オフラインルートを使用するWindowsPKI（おそらくOpenSSLを使用）-可能ですか？
2層PKIをセットアップしようとしていますが、たくさんの質問があります。 ADにはトゥームストーンの制限があるため、ルート（オフラインになる）をADの一部にすべきではないと想定しています。私は正しいですか？
私が検討していたセットアップは、1つのルートCAと複数の中間体（さまざまな目的のため）でした。したがって、ルートはスタンドアロンのWindows標準またはLinux + OpenSSLである可能性があります（これが可能/推奨されるかどうかはわかりません）。中間CAの1つは、ADの一部になります（自動登録など）。
だから、私の質問は次のとおりです。
ルートをスタンドアロン（ADの一部ではない）にすることはできますか？これにより、証明書チェーンなどに問題が発生しますか？
ルートはLinux + OpenSSLにすることができますか？これは管理が難しいでしょうか？
または、トゥームストーン制限の回避策はありますか？
ありがとう。
参照： http://blogs.technet.com/b/askds/archive/2009/10/13/designing-and-implementing-a-pki-part-ii.aspx [1] および http://pki-tutorial.readthedocs.org/en/latest/advanced/index.html [2] 参照用。
Microsoft オフラインルートCAマシンがドメインのメンバーであってはならないことを指定します したがって、問題が発生することはなく、ADトゥームストーンの有効期間の問題全体が問題になります。ウィットに：
ルート証明機関に使用するWindowsを実行するサーバーをセットアップします。サーバーはドメインのメンバーであってはならず、ネットワークから切断され、物理的に安全である必要があります。
私はOpenSSLとWindowsCAとの広範な相互運用性テストを試みていませんが、原則として、正常に動作するはずです。これはすべて標準ベースのPKIです。確かに、私はOpenSSLを使用してWindowsサーバーの証明書に何度も署名しましたが、悪影響はありませんでした。 OpenSSLツールを使用して第2層CAの証明書を発行することに慣れている限り、特定の管理上の問題は発生しません。
あるツールセットと別のツールセットを使用してルートCAを展開しても、特に価値はありません。あなたは確かにそうすることができます、しかし私はそれがあなたに何かを「買う」方法がわかりません。
2層PKIをセットアップしようとしていますが、たくさんの質問があります。 ADにはトゥームストーンの制限があるため、ルート（オフラインになる）をADの一部にすべきではないと想定しています。私は正しいですか？
正しい。オフラインルートCAはワークグループコンピューターになります。これは、発行元のCA証明書を更新してCRLを公開する目的でのみオンにします。通常、ルートの公開鍵/証明書をGPOを介してすべてのクライアントに配布します。
私が検討していたセットアップは、1つのルートCAと複数の中間体（さまざまな目的のため）でした。したがって、ルートはスタンドアロンのWindows標準またはLinux + OpenSSLである可能性があります（これが可能/推奨されるかどうかはわかりません）。中間CAの1つは、ADの一部になります（自動登録など）。
1つのPKIでWindowsとLinuxを組み合わせて使用することはしません。そうすることで得られるメリットはなく、PKIの管理がより複雑になるだけです。