openssl証明書チェーンの出力
Android開発者向けの「HTTPSとSSLによるセキュリティ」ガイドを読んでいて、これを読んでいました 段落 。
この段落では、SSLハンドシェイク中にサーバーが常に証明書チェーン全体を返すとは限らないという事実について説明しますが、サーバー証明書とチェーンのルートCAのみを返すことがよくあります。チェーンは次のようにopensslを使用して示されています：openssl s_client -connect egov.uscis.gov:443
これは私にいくつかの疑問を与えました：
この段落では、ブラウザがこのサーバー構成を管理するために、完全な証明書チェーンを提供するサーバーにあるサイトにアクセスするとき、および「リーフ」と「ルート」のみを提供するサーバーにある別のサイトにアクセスするときに、中間CAをキャッシュするだけであると述べています。 "証明書を追跡するために、キャッシュされた中間CAの証明書を使用します。しかし、ブラウザが中間CAの証明書をまだキャッシュしていないときに、サーバーと "ルート"証明書のみを返すサーバー内のサイトにブラウザーがアクセスするとどうなりますか？認証エラーがトリガーされますか？
ブラウザーがサーバーとルートCA証明書のみを受信する場合、ブラウザーは証明書チェーン全体をどの程度正確に追跡しますか？私の知る限り、このプロセスは、証明書の署名を調べて復号化し、復号化の結果が現在のステップの証明書と一致するかどうかを確認する再帰関数のようなものです。ただし、サーバーとルートCA証明書のみが提供されている場合、（2つ以上のCAが証明書チェーンに含まれている場合）サーバー証明書がルートCA ...
PKI検証手順で何かを誤解していると思います...私にそれを明確にして、どこが間違っているのか理解させていただけませんか？
------編集
良い回答をありがとうございます。リンクを張った記事で「必要な中間CAを含まないようにサーバーを構成することは珍しいことではない」とのことです。ルートCAを含まない中間CAの証明書を指しますか？
...多くの場合、サーバー証明書とチェーンのルートCAのみを返します
サーバー証明書サイトのみを返すのは一般的なエラーですが、通常はルートCAは返されません（これは、参照している記事でも主張されていません）。実際、クライアントがローカルのルートCAのみをトラストアンカーとして使用し、ピアが送信するルートCAは使用しないため、ルートCAはクライアントによって無視されます。詳しくは SSL証明書フレームワーク101：ブラウザーは実際に特定のサーバー証明書の有効性をどのように検証するのですか？ を参照してください。
...しかし、ブラウザが中間CAの証明書をまだキャッシュしていないときに、サーバーと「ルート」証明書のみを返すサーバー内のサイトにブラウザがアクセスするとどうなりますか？認証エラーがトリガーされますか？
これによります。一部のブラウザーは、証明書の検証に失敗します。また、権限情報アクセスを使用して、不足している中間CAを見つける、という別の方法もあります。詳細については、 AIAフェッチ：一般的なSSLの誤設定の解決 を参照してください。
ブラウザーがサーバーとルートCA証明書のみを受信する場合、ブラウザーは証明書チェーン全体をどの程度正確に追跡しますか？
この場合も、ブラウザはサーバーから送信されたルートCAをまったく使用せず、ローカルで信頼されたルートCAのみを使用します。ブラウザーが中間証明書を認識しておらず、上記の方法でこれらを見つけることができない場合、証明書の検証は失敗します。
標準のTLSハンドシェイクに含まれる証明書には、3つのタイプがあります。
- アクセスされているサーバーのサーバー証明書。サーバーによって送信されます。これには、有効なドメイン、有効期限などの詳細が含まれます。独自の署名証明書を持っている認証局によって署名されます。
- 「トラストアンカー」とも呼ばれる1つ以上の信頼されたルート証明書。ブラウザ（または接続しているクライアント）によって保持されます。これらは、個々の証明書に署名することが信頼されているサードパーティを表しています。
- サーバーによって送信されるゼロ以上の中間証明書。これにより、サーバー証明書とトラストアンカーの間に直接リンクがない場合、ブラウザーは署名の「チェーン」を構築できます。
最も単純なケースでは、サーバーの証明書は、ブラウザーが保持するトラストアンカーの1つによって直接署名されています。ブラウザはその署名を検証し、すぐに証明書を信頼できます。
ただし、新規または小規模な認証局の場合、署名証明書はブラウザーから直接信頼されないため、発行する証明書はいずれも信頼されません。これを修正するには、署名証明書を他の認証局から連署されます。ブラウザは、サーバーから送信された「中間証明書」の形式で、これを実行したことの証明を確認する必要があります。
例えば：
- MyAwesomeBrowserを使用して https://some-store.example.com にアクセスします
- Cheapo Certificates PLCによって署名されたSSL証明書を送信します
- MyAwesomeBrowserは証明書を見て、署名者を調べます。次に、トラストストアで一致するトラストアンカーを探します-サーバーはルート証明書を送信しないことに注意してください、または明示的に名前を付けます。サーバー証明書自体の署名情報から推定されます
- MyAwesomeBrowserのトラストストアにはCheapo Certificates PLCがないため、デフォルトでは、証明書（つまりWebサイト）は信頼されません。
これを修正するには：
- Cheapo Certificates PLCがFancy Enterprise Security Corpにルート証明書に副署し、中間証明書を作成
- Some-store.example.comの所有者は、この中間証明書とサーバー証明書を送信するようにサーバーを構成します。 これを行わない場合、ブラウザがこの中間証明書を検出する保証はありません
- MyAwesomeBrowserは、サーバー証明書が中間証明書と一致することを確認してから、中間証明書が信頼できることを確認します
- MyAwesomeBrowserはFancy Enterprise Security Corpの信頼されたルート証明書を持っているため、チェーンを検証でき、サイトを信頼します
リンクした記事で説明されているキャッシング、またはSteffen Ullrichが言及した自動検出により、ブラウザーが使用できるトラストアンカーのプールが効果的に増加します。将来的に他のものを信頼する。元のルート証明書が適切に構成されたサーバーによって送信されなかったのと同じように、ブラウザーは提示された証明書に基づいて、このキャッシュされた/発見された中間体をいつ使用するかを決定できます。