状況: 共有ルート CA と複数の中間 CA を持つ内部 PKI があります。中間 CA によって発行されたものはすべて相互に信頼されるようにしたいです。ほとんどのプログラム/言語で問題なく実行できる方法はありますか?
私の現在の理解では、これはではない簡単に可能ですが、私の理解に誤りがあるのではないかと疑問に思っています。
したがって、次のようなプログラムがあるとします。
- 共有ルート => 最初の int の信頼チェーンを備えたファンキーで新鮮な
- 共有ルートの信頼チェーンを備えた非常にクリーンな状態 => 2 番目の int
そして、これら 2 つの間には相互信頼が絶対に必要なので、ルート => 1 番目とルート => 2 番目を互いに結合した大きな CA 証明書を作成するしか選択肢はありませんか? それとも、ルートを含むチェーンを何らかの方法で作成できますか?
OS レベルの信頼ストアにルートを追加するか、コンテナーの場合は特定のコンテナーの信頼ストアに追加することで、これらすべてを回避できますか? (下/etc/pki/ca-trust/source/anchorsなど)
2番目の考えは、おそらくこれは悪い考えですが、すべてが内部にあり、CRLがあるため、のみルート CA を使用し、CA レベルの証明書ではなく TLS 証明書を厳密に監視し、CRL をクリーンな状態に保つだけです。
どこかで定義された特定のエンドポイントで CRL と CA を公開した場合、ソフトウェアが独自のチェーンを構築できるようにする方法はありますか?
答え1
あなたの質問を正しく理解しているか、またはあなたがその概念を正しく理解しているかはわかりませんが、
- 証明書は互いに信頼しません。代わりに、TLS クライアントはいくつかの証明機関を信頼し、そこからサーバー証明書への信頼を導き出します。
- TLS クライアントは、基本的に、期限切れでないこと、サブジェクトが一致することなど、期待に一致する限り、信頼できる CA によって発行されたすべての証明書を信頼します。TLS クライアントは、信頼できる CA までの信頼チェーンを構築できる必要があります。したがって、TLS クライアントは、通常 TLS ハンドシェイク内で送信される関連する中間証明書を認識している必要があります。
したがって、どの中間 CA が使用されたかに関係なく、すべてのクライアントがすべての証明書を信頼するようにするには、a) クライアントがルート CA を信頼し、b) サーバーが TLS ハンドシェイク中にサーバー証明書に加えて中間 CA を送信する必要があります。
参照SSL 証明書フレームワーク 101: ブラウザは実際にどのようにして特定のサーバー証明書の有効性を検証するのでしょうか?。