web-dev-qa-db-ja.com

クロス署名されたCAと証明書を適切に作成して使用する方法

クロス署名されたCAを使用して環境を作成し、すべてのopensslを使用して、CAの1つに対して発行された証明書を確認しようとしています。私がこれまでに得た最高のものは、検証中にopensslを無限ループに入れることです（ループはレベル100で終了します）。

作成したすべての証明書を公開しました 。さて、モデルを構築するために このOasisドキュメント に主に基づいて、私が行っている多くの仮定があります。ここに私の仮定があります：

  1. 機関＃1と＃2から自己署名され、相互署名された4つの証明書が必要です。機関＃1は機関＃2によって署名され、逆も同様です。
  2. 実際に使用されるサブジェクト（DN）は2つだけです（自己署名のために機関が使用するのと同じサブジェクトは、別の証明書ではありますが、他の機関が署名したものです）。
  3. 4つの証明書はすべて、エンドユーザーの信頼の一部である必要があります。
  4. 自己署名証明書と相互署名証明書の両方で、同じ機関が使用する鍵 同じである必要があります
  5. AKIは使用しないでください（「すべきではない」という言葉は強すぎるかもしれませんが、使用しても害はありません。同じキールールのため、問題ではありません）
  6. クロス署名証明書にCA：TRUEを設定してみましたが、同じ結果が得られました。

クロス署名についての私の理解は、検証プロセスに代替パスを提供することです。 opensslループが表示されることを考えると、毎回クロス署名された証明書を選択しているようです。したがって、問題の核心は、両方のサブジェクトが同じであることを考慮して、相互署名された証明書よりも自己署名された証明書を優先する検証プロセスをどのようにするのでしょうか。

これが テストリーフ証明書 です。openssl verifyで確認します。

[vps@druid]~/ws/EF/pki3$  openssl verify -verbose -CAfile cas.pem cert.pem 
cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 2
error 2 at 100 depth lookup:unable to get issuer certificate
public-key-infrastructureopensslx.509
12
Pawel Veselov

わかりました、これは私がこれまでに思いついた中で最高です。

深度処理の問題は、OpenSSLの問題にすぎないと私は思います。適切なパスを構築できないのは良くありません。 RFC-5280、セクション6.1 は言う：

証明書は、将来の認証パスに複数回出現してはなりません。

OpenSSLはおそらくそれに違反しています。ただし、パスの作成方法については RFC-528 には説明がありません。ただし Sec 3.2 を除きます。パスは各チェーンの最後にsingle自己署名CAで終了する必要があるという提案があります（ただし、検証チェーンに信頼アンカーを含めてはならないという記述と矛盾しますが、トラストアンカーには中間証明書が含まれる場合があり、これによりポストチェーン側に複数の証明書が含まれるようになり、OpenSSLは無限ループになります）。いずれにせよ、OpenSSLが行っていることに同意しません。

また、私が話していたのは、クロス署名された証明書だけでなく、相互にクロス署名された証明書でもあるということです。明らかな違いは、通常の相互署名はそのような循環依存を作成しないことであり、別のCAによって署名された1つのCAからのトラストアンカーを持つことによって達成されます（検証者の観点から、これは信頼された仲介者と同じケースです） 、AFAIU）。

OpenSSLで動作させる方法は、相互署名された証明書を信頼リストに追加せずに、キーホルダーが生成する中間証明書の一部として提供することです。

すべての自己署名をtrust.pemに入れ、すべてのクロス証明書をuntrust.pemに入れると、中間エラーが発生しますが、検証プログラムは機能します（すべてのツリーが正常にビルド/検証されるわけではないので意味があります）。

これは両方のルートが存在する場合です：

$  openssl verify -verbose -CAfile trust.pem -untrusted nontrust.pem Host1/cert.pem 
Host1/cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 1
error 24 at 1 depth lookup:invalid CA certificate
C = US, O = Excelfore, OU = PoC, CN = xl4 CA 2
error 24 at 2 depth lookup:invalid CA certificate
OK

