Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have two servers, let's call them Milo and Otis. Now Milo and Otis are setup to be an active-passive pair of highly available servers where Milo is usually the master and Otis stands-by waiting for the unlikely failure of Milo when Otis will take over the shared virtual IP. I have a question about what happens to the SSL connection during the failure.

Consider the following:

  1. Some client (me) makes a SSL connection to Milo.
  2. The SSL connection is set to stay alive, so lets say a webpage is requested over the SSL connection. The page is downloaded completely and the connection is open ready for another request (let's say an asset like a css file).
  3. Before the request for the css file is started, Milo experiences some catastrophic failure and now Otis has taken over.
  4. What happens now that I want to make a request for the css file? I still think I have an open connection to Milo, but the Virtual IP is now pointing to Otis.

Does Otis pick up the SSL sessions that Milo had automatically? Does my browser start to communicate with Otis and Otis says "Hey, we should probably shake hands first."? Any and all comments/answers about this would be appreciated.

share|improve this question
up vote 1 down vote accepted

When failover occurs, currently active connections will break. This will happen the TCP level however, so SSL/TLS won't even enter the scene. A TCP connection requires that both endpoints know about the connection and have the right information (sequence numbers, window sizes, etc.), and so when the IP fails over the backup machine will have no knowledge of the TCP connections which the master had established. When the backup machine receives packets which are part of previous TCP connections it will reply with an RST packet, which will cause the client to close the connection.

Even if TCP connections were recovered, a similar situation would occur with SSL/TLS. Each session requires state at each end, including the session key (which is what actually secures the application data). The backup machine won't have this session state, and so existing sessions would be terminated.

share|improve this answer
So, even though the IP doesn't change as far as the client is concerned, the new (Otis) server will go "Whoa buddy, we don't have a TCP connection yet"? Is that right? – Patrick James McDougle Mar 18 '13 at 21:11
@PatrickJamesMcDougle Correct. – mgorven Mar 18 '13 at 21:11
currently active connections will break - no, it's what should happen (sometimes it doesn't - fencing is a major issue with any clustering). This will happen the TCP level - not necessarily - a lot depends on where the SSL is terminated - which is not necessarily on the server. The backup machine won't have this session state - sorry, this is very wrong. SSL session sharing across servers has been around for a very long time. – symcbean Mar 18 '13 at 23:43
@symcbean I'd be interested in more details about those points, hope you're writing up an answer :-) – mgorven Mar 19 '13 at 0:00
1 , ,… and it's trivial to handle failed GETs (POSTs should never be recoverable) at the application level. – symcbean Mar 19 '13 at 9:48

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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