X.509証明書チェーンはどれくらいの長さにできますか？
通常、特定のSSL/TLS WebサイトのルートCA、中間CA、および3番目のCAの証明書チェーンのみが表示されます。しかし、X.509証明書チェーンを3レベルより深くすることはできますか？それらの長さに制限はありますか？他のルートCAや中間CAと相互接続されている長いチェーンを使用すると、信頼チェーンがより強力になり、分散化され、単一点障害が発生しにくくなりますか？
これは okTurtlesのDNSChain —分散型の blockchain -ベースのDNSネットワークの背後にある考え方のようで、CAの集中型ネットワークに依存する必要があるという問題を解決します。したがって、中間者（MitM）攻撃に対して耐性があります。
証明書チェーンの長さに課される技術的/仕様上の制限はありません。 （ただし、CAの証明書チェーンの長さにare X509v3属性がありますpolicy-ベースの制限があります。BasicのpathLenConstraintフィールドを参照してください制約、 RFC 5280、セクション4.2.1.9 。）
チェーンが長くなると、クライアントを検証するときに検証作業が少し増え、チェーン内の各証明書を構築してウォークし、検証する必要があります。しかし、それは必ずしも悪いことではありません。ただし、ある時点で、チェーン内の証明書の1つが期限切れになるか、取り消される可能性が高くなります。多くの証明書チェーンは、only onee.g。リーフ証明書（サーバー/クライアント）から信頼されたルートCAへのパスがあるように構築されています。そのパスが途中で無効にされた場合、そのリーフ証明書は信頼できると見なされません。
CAが行う方法はいくつかあります相互認証。これは、2つのCAが相互に信頼していることを示します（ RFC 5280、セクション3.2）で説明します ）。このメカニズムの使用法がどれほど一般的/広く普及しているかはわかりません。 someの種類の委任が可能ですが、完全に分散化されているのではなく、非常に階層的で集中管理されています。
お役に立てれば！
理論的には、X.509チェーンの長さは無制限です。 Basic Constraints 拡張は、チェーンごとの制限を適用できます。これは主に、サブCA証明書を発行することに同意しているが、そのサブCAがエンドエンティティ証明書のみを発行するように制限したいCAに使用されます。
実装には制限がある場合があります。実際、注意深く作成された証明書を使用すると、パス構築アプリケーションを探索できますn！深さの潜在的なパスn、および階乗はかなり速く上昇するため、これは巨大なサービス拒否攻撃につながる可能性があります。同様に、実装は比較的短い最大長を課す傾向があります（私は自分の実装に「8」を使用したことを知っています）。
大まかな概念的な用語では、委任時に信頼はかなり速く希釈されます。 CAがサブCAに証明書を発行するとき、サブCAの公開鍵がそのサブCAによって所有されていることを表明するだけでなく、親CAに代わってその種の検証を実行する権限も与えます。 CAはエンドエンティティの証明書を発行するときに、そのアイデンティティをチェックします。サブCAに証明書を発行するときは、サブCAがだまされないようにまた確認する必要があります。 3番目のレベルでは、CAはサブCAが騙されないようにし、だまされやすいサブサブCAに証明書を発行しないようにする必要があります。
したがって、反射はチェーンを長くするのではなく短く保つようにすることです。
「単一障害点」の式に注意してください。これは通常、運用の継続性に適用されます。ここでは、セキュリティについて説明します。作成する他のパスの数に関係なく、単一の不正なCAがセキュリティを侵害します。これは、SPOFルールとは逆になります。冗長性を追加することでSPOFを回避しますが、認証の場合、関係するCAは本質的に物事を危険にさらすことができます-さらにミックスに追加するCAは、より脆弱になります。