In light of modern browsers phasing out security certificates signed using the SHA1 hash algorithm, we're busy replacing all our SHA1 certificates with SHA2. Generally we could simply replace certs for these primarily internal-use web apps in the evening or on the weekend, when there was little to no traffic.

What would happen if I were, unknowingly, in the middle of an encrypted session and the certificate for the domain was replaced?

To be on the safe-side, we advised our clients that they could assume users in mid-session during this change could see an interruption of their session, and possible loss of any data not yet stored in the database. If I were in mid-session during a cert replacement, could I assume that when I loaded the next page, after replacement of the cert, my browser would see a different signed cert than my session was established with, and cause the session to "freak out". I would expect all browsers would deal with this situation in a similar way, but please enlighten me if I am mistaken.

I have spent a fair amount of time searching for more specifics on how browsers would deal with this scenario, but I haven't had much luck finding general or technical information. I am really curious, and have decided to post this question in hopes of getting an answer which answers the Q concisely, with reference to some credible sources to validate.

1 Answer 1


...my browser would see a different signed cert than my session was established with, and cause the session to "freak out".

From a webmaster's perspective, and without getting into details on "how SSL works" (which would be better discussed over at Information Security)...

The session key would no longer match so either the server or client browser would abort the connection. The client browser would then make another request for any resources on the next page not received, which would open a new connection, re-establishing the SSL handshake, the certificate, the key exchanges and session key again (as discussed in brief near the bottom here).

Since the new SSL certificate would be issued to the same domain, users likely wouldn't notice anything since only the certificate would change (i.e., the green lock will still be displayed), which users typically do not view anyway, especially between pages on the same site.

What you might not be considering however is that when you install the new SSL certificate, you're going to have to configure and restart your server anyway, so sessions would be closed then regardless and browsers wouldn't receive anything...

Therefore, I would suggest temporarily redirecting all traffic to a "Maintenance" page using a 302 redirect, with a notification ahead of time posted on your site stating the time the maintenance will occur, and for how long the site will be unavailable.

An alternative to the redirect would be to send a 503 Service Unavailable HTTP server response code with a Retry-After HTTP header response field to indicate when the server would be available again.

Last but not least, if you have more than one server for the front-end of the site, you could install the certificate on another server and redirect new connections to that while you update the other server(s). You can check for existing connections in Apache here and IIS here to help with that, if you don't already use a fail-safe or load-balancing setup.

  • Certs are on a load balancer out front... so there is no interruption of service and no 503/temp redirect are needed.
    – Dallas
    Feb 8, 2015 at 18:25
  • So if I were on page 5 of a 10 page workflow... would my session keep info already entered on pages 1-5, and continue on page 6 with the new cert, or would the connection reset lose all session variables and start me again on page 1 fresh?
    – Dallas
    Feb 8, 2015 at 18:30
  • That depends on how your web application is coded. It should be tracking the session ID for the user (stored in a cookie, form field, URL, etc…), which is different than the SSL/TLS session. So if there's a break in connection (which can occur normally), the user's session data will remain for a period of time until they make another connection. In the odd circumstance that session IDs are not being tracked, you should offload new connections to another server and wait for existing connections to complete or timeout before taking that server off-line to update its SSL certificate.
    – dan
    Feb 8, 2015 at 22:56
  • I apologize for poor wording. What I was getting at, is whether a session takes issue when the next connection comes from a different cert than the session was established with. Does the session not care? I would think a different cert would have some effect on resumption of a session, but I get the impression you're saying the session doesn't care about the connection. I'm not aware of what the difference is between SSL session and "user session"? I was under the impression the session ID we track is the SSL/TLS session ID, which I thought was also the same thing as the user's session.
    – Dallas
    Feb 9, 2015 at 0:47
  • I think you're mixing up terminology a bit: Session ID is generated by the server and used to track the user through subsequent requests since HTTP is stateless. All TCP socket connections can terminate, so it's up to the application to track the user when they do, which is done using a session ID. For example: securely log into a bank or other secure site, click on some links, then disable your nic card, then enable it and click on another link...you'll still be logged in as your session ID is tracked by their application.
    – dan
    Feb 9, 2015 at 1:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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