0

I was wondering (based on the TLS RFC and its current implementation by the major vendors / platforms - i.e. Microsoft's IIS): how would an existing active SSL / TLS session behave / react if the server where to change the certificate that was used for negotiating initially that session to an entire new certificate ?

Would the server automatically close the existing sessions ? (and specifically, how would IIS and Windows Server 2008R2/2012R2 handle this case - would the server side be able to start using the newly selected server certificate without affecting the already established SSL/TLS sessions ?)

Or would the server be able to change its certificate without affecting (closing) the already existing encrypted sessions?

Would the client detect the change at a later stage during the session (i.e. if a session renegotiation were to be performed) ?

Thank you in advance.

Ottootto
  • 123
  • 1
  • 6

1 Answers1

2

The server certificate is only used during the TLS handshake. It is irrelevant for the remaining session and so there is no need to close a session when the certificate changes. In fact the client will not even notice that a certificate has changed (or if a certificate got revoked) unless a new TLS handshake is done, i.e. either when doing a new connection or when doing a renegotiation inside an existing connection.

But it might be that specific server implementations will close a session as a side effect when the certificate gets changed for technical reasons, for example because the process needs to be restarted.

And there are client implementations which restrict certificate changes on renegotiation in order to deal with the triple handshake attack. Thus if the server changes the certificate and a renegotiation gets triggered (maybe because a client certificate need to be checked) then this can result with current Java implementations in server certificate change is restricted during renegotiation.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424