TLS証明書チェーンの検証方法
TLS証明書チェーンの検証を想定しています。チェーンに証明書A-B-C-Dがあるとします。Dはルート証明書で、AはBによって署名され、BはCによって署名され、CはDによって署名されます。
中間証明書Bがすでにブラウザーに組み込まれていることがわかったとします。つまり、Aがチェックされ、有効である（そしてBによって署名された）ことがわかり、Bがブラウザーに組み込まれます。
（1）チェーンの検証はそこで終わりますか、それともDに到達するまで続きますか？
（2）サーバーが証明書チェーンをブラウザーに提示する場合、サーバーはルート証明書Dも提示しますか、それともA-B-Cのみを提示しますか？
（1）チェーンの検証はそこで終わりますか、それともDに到達するまで続きますか？
証明書連鎖エンジン（CCE）実装に依存します。プラットフォームが異なれば実装も異なります。これは RFC528 で説明されているすべての推奨/必須の検証ロジックをサポートするわけではありません。
証明書の信頼には、自己署名形式で提示されるチェーン終了点が必要です（このような証明書をルートCA証明書と呼びます）。証明書Bは自己署名されていない（Cによって署名されている）ため、CとDがフェッチされて検証されるまで、A-B-C-Dチェーンは信頼されません。したがって、この質問への答えは次のとおりです。チェーンはルートへの検証を続行します。
Microsoftの実装（私が精通している例にすぎません）について話す場合、CCEはすぐに検証を実行せずに（可能な限り）1つ以上のチェーンを構築します。証明書をフェッチし、チェーン内の正しい場所で各証明書をバインドするための基本的なルールを実行しようとします。すべてのチェーンが構築されると、それぞれがRFC5280に記述されているルールに従って検証されます。検証されると、複数の信頼できる有効なチェーンが存在する場合があります。 CCEは独自の選択ロジックを使用して、チェーンのコレクションから1つのチェーンのみを選択します。
ブラウザでcertrtificateストアについて話すとき、それらは次の目的で使用されます。
- 特定の信頼されたルートCA（信頼されたルートCAストア）への信頼を確立します。これらの証明書は、自己署名形式で提示する必要があります。そうしないと、チェーンエンドポイントとして使用できず、信頼が確立されません（中間証明書がルートストアにインストールされている場合でも）。
- cCEが不足している証明書をローカルからダウンロードできるので、インターネットからダウンロードしなくても、CCEがすばやくチェーンを構築できるようにします。一部のブラウザは、
Authority Information Access拡張を処理する機能を完全に欠いています。つまり、SSLクライアントは、SSLハンドシェイクとローカル証明書ストアの2つのソースからのみCA証明書をフェッチできます。
（2）サーバーが証明書チェーンをブラウザーに提示する場合、サーバーはルート証明書Dも提示しますか、それともA-B-Cのみを提示しますか？
webサーバーの実装によって異なります。 RFC 5246§7.4.2 からの参照：
certificate_listこれは、証明書のシーケンス（チェーン）です。送信者の証明書はリストの最初に来る必要があります。以下の各証明書は、その前の証明書を直接証明する必要があります。証明書の検証ではルートキーを個別に配布する必要があるため、ルート認証局を指定する自己署名証明書は、リモートエンドがそれを検証するためにすでに所有している必要があるという前提の下で、チェーンから省略される場合があります。
RFCは、ルートCA証明書をクライアントに送信する場合としない場合があることを推奨しています。その結果、SSLクライアントを開発する場合、ルート証明書がチェーンに沿って出荷される可能性があることを期待する必要があります。 2つの主要なWebサーバー：ApacheとIISデフォルトでは、SSLハンドシェイク中にルート証明書を送信しないでください。