I have two servers A and B that connect via SSL to a third server X.

X had a new certificate installed recently.

Server A could not establish SSL with X, while server B is still working.

Server B is a production site and I am unsure why it still connects securely.

Is it possible that there is a persistent SSL connection that exists between B and X?

My question:

Once established, does the SSL connection still rely on a valid certificate?

I wonder about the risk of updating the trusted store of production server B during the holiday season, versus the risk of the server B SSL connection failing as happened with server A.

This is a highly visible enterprise site, thus my caution about the necessity of adding to B's certificate store and restarting services during this peak season.

  • Are you sure the old cert expired? A cert can and almost always should be replaced before expiration. – dave_thompson_085 Dec 10 '16 at 4:07
  • You should also take into account the possibility of timezone bugs in the client implementation, and always deploy a renewed certificate at least 24 hours in advance. – Riking Dec 10 '16 at 6:42
  • @Riking Why would time zone matter? Aren't times in X.509 certs UTC? – jordanbtucker Dec 10 '16 at 18:08

The certificate is validated at the beginning of a full TLS handshake and usually not validated again during a SSL session (although possible). A SSL session usually lasts at least from the initial handshake to the end of the TCP connection. But with session resume it can also span multiple TCP connections.

  • It looks like that should be true for either session ids or session tickets, right? (The handshake diagrams in that article might be useful here.) – Xiong Chiamiov Dec 9 '16 at 22:54
  • @XiongChiamiov: yes, it does not matter which session resume mechanism is used as long as the session can be resumed. This mainly depends on the server, i.e. if the session id is still there or if the session ticket is still valid. – Steffen Ullrich Dec 10 '16 at 5: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.