中間CAは自己署名ルートCAのように信頼できますか？
X.509仕様の制限内で、中間CAを特定の目的のために信頼できるものとしてマークすることは可能ですか？ルートCAと同様に、VPN、HTTPSなどのサーバーキーを検証するには
VPNクライアントにはすべて、信頼されたCA証明書を明示的に提供する方法があり、これを使用してVPNサーバーの信頼性を確認します。ルートCA証明書を提供する限り、これは期待どおりに機能します-証明書は信頼されます。 （中間証明書は、TLSハンドシェイクの一部として提供されます。）
ただし、私は中間CAを使用しており、ルートCAの代わりにその証明書を提供したいと考えています。 X.509の私の理解では、それはうまくいくはずです：
VPNサーバーのキーは中間CAによって署名されており、私がX.509を理解している限り、信頼されたチェーンを確立するために必要なのはこれだけです。
しかし、実際には機能しません。VPNクライアントが接続しません。
VPNに加えて、802.1X/EAPOL認証と複数のクライアントでこれを試しましたが、同じ結果が得られました。クライアントにルートCA証明書を提供すると機能します。私の中間CA証明書を提供しません。
それは仕様によるのですか、それともほとんどの実装がどのように機能するのですか？
（私はTLSベースのVPNを使用していますが、802.1XとTTLSでも試したため、特定のVPNクライアント/サーバーアーキテクチャではなく、TLSまたはX.509に関連しているようです。）
更新：私は好きです OpenSSLコミット 非自己署名CA証明書をトラストアンカーとして追加することを実装します。残念ながら、これはどのリリースバージョンにもまだ含まれていないため、コメントで提案されている回避策はすべて適用されます。
Update 2：OpenSSL now contains this option リリースバージョン1.0.2以降。コマンドラインクライアントに対応するフラグはpartial_chainで、プログラムフラグはX509_V_FLAG_PARTIAL_CHAINのようです。
さらに、私は最近、Javaでサーバー証明書を検証する必要がありました。少なくとも、Sun JSSEプロバイダーのSSL実装のJDK 1.8バージョンでは、デフォルトのTrustManagerにリーフ証明書を追加すると、特別な構成なしで機能し、検証は次のように成功します。ルートCAが提供されている場合。
root CAは実際には幻想です。 X.509 には、トラストアンカーがあります。トラストアンカーは、ほとんどの場合、名前と公開鍵であり、アプリオリであり、信頼できるものです。その名前とその公開鍵を「証明書ファイル」（従来は自己署名）として表現することは、トラストアンカーを一連のバイトとして保持するための便利な方法にすぎません。
X.509によると、CAが「中間」であるのは、事前に信頼していない場合のみです。 CAの固有のプロパティではありません。ソフトウェアに、CAをトラストアンカーと見なすようにする必要があります。考えられるトリックの1つは、関連データ（CA名と公開鍵）を（意図的に）自己署名証明書として再エンコードすることです。自己署名は単なる伝統であることに注意してください。証明書のファイル形式には署名の必須フィールドがあるため、ほとんどの場合そこにあります。 「ルート」CAの場合、このシグネチャは重要ではありません（セキュリティ面で何も購入しないため、このシグネチャを検証しても意味がありません）。したがって、ルートCA証明書を使用するアプリケーションは、署名が「自己」であることをほとんど確認しません。
したがって、「中間CA」の名前をSubjectDNとIssuerDNの両方として使用して、カスタムの「自己署名」証明書を作成できます。署名には、ほぼ適切なサイズのランダムなジャンクバイトを入れてください（2048ビットの署名では256バイト）。次に、この疑似自己署名証明書をルートとして設定してみてください。VPNで動作する可能性があります。または、独自のルートCAを作成し、中間CAに追加の証明書を発行します（そのために中間CAの協力は必要ありません。名前と公開鍵が必要で、これらは中間CA証明書にあります） ）。
証明書の検証に関するRFCによると- RFC 328 -セクション6.2：
1つ以上の信頼できるCAの選択は、ローカルの決定です。システムは、信頼できるCAのいずれかを特定のパスのトラストアンカーとして提供できます。パス検証アルゴリズムへの入力は、パスごとに異なる場合があります。パスの処理に使用される入力は、特定のトラストアンカーに与えられたトラストのアプリケーション固有の要件または制限を反映する場合があります。たとえば、信頼できるCAは、特定の証明書ポリシーに対してのみ信頼される場合があります。この制限は、パス検証手順への入力を通じて表現できます。
ただし、たとえば、CA証明書のポリシー拡張でCRLまたはOSCPによる検証が必要であることが示されている場合、深刻な痛みを伴う可能性があります。それができない場合、アプリケーションが正当にハングする可能性があります。ルートCAを見つけて、このプロセスの一部を確認します。たとえば、CRLがルートCAによって署名されている場合があるため、ルートCAがトラストストアで使用できない場合、アプリケーションは状況に対処できない可能性があります。
RFCによると、トラストアンカーとして機能する中間CA証明書を設定でき、機能する一連のポリシー設定を作成できるはずです。しかし、あなたは「多分」の怪しげな領域に入ったと経験から言うことができます。ここでは、一般的ではない非標準の構成を提案しています。ほとんどの場合、ルートCAはここで使用されます。なぜなら、それはそこにある最高レベルのものであり、長期的には、トラストアンカーのプロビジョニングは通常、人々が最高の信頼できるパワーで満足し、新しいものを追加する必要がないように十分に毛深いです。時間の経過とともにアプリにCAを追加します。ポリシー拡張を正しく設定してアプリを動作させる領域はAdvanced PKI Vodooです。エラーメッセージはばかげていることが多く、技術サポートが最小限であり、正しく機能するようになるまでにかなりの時間がかかる場合があります。
意図的な設計決定ではなく、実装の欠点である可能性があります。
概念的には、トラストアンカーのセットに中間CA証明書を追加する場合（信頼するため、それらによって署名されたものを受け入れるCA）、クライアントはそのCAが署名した他の証明書を受け入れることをいとわないはずです。チェーンのルートではありません。これは、クライアントが動作するための非常に合理的な方法です。ただし、これはあまり一般的ではなく、アプリケーション開発者が考慮しなかったユースケースである可能性があるため、コードが偶然サポートしていない場合があります。 C'est la vie。
システムは意図したとおりに機能しています。定義により、中間証明書は、クライアントとルートCAの証明書間の信頼関係によって発行され、信頼関係に依存しています。 ルートCAは自己署名され、クライアントによって信頼されています。中間CAはルートCAによって署名されています。
簡単に言えば、中間CAは「ねえ、私はCAです。あなたが既に信頼しているルートCAによって署名されているので、あなたは私を信頼できます」と言います。次にクライアントは、ルートCAを本当に信頼しているかどうかを確認し、その信頼関係が確立されている場合は、証明書階層（証明書チェーン）が検証され、証明書を使用できます。
特定のフィールドとメソッド（証明書テンプレート、OID、Enhance Key Usageフィールドなど）を使用することにより、特定の証明書の用途を指定できますが、スキーム全体は、証明書チェーンのルートを信頼するクライアントに依存しています。