web-dev-qa-db-ja.com

既存のCAに影響を与えずに新しいルート/エンタープライズCAを追加しますか?

新しいAD統合エンタープライズ認証局構造のインストールを検討していますが、誰かがすでにCAを作成していることを発見しました(ほとんどが内部WebサイトのSSLに使用されています)。

オフラインルートを作成したり、フォールトトレランスのために複数の下位CAを承認したりするなど、ベストプラクティスに従って新しい構造を構築したいのですが、既存の機能を台無しにしたくありません。どうやら既存のルートCAを下位に変えることはできないので、除外されています。

新しいルートを既存のルートに触れずに、単に他の場所にインストールできますか? (または、おそらく既存のCAに新しいルートの権限をクロスサインしますか?)

7
ewall

同じシナリオを扱ったので、私が取ったアプローチの概要を次に示します。

新しい環境を稼働させますが、証明書を発行する機能は与えないでください-capolicy.infでLoadDefaultTemplates=Falseを使用します。

デバイスはまだテンプレートを発行しないように設定されていますが、すべてを新しい環境、AIAの場所、CRL配布などで解決します。エンタープライズPKIスナップインですべての状態を確認します。

次に、準備ができたら、既存のCAの構成を変更して、特定のテンプレートに対する証明書の発行を停止します。あなたはまだサーバーを殺していません、ただ新しい証明書の発行をやめるようにそれを告げるだけです。それらの同じテンプレートを、新しい環境の許可された発行ポリシーに追加します。

次に、テンプレート管理ツールで「証明書の再登録」オプションを使用して、そこに証明書があり、自動登録されているテンプレート(ユーザー、コンピューター、およびドメインコントローラーの証明書)を使用します。これにより、テンプレートバージョンがバンプされ、自動登録のパルス時に新しいインフラストラクチャから新しい証明書が取得されます。

これはそれらの証明書についてはカバーしますが、Webサーバー証明書の場合は残念ながら手動プロセスになります。それぞれに再発行し、リスナーを新しい証明書に変更します。

すべての証明書が再発行されたことをかなり確信したら、古いCAを無効にしますが、まだ役割を削除しないでください。 CAの構成内のすべてのAIAまたはCRL配布ポイントを削除し、それらの場所からファイル/オブジェクトを削除するという行に沿って何かを行います(おそらくLDAPが主なものですが、httpおよびsmbもチェックが必要です)。数週間問題を待ちます。何かが壊れた場合、削除したAIA/CRLポイントを再度追加し、必要に応じて再公開できます(certutil -dspublish)。

古いCAを使用していないことに満足したら、役割を削除してから、Active Directoryをクリーンアップします。 AIA、CRL、Delta CRLは手動で削除する必要があります。これは、エンタープライズPKIスナップインの[ADコンテナーの管理]オプションで実行できます。

8
Shane Madden

この記事によると: http://thedailyreviewer.com/server/view/multiple-enterprise-certificate-authorities-10276898 Microsoftはこれを許可していますが、推奨していません。古いサーバーをオフラインにして最初からやり直すことを選択したこの選択に直面しました。私たちが最初に行ったことの1つは、SSLを積極的に使用しているユーザーに証明書を再発行することでした。

0
uSlackr