¿Qué le sucede al navegador de un usuario si se reemplaza un certificado SSL a mitad de sesión?

A la luz de los navegadores modernos que eliminan gradualmente los certificados de seguridad firmados con el algoritmo hash SHA1, estamos ocupados reemplazando todos nuestros certificados SHA1 por SHA2. En general, podríamos simplemente reemplazar los certificados para estas aplicaciones web principalmente de uso interno en la noche o el fin de semana, cuando había poco o ningún tráfico.

¿Qué pasaría si, sin saberlo, estuviera en medio de una sesión cifrada y se reemplazara el certificado del dominio?

Para estar seguros, les informamos a nuestros clientes que podrían asumir que los usuarios a mitad de sesión durante este cambio podrían ver una interrupción de su sesión y la posible pérdida de cualquier dato que aún no esté almacenado en la base de datos. Si estaba en la mitad de la sesión durante un reemplazo de certificado, ¿podría suponer que cuando cargué la página siguiente, después de reemplazar el certificado, mi navegador vería un certificado firmado diferente al que se estableció con mi sesión y causaría que la sesión " asustarse". Esperaría que todos los navegadores aborden esta situación de manera similar, pero por favor, ilumíneme si me equivoco.

He pasado bastante tiempo buscando más detalles sobre cómo los navegadores lidiarían con este escenario, pero no he tenido mucha suerte en encontrar información general o técnica. Tengo mucha curiosidad y he decidido publicar esta pregunta con la esperanza de obtener una respuesta que responda a la Q de manera concisa, con referencia a algunas fuentes creíbles para validar.

... mi navegador vería un certificado firmado diferente al que se estableció mi sesión y provocaría que la sesión se "volviera loca".

Desde la perspectiva de un webmaster, y sin entrar en detalles sobre " cómo funciona SSL " (que se discutirá mejor en Seguridad de la Información ) ...

La clave de sesión ya no coincidiría, por lo que el servidor o el navegador del cliente anularían la conexión. El navegador del cliente luego haría otra solicitud de cualquier recurso en la siguiente página no recibida, lo que abriría una nueva conexión, restableciendo el protocolo de enlace SSL, el certificado, los intercambios de claves y la clave de sesión nuevamente (como se discutió brevemente en la parte inferior aquí )

Dado que el nuevo certificado SSL se emitiría para el mismo dominio, los usuarios probablemente no notarían nada, ya que solo el certificado cambiaría (es decir, el bloqueo verde aún se mostrará), que los usuarios generalmente no ven de todos modos, especialmente entre páginas en El mismo sitio.

Sin embargo, lo que quizás no esté considerando es que cuando instale el nuevo certificado SSL, tendrá que configurar y reiniciar su servidor de todos modos, por lo que las sesiones se cerrarían y los navegadores no recibirían nada ...

Por lo tanto, sugeriría redirigir temporalmente todo el tráfico a una página de "Mantenimiento" utilizando una redirección 302 , con una notificación anticipada publicada en su sitio que indique la hora en que se realizará el mantenimiento y durante cuánto tiempo el sitio no estará disponible.

Una alternativa a la redirección sería enviar un código de respuesta del servidor HTTP 503 Servicio no disponible con un   campo de respuesta de encabezado HTTP Retry-After para indicar cuándo volvería a estar disponible el servidor.

Por último, pero no menos importante, si tiene más de un servidor para el front-end del sitio, puede instalar el certificado en otro servidor y redirigir nuevas conexiones a ese mientras actualiza los otros servidores. Puede verificar las conexiones existentes en Apache aquí e IIS aquí para ayudar con eso, si aún no utiliza una configuración a prueba de fallas o de equilibrio de carga.