Question on ssl handshake and behavior in java

Question

I am using https to connect to an https server.
Specifically I am using apache httpclient and I configure the ssl context to use my keystore and truststore.
The https server I am using is IIS7 and is configured to require client authentication.
I think I have set it up properly.
Anyway, if I configure the httpClent's ssl context with a keystore (i.e. with client certificates) valid for IIS then there is no problem connecting.

Now my problem is the following: If I do not configure the ssl context with any client certificate to send to IIS, there is no connection with the server. What makes me think though, is the fact that I was expecting to see some java exception in the code as a result of a hanshake failure alert.
Monitoring what is happening with wireshark, I could not see a certificate request from IIS to my application, but I noticed that after ServerHelloDone everything was encrypted.
I did not expect that. I think the handshake is usually in cleartext.
I used private key to decrypt traces and i saw a certificate request from IIS but after many starting and opening of new connections.
My app send back as a response a certificate of length 0 and IIS replies with a TLSv1 Finished.
After that the packets stop (i.e. seems that the communication ends).
I was expecting a handshake alert.

My question is, is this how it is supposed to work or at least how IIS works?
Or if I do not see the alert something is wrong with my use case?

Thanks

score 1 · Answer 1 · answered May 21 '11 at 18:07

1

It sounds like IIS is only requiring client certificates for certain URLs (ie, for example.com/foo, but not example.com/bar).

In the initial handshake, it does not know which url you are requesting, so it does not require a certificate. When it sees that you are requesting a restricted resource (/foo), it then rehandshakes, requiring a certificate.

However, I would still expect a handshake_failure to occur.

answered May 21 '11 at 18:07

Jumbogram

2,249
1
20
24

I think what you say makes sense concerning IIS.I am not sure what the TLSv1 Finished message is.It seems to be used to close the ssl connection instead of an alert – Cratylus May 21 '11 at 18:32
And the re-handshake, aka the renegotiation as in Bruno's answer below, is encrypted. – President James K. Polk May 27 '11 at 01:46

score 0 · Answer 2 · answered May 23 '11 at 02:15

Failing to supply a certificate in response to a CertificateRequest isn't an SSL protocol error, so there is no handshake_error. 'Requiring' instead of just 'needing' client certificates is added-in by SSL libraries, and all they can do if you don't send one is just close the connection.

score 0 · Accepted Answer · edited May 23 '17 at 12:00

0

As I was saying in an answer to this question, as far as I remember, IIS uses re-negotiation to get the client certificate. You should be able to change this behaviour using netsh and clientcertnegotiate=enable (depending on the version of IIS you're using).

You might also be interest in this similar question.

edited May 23 '17 at 12:00

Community

1
1

answered May 26 '11 at 21:16

Bruno

119,590
31
270
376

Question on ssl handshake and behavior in java

3 Answers3