Let’s build this project, using our standard environment of visual studio 2012, IIS express (with certs), on Windows Server 2012. Lets see what we have to do to this older project to get it to do what it was supposed to do, originally.
concerning the steps
we use our *.rapmlsqa.com cert for step 1 (server authn)
we use www.rapmls.info cert for step 2 (client authn)
Each are issued by GoDaddy.
We make the core service using the wizard:
We want to host this in IIS express with our ssoservices.rapmlsqa.com cert on port 44300 (already configured with the the kernel so SSL bindings for this domain can tie to the cert). So, we set our web binding properties with the domain and the cert, ready to create the vdir. But, before we do it we ensure IIS (express) has such a binding. Perhaps, you will just use IIS and IIS manager.
When we start debugging, having selected the .svc file, we get
note we added httpsgetenabled=true to the metadata behaviour
we see by default (on viewing the config file in test client), the security properties of the default binding
A simple test shows something working on https from a browser:
And if we insert fiddler in the SSL MITM chain, it confirms that we are not being misled – since we can wiretap everything (American style) including the metadata (sent over https) concerning the http endpoint exposed by the port:
Having established “sanity”, we can look at the exam’s instructions for step 4:
So, we create a service (since they can be implicitly defined in WCF 4, unlike earlier incarnations)
and follow the wizard (which deviates a little from the old instructions in the old exam):
getting us to the screen where we can set the name:
we create our binding:
When we save and look at the web.config result, we can compare it with the verification material in the exam (remember your CISCO certification even at CCNA level):
note the missing mex endpoint, to be added/amended next:
OF course the next step is to add security to an IMetadataExchange endpoint
So we use the tool again:
Running a quick sanity check, we fail to read metadata now (since this WCF test client cannot provide the required client credentials, per the security policy assertion attached to the mex endpoint)
Lets make sure IIS express uses transports that are willing to challenge for SSL client certs within https:
If we start up our metadata importer tool with fiddler intercepting https, we see fiddler try (and fail) to supply a client cert. (This is because I have not configured one; but at least it shows the challenge!)
and (not) supplying one gives
Now to the client, per step. We add a client-side proxy to our service, having added a forms project to the solution – within which services are discovered:
When we add a call to the method in the form_load event, we get (when fiddler,m as interceptor, does NOT supply the cert or relay the challenge to the form:)
ok. I see the problem folks are having with client certs, in an IIS/windows world, as a transport credential.