これは、1つまたは別のルートのみが存在する場合です。

$  openssl verify -verbose -CAfile ca1/ca1.pem -untrusted nontrust.pem Host1/cert.pem 
Host1/cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 1
error 24 at 1 depth lookup:invalid CA certificate
C = US, O = Excelfore, OU = PoC, CN = xl4 CA 2
error 24 at 2 depth lookup:invalid CA certificate
OK
$  openssl verify -verbose -CAfile ca2/ca2.pem -untrusted nontrust.pem Host1/cert.pem 
Host1/cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 1
error 24 at 1 depth lookup:invalid CA certificate
OK

これは、クロス署名の最も優れた部分であり、CAを核にしても、元の証明書が機能していることを示しています。

[〜＃〜]ただし[〜＃〜]

RFC-5246、セクション7.4.2 TLS 1.2を文書化すると、サーバーはクライアントに提示するチェーンは1つだけであると述べています（逆も同様です）。クロス署名された証明書をトラストストアの一部にすることができない場合、クライアントはオプションがあることを確認する側に複数のチェーンを提供する必要があります。したがって、はい、それは理論的には機能しますが、少なくともOpenSSLの実装では、SSLでは機能しません（他の検証プロトコルで機能する可能性があるため、確認しませんでした）。

3
Pawel Veselov

私の答えには多少の当て推量が含まれていると言いましょう。私の推測では、2つのリーフ証明書を発行し、一方の証明書の発行者が他方を指しており、その逆がループを引き起こしていると考えられます。

私はあなた自身の問題を再現しようとはしませんでしたが、クロスサインをしました。 LEサイト（ LEによるクロス署名 ）とヒントから、クロス署名証明書の発行と使用に成功しました。私の目的は、CAルートの復元力ではなく、CAルートのロールオーバーでした。あなたの役割がCAである場合、それは基本的に、あなたが達成しようとしたことと大差ありません。重要な要素は次のとおりです。

  • 件名フィールドは同一でなければなりません（上記も参照）
  • キーは同一でなければなりません（上記も参照）
  • 証明書には別の発行者が必要で、アプリケーションのように1つは自己署名できます

LEリンクの一部と同様に、クロス署名された中間証明書と1つの新しいルート証明書を作成しました。永続的な中間証明書（PATHLEN：0）は、サブジェクトとキーが同一であるため、どちらが重要でもない2つの相互署名付き証明書のいずれかによって署名されます。ヒント：両方のクロス証明書のCSRを再利用して、サブジェクトが間違っていないようにします。クロス署名された（temp。）中間証明書で、PATHLENを1に設定しました（0にはできません！）

それを非常に明確にするために：

  • パス1（古いルート）：リーフ証明書、パーマ。中間証明書、一時。中間証明書、「古い」ルート証明書
  • パス2（新しいルート）：リーフ証明書、パーマ。中間証明書、「新しい」ルート証明書

SANで開始し、好きな日付で開始/終了できます。「古い」ルートパスの中間証明書（一時またはロールオーバー）の有効期間は5年、「新しい」ルート10年。「新しい」ルート証明書をインポートした後、短い（4→3）パスがFirefoxによってすぐに使用されました。私の場合、Webサーバーに3つの証明書をロードする必要があります：リーフ証明書、パーマ中間証明書、一時。中間（「古い」root/temp/roll-over）証明書。

OpenSSLは、有効なパスについてリーフ証明書をテストするように私を失望させませんでした。パスのルートにCAfileを使用してOpenSSLの検証ツールを使用しましたが、使用した中間証明書は信頼できません。古いルートと新しいルートへの両方のパスをこの方法で確認できます。

エンドユーザー（非CA）として、復元力が必要な場合は、1つのCSRと連携して、2つのCAからリーフ証明書を取得（注文）し、2つの証明書をWebサーバーにロードします。発行CA。合計で4つの証明書です。

0
HanC