web-dev-qa-db-ja.com

TLS：証明書の信頼チェーンにおける信頼の明確化

トラストストアに次のトラストチェーンがあるとします。

ROOT_CERT
|
|---INTERMEDIATE_CERT_1
     |
     |---INTERMEDIATE_CERT_2

INTERMEDIATE_CERT_2によって署名されたすべての証明書が信頼できることは知っていますが、次の説明も当てはまります。

a）ROOT_CERTによって直接署名された証明書は信頼されますか？

b）INTERMEDIATE_CERT_1によって直接署名された証明書は信頼されますか？

tlscertificatesopenssltrust
2
user2521119

はい、両方に。

通常、ルートはトラストストアにのみ存在し、リーフ証明書を提供するエンティティは必要な中間証明書も提供します。検証者は、リーフを信頼できるルートにリンクするチェーンを構築します（ルートが1つだけの場合は「信頼できる」ルート）信頼されています）。

もちろん、証明書には正しいキー使用制限などが必要です。 OCSP応答の署名にのみ使用される証明書は、証明書などを発行できません。

2
Z.T.

要するに：両方にはい。

説明

以下は非常に簡略化した説明です。詳細は以下にリンクされています。

CAが証明書に署名するとき、CAはWebサイトの公開鍵などに署名するだけでなく、実際には大量のメタデータに署名します。このメタデータ。証明書の有効期限などが含まれます。私たちの場合、これはX.509として定義されたデータ形式で保存されます。

また、特定の「制約」、つまり、証明書が実行できることに対する制限も含まれます。 Wikipediaの記事には概要が記載されています ですが、私たちのケースで重要なことは、その証明書が他の「（サブ）証明書」に署名できるかどうか、つまり「証明書」に署名できるかどうかも示しています。

ルートCAと中間CA /証明書の両方にこのセットがあります。したがって、他の証明書への署名が許可されます。

信頼の連鎖

次に、ブラウザが行うことは、Webサイトから提供された証明書を取得することです（https://example.com例）そして、いわゆる証明書チェーンを構築しようとします。ルート証明書に到達するまで証明書を取得します。あなたはすでにそれを描きましたが、私が話した最後の証明書を逃しました。これは通常リーフ証明書と呼ばれます。 （おそらく ツリーデータ構造 のため）

ROOT_CERT (isCA=yes)
|
|---INTERMEDIATE_CERT_1 (isCA=yes)
     |
     |---INTERMEDIATE_CERT_2 (isCA=yes)
         |
         |---LEAD_CERT valid for example.com (isCA=no)

明らかに、リーフ証明書は他の証明書に署名する権限を持っていない必要があります。

練習

実際には、これにより、CAが1つしかない場合には考えられない多くのことが可能になり、その後、直接署名されるリーフ証明書が得られます。例えば。 CAは販売インフラストラクチャを再販し、他の企業が中間証明書を使用して自社の証明書に署名できるようにする場合があります。 （ただし、技術的および法的事項は遵守する必要があります。たとえば、APIを提供するだけです。）

または、ルート証明書の秘密鍵は次のとおりです。通常は HSMs に保持されます。生産的な使用のために中間CAを使用するため、本当に問題が発生した場合は中間CAを切り替えることができます（中間CAが危険にさらされます）。

または、あるCAが別のCAのルートに署名する cross-signing などのクレイジーなことを行うこともできるので、ブラウザーでの受け入れが速くなります。暗号化しましょう たとえば、これを実行しました –また、「実際の世界」の例を見たい場合は、中間証明書の興味深い文書化された構造も持っています。

もっと詳しく

詳細をお読みになりたい場合は、以下をご覧になることをお勧めします。

1
rugk