1

I have one windows service and web service trying to make a web service call over TLS. I have setup the certificates in MMC and I am able to successfully connect using the web service. However, when I try to make the same call using same certificate from Windows Service it is unable to establish the connection. Both web service and windows service are running under local system account. I tried using Microsoft Network Monitor and found that when using with Windows Service, server is not providing the certificate during SSL handshake. What could be the reason to this? Following are screenshots of the network monitor.

With webservice

Windows Service

3

In your second screenshot you see that the server sends its ServerHello and no subsequent Certificate Request... but no Certificate either. The server immediately proceeds with a ChangeCipherSpec, as if all the asymmetric crypto had already been done; and that's exactly the case. This is an abbreviated handshake in which both client and server remember the session secrets from a previous connection, and agree to use them again. When a session is thus resumed, there is no certificate, neither from the client, nor from the server. The client sends in the ClientHello a copy of the session ID from the previous session, and the server elects to indeed resume that session.

Ideally this is fine; if the previous session used an authentication that the server is comfortable with (e.g. a client certificate was indeed shown), then reusing the session implies reusing that authentication state. If the server is not comfortable with it, it may reject the resumption attempt (i.e. ignore the session ID as sent by the client, and proceed with a full, normal handshake) or enforce a re-handshake within the first. In a practical, realistic World, things are not always ideal, so the server code may accept to reuse the session, then decide that it should not have done so, and hide its shame by abruptly closing the connection.

SSL session parameters are cached in RAM, so restarting the client and/or the server process should empty such caches and at least allow you to obtain a clearer picture of what happens. It might also fix the issue altogether (that's the lightweight version of "try a reboot", a well-known cure for many Windows-related ailments).

  • Thanks for the explanation, is there any way for me to force a normal handshake other than killing previous process? (I am using C# for coding these if it matters). – Naveen Jan 17 '14 at 4:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.