私はサーバーとネットワークの世界では初心者なので、質問が明確で、あまり些細なことではないことを願っています。最近、次のようなシナリオに遭遇しました。
数か月後に期限が切れるルート証明書 A がありました。A の代わりとなる新しいルート証明書 B がありました。A と B は両方とも自己署名されています。A の CA は古いブラウザと新しいブラウザ/OS によって信頼されていますが、B の CA は最新のブラウザ/OS によってのみ信頼されています。
現在、当社のサーバーで使用しているクロス証明書 A->B (B は A によって署名されています) がありました。ただし、A はまもなく期限切れになるため、代わりに別のクロス証明書 C->B (B は C によって署名され、C の CA は新旧両方のブラウザー/OS によって信頼されています) を適用しました。
さて、UAT 環境では、証明書 C->B を更新し、クライアント側ではテストにいくつかのレガシー ブラウザーを使用してみました。A の CA と C の CA のみが信頼され、B の CA は信頼されていないことを確認しました。PROD 環境では、変更せず、証明書 A->B を使用します。
上記のブラウザで UAT サイトにアクセスし、初めて使用された証明書が A->B であることを確認しました。驚いたことに、その後の UAT サイトと PROD サイトの両方へのアクセスでは、使用された証明書は C->B でした (クライアント側で確認済み)。
私の質問は、これは通常の動作ですか? クライアント側は、UAT サイトへの最初のアクセス以来、なぜ C->B を使用することを「認識」しているのですか? また、openssl s_clientPROD サーバーがまだ A->B を使用していることを確認するためにも使用します。 ブラウザは、使用する証明書をどのように認識し、それに応じて証明書を「更新」するのでしょうか?
2022年12月13日に編集
- 私たちの主な目的は、非常に古いブラウザ/OSと最新のブラウザ/OSの両方をサポートすることです。つまり、証明書Aの有効期限が切れた後でも、すべてのブラウザが当社のサイトに正常にアクセスできます。
- 私の主な疑問、あるいは疑念は、次のことが真実であるかどうかだと思います。
- 古いブラウザでは、UAT サイトに初めてアクセスすると、キャッシュ メカニズムにより、サーバーが証明書 A->B を使用していることが示されます。
- UAT サイトへの最初のアクセス後、サーバーは実際に、サーバーで構成されている新しい証明書 C->B をクライアント側に「プッシュ」します。これで、ブラウザー、または OS レベルでも、最新の証明書が A->B ではなく C->B であることが認識されます。
- C->B は承認されていますが、証明書 A->B はブラウザ/OS にまだ保存されています。しかし、ブラウザはどういうわけか、新しい証明書 C->B で検証することを認識しています。つまり、目的は達成できます。
答え1
しますかこれあなたの質問に答えますか?
リンクから、ブラウザのキャッシュ/SSL 状態をクリアする必要がある可能性があります。
Web ブラウザは、ブラウジングの速度を上げるために SSL 証明書をキャッシュします。通常、これは問題ではありません。ただし、Web サイトのページを開発しているときや新しい証明書をインストールしているときは、ブラウザの SSL 状態が問題になることがあります。たとえば、新しい SSL 証明書をインストールした後、ブラウザのアドレス バーに南京錠アイコンが表示されないことがあります。