web-dev-qa-db-ja.com

オフラインルートのAIA / CRLの場所

次の「 オフラインルートおよび中間認証局（CA）の構築に関するチェックリスト 」の回答を読みました。構築しようとしているシステムに基づいて1つの質問があります
これは、3つのドメイン/フォレスト（つまり、フォレストごとに1つのドメイン）を備えたWindows 2008システムです。これで証明書を使用したいと考えています。これは、単一の自己署名オフラインルームで使用できるはずです。

  • ROOT-CA =自己署名オフラインルート
  • DOM1IntRootは、Active DirectoryドメインDOM1.A.COMのCAです。
  • DOM2IntRootは、Active DirectoryドメインDOM2.A.COMのCAです。
  • DOM23IntRootは、Active DirectoryドメインDOM3.DOM2.A.COMのCAです。

信頼はなく、サブドメインもないので、DOM1IntRoot、DOM2IntRoot、DOM3IntRootにROOTで署名して、オフラインルートが1つだけ必要になります。
つまり、各ドメインにルートCA証明書をインストールする必要があることを意味します。これは Microsoft "Contosoのシナリオ例" から考えると、LDAP AIAの場所をすべてのドメインに存在する構成パーティション（この場合はDC = a、DC = com）と、いくつかの単一サーバーへのHTTPロケーション。ただし、CRL/AIAの場所が分かれている可能性もあり、矛盾しているようです。

それで私は上記の回答を読み、AIA/CRLを空白のままにしておくと言います。これは、DOM1IntRoot、DOM2IntRoot、DOM3IntRootがROOTのCRL/AIAを公開することを意味するようです

したがって、ROOTCAにCRL/AIAがある場合とない場合の2つの可能性のある答えがあります。 ROOTCAにAIA/CRLがある場合、AIAおよびCRLの場所のLDAP/HTTPおよびFILE URLに正確に何を指定する必要がありますか？これは正しいですか？

ldap:///CN=ROOTCA<CRLNameSuffix>,CN=ROOTCA,CN=CDP,CN=Public Key Services,CN=Services,DC=A,DC=COM
http://<SOMESERVER>/CertEnroll/ROOTCA<CRLNameSuffix><DeltaCRLAllowed>.crl
file://\\<SOMESERVER>\CertEnroll\ROOTCA<CRLNameSuffix><DeltaCRLAllowed>.crl

どこ <SOMESERVER>はIISを備えたサーバーであり、証明書を使用可能にします

オフラインルートサーバーの名前を使用していないことに注意してください。これは見たことがないので正しいですか。

ROOTCAにAIA/CRLがない場合、（たとえば）DOM1IntRootの取り消しをどのように公開しますか？

私は少し混乱しているので、この質問は完全に間違った仮定から始まっているかもしれません

ドメイン構造に少し情報を追加して、いくつかの質問を試してみます-DOM1.A.COMはクライアントが設定する場所です-DOM2.A.COMはDMZタイプのネットワーク保護ですDOM3-DOM3.DOM2.A.COMにのみアクセスしますが、DOM1のユーザーがリモートでDOM2にログインし、次にDOM3の別のリモートセッションにログインします。 DOM2からネットワークデバイスへの証明書（おそらくDOM3である必要がありますが、それはまだ議論されています）-DOM2とDOM3はインターネットから分離されています。DOM3はDOM2以外のすべてから分離されています

windowscertificatespublic-key-infrastructurecertificate-authoritycertificate-revocation
6
Ross

ルートCAがオフラインの場合、ルートCAはofflineです。ネットワークがありません。これは、CRLが公開されるたびに、接続されたホストにCRLを配置するためにmanual介入が必要であることを意味します。その時点で、必要に応じて手動でthree場所に配置できます。

"機関情報アクセス"（AIA）および "CRL配布ポイント"（CRLDP）拡張は、証明書に記述されている情報です発行元CA。その場合、これらの拡張は、下位CA（3つのサブドメインCA）に発行されたCA証明書に含まれています。各サブCAがルートからまったく同じAIAおよびCRLDPを受け取る必要はありません。ルートがldap://のフォレスト内の場所（DOM1.A.COM URL）をポイントするAIAおよびCRLDPでCA1の証明書を発行するように完全に調整できます。ここで、ルートCAのコピーを手動でプッシュします証明書とルートCAによって作成されたCRL。 CA2のDittoですが、今回はDOM2.A.COMの場所などを使用します。

ただし、おそらくHTTPを使用する方が簡単です。すべてのドメインからアクセス可能な場所にWebサーバーを配置し、ルートCAにhttp:// URLを使用してAIAおよびCRLDPを発行する証明書を書き込みます。プレーンHTTPは、署名されたオブジェクトである証明書とCRLに適しているため、いかなる種類のセキュリティも考慮せずに配布できます（HTTPSや証明書とCRLの公開の必要はありません）。

また、AIAはルートCAであるので、ルートCAにはあまり役に立ちません。検証は、検証する人がルートを信頼する場合にのみ機能しますapriori。 AIAは、あなたが知らない証明書を見つけるためのものです先験的、したがって、あなたが知らない証明書信頼先験的：非常に役立ちます中間CA、ルートCAにはまったく役に立たない。 Active Directoryのコンテキストでは、たとえば一部のGPOを介して、ルートCAを「信頼できる」ものとしてプッシュできます。

CRLの発行を自動化するには、ほとんどオフラインルートCAを使用できます。これは、定期的に生成されたCRLを出力するための本質的に一方向のチャネルがあることを除いて、オフラインのルートCAです。私はオーディオケーブルを介してそれを1回実行しました（サウンドとしてエンコードされ、反対側でデコードされます）。利点は、サーバーのオーディオインターフェイスの「アウト」ジャックが「イン」ジャック（「 「アウト」は緑色、「イン」はピンク）なので、ルートがまだオフラインであることを視覚的に確認できます。他の人々は、1組のワイヤーのみが接続されたRJ45ケーブルを使用しました。これは、帯域幅は優れていますが、視覚的に簡単に検査することができません。

とにかく、それは事の根本を変えることはありません、それはHTTPがあなたの人生をよりシンプルにするということです。

5
Thomas Pornin