7

I am testing a web service with an external partner using 2 way SSL under IIS 7.5. I am requiring SSL, requiring a client cert, and using one to one mapping to authenticate to a domain account. I have configured everything and it works fine on our network (I am able to provide a client cert, get authenticated and invoke the service from browser and test harness). From outside of our network (in most cases, see below), I am getting a 403.7 error. I have gone through the machine level certificate store and made sure the certificates and CAs are trusted. Here's the weird thing. I obtained a Type I cert to test from home (and got 403.7 like our intended partner is). So I setup Fiddler to debug SSL and send my certificate, and this works for some reason. I setup a test harness to pass the exact same certificate, and got 403.7. I test in my browser (IE 9), don't get a prompt for a client cert, and get 403.7.
Any help appreciated. Bill

Bill
  • 73
  • 1
  • 1
  • 3

2 Answers2

8

Last time I checked, IIS was using re-negotiation (by default) to get the client certificate: there is a first handshake where the server doesn't request a client certificate, followed by another handshake (encrypted this time) where the server requests the certificate (via a TLS CertificateRequest message). This will prevent you from seeing anything from Wireshark, unless you configure it to use the server's private key and decipher the traffic (note that this only works with some cipher suites).

One way to see the client-certificate negotiation is to configure IIS to use initial client certificate negotiation, using netsh and clientcertnegotiation=true (which is about initial negotiation). At least the CertificateRequest and the certificate will be sent in clear during the handshake, so you should be able to see this with Wireshark. If the client isn't sending a certificate to the server as a response to the CertificateRequest, you'll still see an empty Certificate message from the client.

If you don't export the private key with the certificate to use with Fiddler or whichever other client, there is no chance that it will be able to use the certificate. It may at best try to send the certificate, but the handshake will fail (since the CertificateVerify message needs to be signed by the client's private key).

I guess you may encounter a problem whereby:

  • not presenting a certificate is accepted by the server (it's effectively optional),
  • presenting an invalid certificate makes it fail and causes this 403.7 status code (many servers and SSL/TLS stacks would implement this as a fatal error, but TLS specification doesn't say that unsupported_certificate, certificate_revoked, certificate_expired, certificate_unknown should be fatal, so this is at the server's discretion).
Community
  • 1
  • 1
Bruno
  • 119,590
  • 31
  • 270
  • 376
  • 1
    Good advice. I forgot we ran with clientcertnegotiation=true when using WS :) – jglouie May 27 '11 at 16:55
  • I was able to get the SSL decryption going with Wireshark. What I'm seeing inside of our network is a Certificate Request message going out to the client after the second handshake. This doesn't happen outside of our network (no Certificate Request is sent by the server after the second handshake. What is sent is: Server Hello, Certificate). Thanks again for reading and responding. – Bill May 28 '11 at 14:11
  • In case it wasn't clear from the above, this is still an open problem. My suspicions are now turning toward either our firewall or the list of CAs being returned in the Certificate Request (despite the fact that I'm not seeing a Certificate Request outside of our network, I did notice that the list of CAs included in the request on the internal network was not the complete list I have configured in the computer store. Not sure why.) – Bill May 28 '11 at 20:05
  • 2
    OK, figured out my problem. First, I don't know why I wasn't seeing a Certificate Request in Wireshark, because I see one now that things are working, and I am certain one was being issued prior because I did get the cert prompt w/ another cert listed. So I consider that a false negative. I had to change the service to run under an account with privileges to the certificate store and NTFS folder. My client cert uses an intermediary CA, so I needed to add that to the server machine store. Final issue was the root CA for my client cert imported w/o the client authentication use indicated. – Bill May 30 '11 at 00:12
0

Are you using the same physical machine to test both the in-network and external-network connections? If not, are you sure that the external-network client has the private key accessible?

I have not configured Fiddler client authentication before. Does it read the client certificate and key from the standard certificate stores? Does it read directly from a PKCS12?

One other thing that may be helpful is inspecting the TLS handshake in WireShark. Specifically, check out the Server's "Certificate Request" message, as the data here clues the client (IE9) which client certificates it should display in the prompt. Compare this for the internal and external connections.

jglouie
  • 12,523
  • 6
  • 48
  • 65
  • Thanks for the advice. Fiddler simply uses a .cer file which you place in its MyDocuments folder under a fixed filename. I didn't embed the private key in the cert file, but it didn't seem to bother Fiddler's connection. I will try your Wireshark idea, although I've never looked at the TLS handshake before. One suspicion I have is that our wildcard certificate on the server may be somehow impacting the certificate query, but when Fiddler's proxy server request the cert, it may be working and then Fiddler passes that cert to the server regardless. Thanks again. – Bill May 26 '11 at 00:49