RFC 5280によるSSL証明書チェーンの検証：これを正しく理解していますか？

Question

chromeでは証明書の安全性が低下するようにGoogleが移行したため、証明書をSHA1ハッシュに置き換える処理を行っています。交換用の証明書は、現在使用しているものとは異なる中間CAを使用しますが、ルートCAは同じです。テスト中に、SSLクライアントが新しい証明書を使用したチェーンの検証に失敗することに気付きました。理由はよくわかりません。

詳細は次のとおりです。

現在、サーバーが送信するチェーンは次のようになります。

同じ認証局からのサーバーCA Xによって署名されたルートCA（サーバー証明書に付属）
中間CA 1（サーバー証明書に付属）
サーバー証明書

私たちが信頼するSSLクライアントでは：

ルートCA、自己署名、同じCNおよび同じキー（同じスキッド）！（当局からダウンロード。Mozillaが製品に組み込むのと同じ）
中間CA 1（サーバーが送信するものと同じ）

これは現在の証明書チェーンで機能しますが、中間CA 1を信頼しているためです。これを削除すると、サーバーCA Xが信頼されていないために失敗します。新しい証明書は、別の中間CAによって署名されているため、明らかに機能しません。

さて、RFC 5280のセクション6.1を読んだときの私の印象は、SSLクライアントは標準に準拠していないということです。

トラストアンカーから始めます。現在も有効かどうか（時間）などを検証します。
次の証明書の場合：以前の証明書のCNとキーが現在の証明書の発行者のCNとキーと一致するかどうかを確認します（pathlenの制約などを確認します...）
最後の証明書はCA証明書であってはなりません

ポイントは、トラストアンカーとして使用するように構成されているルート証明書の発行者が、サーバーによって提示されたルート証明書とは異なるため、SSLクライアントはチェーンの検証に失敗します。ただし、CNとキーはどちらも同じです。 RFC 5280で読んだ内容についての私の理解から、SSLクライアントはトラストアンカーの発行者を気にするべきではありません。また、チェーン内の証明書には、そのようなことを強制するポリシーが定義されていません。ただし、SSLクライアントがこれにつながる追加のポリシーを強制する可能性があるかどうかはわかりません（私のシステムではありません）。

だから私の質問は：私たちのSSLクライアントはこのシナリオで正しく動作するか？そしてもちろん：なぜ？

前もって感謝します

編集：サーバーは知っていますすべきルート証明書ではなく、中間CA証明書のみを送信しますが、認証局が証明書と一緒にバンドルとして提供したものを使用しています、ルート証明書が含まれています。さらに、私が知っていることから、その場合、クライアントはサーバーから送信されたルート証明書を無視する必要があります。

また、奇妙なのは、クライアントがサーバー証明書から信頼できるものまでのチェーンを検証するように動作し、その後停止するのに対し、仕様では、トラストアンカーからサーバー証明書までのチェーンを検証する必要があるということです。

Edit2：ルートCA証明書のさまざまな「バージョン」はすべて同じSKIDを持っています-それらは（もちろん）発行者とシリアル番号のみが異なります。

また、頭に浮かんだのは、最初の編集の情報から、SSLクライアントは、信頼できるルート証明書と、発行元で同一であるチェーンと、それを受け入れるためのシリアル番号が必要であるかのいずれかであるようです。

Thomas Pornin · Accepted Answer

X.509 と SSL/TLS があります。 TLSは、サーバーがX.509証明書チェーンを送信することを期待しており、そこからクライアントがサーバーの公開鍵を抽出します。次に、物事は分岐します：

純粋なX.509では、サーバーはcertificateを送信してクライアントが検証する必要があります。おそらく、サーバーは、クライアントにとって有用であることが判明する可能性のある、順序付けされていない追加の証明書の束を追加する可能性があります。クライアントは、特に任意のチェーン構築を通じて、証明書が適切と思われる方法で自由に検証できます。この方法は、たとえば [〜＃〜] cms [〜＃〜] （以前は「PKCS＃7」として知られていました）で示されています。ここでは、署名されたドキュメント（SignedData）は署名者の証明書を参照し、オプションで追加の証明書の順序付けされていないセット（ASN.1 "SET"）を含みます。
SSL/TLSでは、物事はそのようにはいきません。代わりに、サーバーは使用される正確なチェーンを送信する必要があります。サーバーは明示的にルートCAを省略できますが、それだけです。すべてのクライアントは、チェーンがこのパターンに一致しない場合、サーバーの証明書を拒否する資格があります（少なくとも、そうでない場合はde jure）。もちろん、どのクライアントも許可して、独自のパスを構築し、X.509の方法でサーバーの証明書を検証しようとします。しかし、そのような努力をしないSSLクライアントが世に出ています。

RFC 5246の関連する抜粋は付録F.1.1 にあります。

