セッションの途中でSSL証明書を置き換えると、ユーザーのブラウザーはどうなりますか？

SHA1ハッシュアルゴリズムを使用して署名されたセキュリティ証明書を段階的に廃止する最新のブラウザーに照らして、すべてのSHA1証明書をSHA2で置き換えることに忙しくしています。通常、トラフィックがほとんどないかまったくない夜間または週末に、これらの主に内部使用のWebアプリの証明書を単に置き換えることができます。

知らないうちに、暗号化されたセッションの最中にドメインの証明書が置き換えられた場合はどうなりますか？

安全を期すために、この変更中にセッションの途中のユーザーがセッションの中断や、データベースにまだ保存されていないデータの損失が発生する可能性があると想定できることをクライアントにアドバイスしました。証明書の交換中にセッションの途中だった場合、次のページを読み込んだときに、証明書の交換後に、ブラウザがセッションの確立に使用したものとは異なる署名付き証明書を表示し、セッションを「フリークアウト」。私はすべてのブラウザがこの状況に同様に対処することを期待しますが、私が間違っている場合は教えてください。

ブラウザーがこのシナリオをどのように処理するかについての詳細を探すのにかなりの時間を費やしましたが、一般的または技術的な情報を見つけるのにあまり運がありませんでした。私は本当に好奇心が強いので、検証するいくつかの信頼できる情報源を参照して、Qを簡潔に回答する回答を得ることを期待して、この質問を投稿することにしました。

...私のブラウザは私のセッションが確立されたものとは異なる署名された証明書を見て、セッションを「フリークアウト」させます

Webマスターの観点から、「SSLのしくみ」の詳細に触れずに（情報セキュリティで詳しく説明されています）...

セッションキーが一致しなくなったため、サーバーまたはクライアントのブラウザーが接続を中止しました。次に、クライアントブラウザーは、受信されていない次のページのリソースに対して別のリクエストを行い、新しい接続を開き、SSLハンドシェイク、証明書、キー交換、およびセッションキーを再確立します（下で簡単に説明します）。こちら）。

新しいSSL証明書は同じドメインに発行されるため、証明書のみが変更されるため（つまり、緑色のロックが引き続き表示されます）、ユーザーは通常何も表示しません。同じサイト。

ただし、新しいSSL証明書をインストールすると、サーバーを構成して再起動する必要があるため、セッションが閉じられ、ブラウザーが何も受信しないことを考慮しないでください。

したがって、302リダイレクトを使用してすべてのトラフィックを一時的に「メンテナンス」ページにリダイレクトすることをお勧めします。事前にサイトに投稿され、メンテナンスが行われる時間とサイトが利用できない期間を通知します。

リダイレクトの代わりに、503 Service Unavailable HTTPサーバー応答コードを  Retry-After  HTTPヘッダー応答フィールドとともに送信して、サーバーがいつ再び利用可能になるかを示すこともできます。

最後に重要なことですが、サイトのフロントエンドに複数のサーバーがある場合は、別のサーバーに証明書をインストールし、他のサーバーを更新しながら新しい接続をそのサーバーにリダイレクトできます。あなたは、Apacheでの既存の接続を確認することができ、ここでとIIS ここにすでにフェイルセーフまたはロードバランシングの設定を使用しない場合は、それに助けに。