Qu'advient-il du navigateur d'un utilisateur si un certificat SSL est remplacé en cours de session?

À la lumière des navigateurs modernes supprimant progressivement les certificats de sécurité signés à l'aide de l'algorithme de hachage SHA1, nous sommes occupés à remplacer tous nos certificats SHA1 par SHA2. En règle générale, nous pouvions simplement remplacer les certificats pour ces applications Web principalement à usage interne le soir ou le week-end, lorsqu'il y avait peu ou pas de trafic.

Que se passerait-il si j'étais, sans le savoir, au milieu d'une session cryptée et que le certificat du domaine était remplacé?

Pour être sûr, nous avons informé nos clients qu'ils pouvaient supposer que les utilisateurs en cours de session pendant ce changement pourraient voir une interruption de leur session et une perte possible de toutes les données non encore stockées dans la base de données. Si j'étais en cours de session pendant un remplacement de certificat, puis-je supposer que lorsque je chargerais la page suivante, après le remplacement du certificat, mon navigateur verrait un certificat signé différent de celui avec lequel ma session a été établie et entraînerait la session " flipper". Je m'attendrais à ce que tous les navigateurs traitent cette situation de la même manière, mais veuillez m'éclairer si je me trompe.

J'ai passé pas mal de temps à chercher plus de détails sur la façon dont les navigateurs géreraient ce scénario, mais je n'ai pas eu beaucoup de chance pour trouver des informations générales ou techniques. Je suis vraiment curieux, et j'ai décidé de poster cette question dans l'espoir d'obtenir une réponse qui répond au Q de manière concise, en référence à quelques sources crédibles à valider.

... mon navigateur verrait un certificat signé différent de celui avec lequel ma session a été établie, et provoquerait une "panique" de la session.

Du point de vue d'un webmaster, et sans entrer dans les détails sur " comment SSL fonctionne " (ce qui serait mieux discuté à la sécurité de l'information ) ...

La clé de session ne correspondrait plus, donc le serveur ou le navigateur client abandonnerait la connexion. Le navigateur client ferait alors une autre demande pour toutes les ressources sur la page suivante non reçues, ce qui ouvrirait une nouvelle connexion, rétablissant la négociation SSL, le certificat, les échanges de clés et la clé de session (comme discuté brièvement en bas) ici ).

Étant donné que le nouveau certificat SSL serait émis sur le même domaine, les utilisateurs ne remarqueraient probablement rien car seul le certificat changerait (c'est-à-dire que le verrou vert sera toujours affiché), ce que les utilisateurs ne voient généralement pas de toute façon, en particulier entre les pages sur le même site.

Ce que vous pourriez ne pas considérer cependant, c'est que lorsque vous installez le nouveau certificat SSL, vous devrez de toute façon configurer et redémarrer votre serveur, de sorte que les sessions seraient alors fermées et les navigateurs ne recevraient rien ...

Par conséquent, je suggérerais de rediriger temporairement tout le trafic vers une page "Maintenance" en utilisant une redirection 302 , avec une notification à l'avance publiée sur votre site indiquant l'heure de la maintenance et la durée pendant laquelle le site sera indisponible.

Une alternative à la redirection serait d'envoyer un code de réponse de serveur HTTP 503 Service non disponible avec un   champ de réponse d'en-tête HTTP Réessayer après pour indiquer quand le serveur serait à nouveau disponible.

Enfin, si vous disposez de plusieurs serveurs pour le front-end du site, vous pouvez installer le certificat sur un autre serveur et rediriger de nouvelles connexions vers celui-ci pendant que vous mettez à jour les autres serveurs. Vous pouvez vérifier les connexions existantes dans Apache ici et IIS ici pour vous aider, si vous n'utilisez pas déjà une configuration de sécurité intégrée ou d'équilibrage de charge.