サーバーが認証される場合、その証明書メッセージは、受け入れ可能な認証局につながる有効な証明書チェーンを提供する必要があります。

これは、SSLクライアントに、「現状のまま」検証できないサーバーチェーンを不当に拒否する「権利」を与える一節です。

あなたの場合、サーバーによって送信されたチェーンは次のとおりです：

Root-X-> CA1->サーバー

ここで、「Root-X」は「サーバーCA Xによって署名されたルート」です。レイジークライアントは、そのチェーンを2回検証しようとします。

最初の試みは、チェーンにルートCAが含まれているという前提に基づいています。クライアントは自身のルートCAのリストで「Root-X」を見つけられないため、これは失敗します。
2番目の試みは、チェーンにルートCAが含まれるないとの仮定に基づいています。クライアントは、ルートCAでRoot-Xの発行者をスキャンします（これが重要なポイントです）。何も見つからないため、失敗します。

サーバーから送信されたチェーンを検証するために、クライアントは少し遅延が少なく、独自の信頼されたCAのセット内でCA1の発行者を見つけようとする必要があります。これには3番目の前提が必要です。つまり、サーバーから送信されたチェーンにはルートCAが含まれていますが、「正しいもの」は含まれていません。

上記のように、失敗したSSLクライアントは「遅延クライアント」であると思います。確認するには、クライアントとしてInternet Explorerに接続してみてください。 IEの欠点はすべてありますが、証明書の検証に関しては面倒ではありません。 IEは、サーバーから送信された証明書、独自のストアにある証明書、およびダウンロードできる証明書からチェーンを再構築しようとします。特に、すべての証明書には、発行者の証明書（それは Authority Information Access 拡張の一部です）IE（そして、実際にはWindows全般）は、そのようなURLを喜んで追跡し、収集します中間CA（厄介なループを回避するために、HTTPSではなくHTTPのみ）。

このようにして問題が実際に遅延クライアントであることを確認できた場合、考えられる回避策は次のとおりです。

サーバーから送信されたチェーンを変更して、自己署名ルートが含まれるようにするか、単にCA1で終了するようにします。
「サーバーCA X」証明書を信頼できるCAとしてクライアントにインストールします。
遅延しないようにクライアントを変更/構成します。

もちろん、実際の証明書を見ずに評価するのが難しい他の方法でチェーンが正しくない可能性は十分にあります。パス検証アルゴリズムは複雑であるため、クライアントを満足させない別の拡張機能が存在する可能性があります（たとえば、1つの証明書が、SSLクライアント実装がチョークしたName Constraints拡張機能を使用している可能性があります）。おそらく、クライアントは怠惰ではありませんが、パス内のすべての証明書の失効ステータスを確認するように要求し、一部のCRLまたはOCSPレスポンダは古くなっているか到達不能です。証明書の検証が失敗する可能性のある方法は何百もあります。

mr.spuratic · Answer

提供されたチェーンにはルートを含めないでください、ルートを含める必要がある場合、クライアントはそれを無視する必要があります。 X.509信頼の重要な機能は、既知のルート（または trust anchors ）が必要なことです。これはあなたの問題の原因ではありません。順序が逆になり、サーバー証明書が最初になり、その後に署名者（および必要に応じて署名者など）が続く必要があります。これはmightで問題を引き起こします一部のプラットフォームですが、読んでください。

現在のクライアントは、DN（発行者の証明書名）によってチェーンを追跡することに依存しなくなりました。証明書（認証局キー識別子）の [〜＃〜] akid [〜＃〜] で始まり、親は一致する [〜＃〜] skid [〜＃〜] 。 SKID（サブジェクトキー識別子）は（統計的に）一意の識別子であることが意図されており、通常は公開鍵のハッシュから派生しますが、そうである必要はありません。検証の目的では、これは単に不透明な識別子です（つまり、検証では再計算されず、値を比較するだけです）。人間が読める名前は変わっていませんが、識別子が変わったようです。

チェーンのチェックはサーバー証明書から開始し、ルートの「トップ」に向かって実行する必要があります。これは通常「アップ」です。これは、チェーンが提示される順序と同じです。各証明書は、その署名者（CNおよびSKID）のみを「認識」し、階層については何も知りません。

これは検証プロセスを少し拡張します：証明書チェーンチェック、そしてこれはOpenSSLを使用して典型的な検証プロセスを再現する例を示します： https://serverfault.com/questions/541262/ check-the-issued-and-expiry-dates-for-the-certificates-involved-a-certificate

別の考えられる問題は、「トップ」または「トラストアンカー」を構成するものです。一部のCAは自己署名ルート証明書（AKID == SKID）を持っています。一部のCAは相互署名ルートを使用しています（署名証明書は別のCAに属しています）。チェーンの追跡を停止する場所は、通常、特定の分類のCA証明書によって、クライアントキーストアのプロパティです。