プライマリ DC で Windows 2003 AD 証明書サービスが失敗しましたか?

Question

まあ、確かに、あなたはある種の混乱に陥っています。まず、Exchange サーバー、DC、または他の役割を持つマシンに CA をインストールしないでください。これは災害の引き金となります。CA の適切な設定は、ルートとなるサーバーを選択することです (できればオフラインルートCA）、および他のニーズのための中間 CA として機能する 2 番目のサーバー。

このようにすると、中間 CA に何か問題が発生した場合 (自分の CA に起こったように)、ルート CA からそれを取り消して、あまり問題なく新しい CA を構築できます。

現在、展開した CA の種類 (スタンドアロンまたは AD 統合) が指定されていませんが、説明されている問題から判断すると、AD 統合型であると推測されます。

上記が正しいと仮定すると、状況は次のようになります。証明書を発行するために使用されていた CA が現在無効になっています。その CA は、すべてのマシンで自動証明書登録に使用されており、さらにこれらの証明書を認証に使用しています。

さて、システムを適切にセットアップしたら、ルート上の古い中間CAを失効させ、新しいCAを公開します。CRL別の中間 CA をインストールして、証明書を再発行します。また、ADSI エディターを使用して、登録サービスの LDAP エントリを再ターゲットする必要がある場合もあります。

あなたの場合、この方法ではこれを行うことはできません。移住（ルートCAにリンクされた秘密鍵にまだアクセスできると仮定した場合、または回復できる) または、新しい権限で最初からやり直します。

新しい権限を作成することにした場合は、次の手順を実行してください。

ルート CA と中間 CA に異なるサーバーを使用できない場合は、少なくとも 1 台のマシンをルート専用にしてください。OpenSSL を使用してルート CA を作成し、その CA を使用して AD 統合中間 CA に署名することもできますが、そのルートに対して新しい CRL を手動で生成する必要があることに注意してください (ただし、適切に保護されている場合は、同じマシンにそのルートをインストールできます)。新しいルートと古いルートが混在しないように (問題や混乱の原因になることがあります)、新しいサーバー名を使用することをお勧めしますが、必要に応じて同じ名前を再利用できます。
新しい CA 階層を作成したら、グループポリシーを使用して、新しいルートをドメイン内のすべてのマシンに配布します。ルートを「信頼されたルート証明機関」ストアに追加し、中間 CA を「中間証明機関」ストアに追加します (2 番目の手順は主に予防措置です)。
古い CA をローカルで強制的に信頼できない状態にします。そのためには、グループポリシーを使用して、パブリック証明書を「信頼されていない証明書」ストアに追加します。
登録サービスを新しいサーバーに再ターゲットします。そのためには、adsiedit を使用して [構成] / [サービス] / [公開キーサービス] / [登録サービス] に移動し、古い CA サーバーへの参照を削除します (新しいサーバーはすでにそこに登録されているはずです)。
必要なすべての証明書を再発行します。CA を適切に設定していれば、自動登録を使用する証明書は新しい CA から自動的に再生成され、古い証明書は破棄されます。これらの証明書が暗号化に使用されていないことが確実でない限り、クライアントマシン/アカウントから証明書を削除しないでください。

(追記: 最初にこれを適切に設定しなかったことについて、あまり落ち込む必要はありません。CA 管理は難しく、間違えることは非常に簡単です。MS は、証明書サービスのインストールを非常に簡単かつ迅速にすることで、さらに簡単に間違えるようにしました。何をしているのかを正確に理解していない限り、最初は間違えてしまうことはほぼ間違いありません)。

Answer 1