I've got a web service with an .asmx entry point that I'd like to access using a client certificate. There's some internal logic that checks the validity of the client certificate in the request and ensures that it is present in the 'trusted people' certificate store of the local machine.
Setting the .asmx file to 'Accept' or 'Require' client certificates in IIS works fine on my local developer box, but on our QA machine the server doesn't respond, and the only error message that I get out from the other side is 'The underlying connection was closed: An unexpected error occurred on a receive.' What's I really don't understand is that even non-ssl communication starts to fail as well.
Wireshark reports that the server is not making a CertificateRequest, making me suspect that the server's configuration is at fault, not the client certificate. IIS Failed Request Traces reveal only that 'The I/O operation has been aborted because of either a thread exit or an application request', without any stack trace or useful information.
The client certificate that I'm using was created from a root that is in the trusted root certificate of both machines, and the server's certificate is also valid and within its expiry. I can travel to other URLs on the server without an issue in my browser and without an SSL error.
https://myservice/api.asmx // Unexpected error on a receive
https://myservice/logon // 200, valid SSL certificate
Does anyone have any experience of getting this sort of an error when turning on 'Accept' or 'Require' client certificates in IIS? It seems to hold true for any folder or application I configure client certificates on for both of the load balanced servers that my services run on. Any help would be appreciated.
OK so in the end the problem was with the load balancer configuration. Apparently netscaler was handling the SSL handshake itself, and so IIS's CertificateRequest never made it to the client (which was evident by Wireshark not finding a CertificateRequest) and conversely any client certificate sent by the client never made it to IIS.
The solution was to alter the load balance protocol from SSL to SSL_Bridge on the netscaler.