証明書チェーンのチェック
非常に具体的な質問があります。
クライアントは、証明書を取得して特定の値を確認し、中間CAのデジタル署名が正しいことを（サーバーに保存されている公開鍵に従って）サーバーを確認します。
- オプションA：クライアントは、中間CA署名（ルートCAによって署名された）が有効であること、およびルートデジタル署名（自己ルートCAによって署名された）は、コンピューターに保存されている公開鍵と相関していますか？
OR
- オプションB：サーバーのデジタル署名が正しいことをクライアントは確認し、証明書ストアに格納されている情報を使用して残りのチェーン（つまり、証明書Bがサーバー証明書の署名に使用された場合、証明書ストアは証明書Aが証明書Bの署名に使用されたため、残りのチェーンとして表示します）
チェーン全体がサーバーにインストールされていることを理解していますが、クライアントはすべての証明書を使用しますか？
これは私の一般的な関心に刺激され、中間証明書が適切にインストールされず、Google ChromeおよびInternet Explorerはそれを受け入れましたが、Firefox 4.0はそうしませんでした。
質問をできるだけ明確にしたいと思います。
質問を混乱させないために、SSL検証で使用される他のいくつかのステップを故意に取り除きました。
注：この質問に関連する非表示の画像があり、編集時に発見しました：
サーバーは独自の証明書を提供し、オプションで（ただし推奨）チェーン内のすべての中間CA証明書（別名CAバンドル）。チェーンのルートCA証明書を提供する必要はありません。それでも、バンドルで提供されている場合、クライアントはその証明書を無視する必要があります。詳細については、 この質問 を参照してください。完全なバンドルはおそらく不要なオーバーヘッドであるため、将来的にクライアントは キャッシュされたコピーがあることを示す で接続設定を削減できるようになります。
検証のポイントは、クライアントは信頼されたルートまでのチェーン全体を検証できる必要があるため、ルートのコピーが既にあり、すべての中間物を持っているか取得する必要があります。
クライアントが中間CA証明書を欠落している場合は、検証可能であればサーバーから提供されたものを信頼でき、CA証明書のローカルコピーを使用して欠落している部分を埋めることができます。これは、中間CA証明書の更新に使用される方法であるため、クライアントは簡単に更新できます（PGPキーサーバーに類似した、広く展開されているX.509証明書の取得または公開システムはありません）。チェーンには、ゼロ、1つ、または多数の中間証明書があります。
各証明書には、その直接の発行者/親（つまり、チェーン全体ではない）の識別詳細のみが含まれます。これは、IssuerDNフィールドなどに記録されます。便利なAKIDフィールド（ AKID/SKID PDF）。読み取り可能なIssuer名は、特定の証明書を一意に識別しない場合があります（特定のシリアル番号は記録されません）。 SKID（Subject Key Identifier） は事実上証明書の拇印であり、 AKID（Authority Key Identifier） は発行者の拇印です。これは単独で機能します-エンド証明書から（理想的には）信頼されたルートまでのリンクリスト（古い証明書にはこれらのフィールドがないことが多いため、代わりにDNが使用されます）。
- サーバーが提供するチェーン（存在する場合）から始めて、クライアントはリストを下に移動する必要があります。有効でない場合、不足している中間証明書をストアに追加できます。
- 次に、クライアントはサーバー証明書からさかのぼってトレースします。通常はAKIDフィールドを使用して特定の発行者（親）証明書を見つけ、確認し、信頼された自己署名ルートに到達するまで操作します。
このプロセスに関連する用語は Certification Path Building および Certificationです。パスの検証 。それを行うための単一の「正しい方法」はありません。堅牢なクライアントがエンドツーエンドでチェックします。通常、ブラウザーはバイパス（厳格な警告）を提供し、一部のシステムでは、エンド証明書からの深さを制限して最適化としてチェックできます。
（有効性チェックには、署名/ハッシュ、日付範囲、CRL、OCSP、 ピン留め などが含まれ、場合によっては [〜＃〜] dane [〜＃〜] が含まれます。）
これは、両方のオプション、および中間CA証明書の自己更新と重複します。
信頼の連鎖は、サーバー証明書から始めて、信頼されたルートが見つかるまで署名を検証することによって検証されます。そのため、サイト証明書の署名は、中間CAの公開証明書に対して検証されます。ただし、中間CAは信頼されていないため、中間CAの公開証明書の署名は、ルートCAの公開証明書に対して検証されます。署名が有効であるため（また、無効であることを示す失効リストエントリがないため）、中間CA（およびサーバーの証明書）は、信頼されたルート証明書から信頼を継承します。
このプロセスは、信頼できる証明書に到達するまで、必要な階層の世代まで継続できます。たとえば、サーバーの証明書がローカルマシンの信頼できる証明書リポジトリに手動で追加された場合、信頼を取得する必要がないため、中間CAの署名は検証されません。
通常、サーバーはデフォルトではすべての証明書チェーンを送信しません。これは、サーバーの構成方法と、そのすべての証明書チェーンがWebサーバーのキーストアに含まれているかどうかによって異なります。
これをOpenssl Serverクライアントのセットアップで実現するには、すべての中間体を独自の証明書と連結する必要があります。証明書は、最初に独自の証明書、次に署名した中間証明書の順である必要があります（ルートCAはクライアントに存在するため、連結することは無視できます）。また、サーバー側のSSL_CTX_use_certificate_chain_fileで同じ証明書チェーンリストを使用します。これで、クライアントでは、この証明書チェーンを検証するためのルートCA証明書があれば十分です。
これと逆のアプローチがあります。サーバーは、SSLハンドシェイクで独自の証明書（中間証明書とルートCAによって署名された証明書）を送信するだけです。ここで、完全なチェーンを検証するには、クライアントに中間CAとルートCAの両方の証明書が必要です。クライアントは、最初にルートCAの順序で中間CAとルートCAを連結し、その後に中間証明書などが続きます。 （このリストのサーバー証明書の連結は無視できます）。クライアントはSSL_CTX_use_certificate_file APIを使用し、この連結ファイルを含めてサーバー証明書を確認できます。