Windows Server 2008 R2 上の旧 CA（AD CS）を、新しい CA に移行した後、どこまで削除してよいのか迷うことが多いです。本記事では「AD CS をアンインストールしても証明書テンプレートは消えない理由」、旧 CA が故障している場合に Active Directory から整理すべき AIA/CDP/Enrollment Services/NtAuthCertificates、さらに KRA（msPKI-PrivateKeyRecoveryAgent）の扱いまで、実務目線で解説します。
結論：AD CS を削除しても「証明書テンプレート」は消えない
まず一番重要なポイントから整理します。
- CA サーバーから「Active Directory 証明書サービス（AD CS）」役割を削除（Certificate Services をアンインストール）しても、証明書テンプレート（Certificate Templates）自体は削除されません。
- 理由はシンプルで、テンプレートは CA サーバーのローカルにあるものではなく、Active Directory（構成コンテナー）側でオブジェクトとして管理されているためです。
- 変わるのは「旧 CA がそのテンプレートを発行していた」という発行の紐づき（どの CA が発行対象として有効化しているか）であって、テンプレート定義そのものではありません。
テンプレートが残ることで起きること・起きないこと
| 観点 | AD CS アンインストール後 | 補足 |
|---|---|---|
| テンプレート定義（オブジェクト） | 残る | 必要なら別途「テンプレートを削除」操作が必要（通常は削除しない） |
| 旧 CA が発行できるテンプレート一覧 | 意味を失う | 旧 CA が無いので発行はされない。新 CA 側で発行設定が必要 |
| 旧 CA が過去に発行した証明書 | 残る（証明書自体は各所に存在） | 証明書の有効性検証には CRL/AIA の参照が必要なケースがある |
| 自動登録（Autoenrollment）の動作 | 環境次第 | 新 CA でテンプレート発行・権限・GPO が整っていれば新 CA に寄る |
AD CS の「どこに何があるか」を理解すると廃止が安全になる
旧 CA の廃止で事故が起きやすいのは、「サーバーを消す」こと自体よりもAD に残る参照（公開情報）が混ざり続けることです。まず全体像を押さえましょう。
AD CS に関連する代表的な格納場所（構成コンテナー中心）
| 要素 | 主な格納場所 | 中身のイメージ | 旧 CA 廃止での扱い |
|---|---|---|---|
| 証明書テンプレート | 構成コンテナー（Certificate Templates） | テンプレート定義（拡張キー使用法、鍵長、SAN、発行要件など） | 通常は残す（発行 CA を入れ替える） |
| Enrollment Services | 構成コンテナー（Enrollment Services） | 「この CA が発行できるテンプレート」等の公開情報 | 旧 CA を消すなら削除対象 |
| Certification Authorities | 構成コンテナー（Certification Authorities） | CA 証明書の公開（参照） | 旧 CA を消すなら整理対象 |
| AIA（Authority Information Access） | 構成コンテナー（AIA） | 上位 CA/CA 証明書参照。チェーン構築に関係 | 旧 CA 参照が不要なら整理対象 |
| CDP（CRL Distribution Point） | 構成コンテナー（CDP） | CRL/デルタ CRL の公開（参照） | 旧 CA 証明書が残る間は慎重（後述） |
| NTAuthCertificates | 構成コンテナー（NtAuthCertificates） | ドメイン認証で信頼される CA の集合（用途により影響大） | 旧 CA が使われていないことを確認してから整理 |
| Key Recovery Agents（KRA/KRI） | 構成コンテナー（Key Recovery Agents） | 鍵回復/鍵アーカイブに使う回復エージェント証明書の公開 | 参照が旧 CA 由来なら最終的に整理対象 |
ポイントは、「テンプレートは AD に残る」一方で、「旧 CA を参照する公開情報（Enrollment Services/AIA/CDP/NtAuth/KRA など）」は状況に応じて整理対象になるということです。
旧 CA を廃止する前にやっておくべき実務チェック（事故防止）
「旧 CA を消したら、ログオンや Wi-Fi 認証や VPN 認証が突然落ちた」などの事故の多くは、新 CA への移行が途中だったり、旧 CA の CRL/AIA 参照が残ったままだったりすることが原因です。廃止前に、次のチェックを最低限押さえると安全です。
移行完了チェックリスト（おすすめ）
| チェック項目 | 確認の観点 | 確認方法例 | 完了の目安 |
|---|---|---|---|
| 新 CA の証明書チェーン | 端末がルート/中間を正しく信頼しているか | テスト端末で証明書を発行して検証（MMC/証明書のパス） | 警告なしでチェーンが完成する |
| 新 CA の CRL/AIA 到達性 | 証明書検証時に失敗しないか | 発行した証明書の CDP/AIA URL を端末から到達確認 | HTTP/LDAP 参照が問題なく取得できる |
| テンプレート発行の切替 | 必要テンプレートが新 CA で発行されるか | CA コンソールの「証明書テンプレート」で発行状態を確認 | 旧 CA 依存のテンプレートが無い |
| 自動登録（GPO） | 新 CA で自動登録が回るか | 端末で gpupdate /force → 再起動 → 期待証明書が入るか | 必要な端末/ユーザーに自動で配布される |
| 重要用途の洗い出し | スマートカード/802.1X/VPN/LDAPS 等の影響 | 用途一覧を作り、証明書の発行元（Issuer）を確認 | 旧 CA 発行の証明書が計画的に置換されている |
| 旧 CA の CRL 継続提供計画 | 旧 CA 発行証明書の有効期間中の失効確認 | 旧 CA を落とした後も CRL を配布できる設計か | 最悪「静的に CRL を配る」代替がある |
特に CDP（CRL 配布ポイント）をどう維持するかは、旧 CA の廃止で最も落とし穴になりやすいです。旧 CA 発行の証明書が残っている間に CRL 取得不能になると、証明書検証が失敗し、認証系の障害につながることがあります。
旧 CA が動く場合の推奨デコミッション手順（段階的に安全に）
旧 CA サーバーにまだログオンでき、サービス停止や役割削除ができるなら、「段階的に止める → 最後にアンインストール」が最も安全です。
推奨フロー
- 新 CA へ発行先を切り替える
- 新 CA で必要テンプレートを「発行」状態にする（CA コンソールの証明書テンプレート）
- テンプレートの「登録（Enroll）/自動登録（Autoenroll）」権限が適切か確認する
- GPO の自動登録設定を確認する（ユーザー/コンピューター両方の適用範囲）
- 旧 CA の“新規発行”を止める
- 旧 CA でテンプレート発行を外す（「この CA では発行しない」状態にする）
- 必要なら CA を「停止」または「一時停止」にし、申請が来ても発行されない状態にする
- Web 登録（存在する場合）や SCEP/NDES 等があるなら併せて停止計画を立てる
- 旧 CA の CRL を「最後まで参照できる状態」に整える
- 旧 CA が発行した証明書が残る限り、CRL（失効リスト）の配布は必要になる可能性がある
- 「旧 CA を廃止しても CRL だけは Web サーバー等で配布を継続する」設計が有効なことが多い
- 役割の削除（AD CS アンインストール）
- サーバーマネージャーから「役割と機能の削除」→ AD CS を削除
- ウィザードで「Active Directory から証明書サービスのデータを削除する」趣旨の選択が出る場合は、設計に合わせて実施
- 残存参照の点検（AD 側・クライアント側）
- AD の構成コンテナーに旧 CA の参照が残っていないか確認
- クライアントの「中間/ルート/発行済み証明書」に旧 CA 由来が残るのは自然（有効期限まで）
- ただし、業務システムの設定（LDAPS の証明書固定、RADIUS の証明書固定など）に旧 CA が残る場合がある
旧 CA が既に使えない場合の「AD 手動クリーンアップ」手順
旧 CA が故障してしまい、正規のアンインストール手順を踏めないケースでは、Active Directory に残った参照を手作業で整理します。この作業は便利な反面、影響範囲が大きい箇所もあるため、削除対象を“旧 CA に限定”して慎重に進めるのがコツです。
作業前の鉄則（安全策）
- 構成コンテナー（Configuration）を触る前にバックアップ方針を決める（システム状態バックアップ等）
- 削除対象は「旧 CA 名」「旧 CA サーバー名」「旧 CA 証明書の拇印（Thumbprint）/シリアル」で突き合わせる
- “コンテナーごと削除”はしない（例：NtAuthCertificates はオブジェクト自体を消すのではなく、中身から旧 CA を外す）
削除・整理の対象になりやすい AD オブジェクト一覧
以下は、旧 CA の参照が残りやすい場所です。ドメイン構成によっては追加要素（例：CEP/CES、NDES、OCSP など）があるため、まずはここを起点に検索します。
| 区分 | AD 上の場所（代表例） | オブジェクト/属性 | 何を消す・外すか | 影響リスク |
|---|---|---|---|---|
| Enrollment Services | CN=Enrollment Services,CN=Public Key Services,CN=Services, CN=Configuration,DC=… | pKIEnrollmentService | 旧 CA の CN を持つオブジェクトを削除 | 中（クライアントが CA を探索する情報に影響） |
| Certification Authorities | CN=Certification Authorities,CN=Public Key Services,CN=Services, CN=Configuration,DC=… | certificationAuthority / cACertificate | 旧 CA 証明書の参照を削除（オブジェクト） | 中（チェーン構築に影響する場合あり） |
| AIA | CN=AIA,CN=Public Key Services,CN=Services, CN=Configuration,DC=… | cACertificate / crossCertificatePair 等 | 旧 CA 参照（CA 証明書）を削除 | 中〜高（チェーン参照に影響する場合あり） |
| CDP | CN=CDP,CN=Public Key Services,CN=Services, CN=Configuration,DC=… | certificateRevocationList / deltaRevocationList | 旧 CA の CRL 参照を削除（ただし時期に注意） | 高（旧 CA 発行証明書が残ると障害化しやすい） |
| NtAuthCertificates | CN=NtAuthCertificates,CN=Public Key Services,CN=Services, CN=Configuration,DC=… | cACertificate（複数格納） | 旧 CA の証明書をストアから削除（全削除はしない） | 高（スマートカード/証明書ログオン等に影響） |
| Key Recovery Agents | CN=Key Recovery Agents,CN=Public Key Services,CN=Services, CN=Configuration,DC=… | msPKI-PrivateKeyRecoveryAgent | 旧 CA 由来の KRA 証明書が不要なら削除 | 中（鍵アーカイブ運用の有無で変動） |
質問にある通り、AIA / CDP / Enrollment Services / Certification Authorities / NtAuthCertificatesは典型的な整理対象です。そして、環境によってはmsPKI-PrivateKeyRecoveryAgent（KRA/KRI）も “旧 CA 参照の残骸” として出てきます。
AD 上で旧 CA を特定するコツ（名前だけで消さない）
手動クリーンアップでよくある失敗は、「CN が似ていた」「テスト用 CA を誤って消した」などの取り違えです。削除前に、旧 CA を特定する情報を揃えます。
旧 CA を特定するための3点セット
- CA の共通名（CA 名）：CA オブジェクトの CN と一致することが多い
- 旧 CA サーバーのホスト名/FQDN：Enrollment Services の属性に含まれることがある
- 旧 CA 証明書の Thumbprint / シリアル番号：NtAuth などで確実に照合できる
PowerShell で「構成コンテナー」を検索する例
ActiveDirectory モジュールが使える管理端末で、構成コンテナーを検索します。値は環境に合わせて置き換えてください。
$conf = (Get-ADRootDSE).configurationNamingContext
# 旧 CA 名（例）で Enrollment Services を確認
Get-ADObject -SearchBase "CN=Enrollment Services,CN=Public Key Services,CN=Services,$conf" `
-LDAPFilter "(cn=OLD-CA-NAME)" -Properties *
# 旧 CA に関係しそうなものを “広めに” 探す（CN/名前に旧 CA 名が含まれる想定）
Get-ADObject -SearchBase "CN=Public Key Services,CN=Services,$conf" `
-LDAPFilter "(|(cn=*OLD-CA-NAME*)(name=*OLD-CA-NAME*))" -Properties distinguishedName
見つかった distinguishedName を控えておくと、ADSI Edit での確認・削除がスムーズです。
各オブジェクトの削除方針：消していいもの／慎重に扱うもの
「旧 CA に紐づくオブジェクトなら全部消す」が必ずしも正解ではありません。特に CDP と NtAuth は慎重に扱う必要があります。
削除方針の目安
| 対象 | 基本方針 | 削除前に確認したいこと | 現場での落とし穴 |
|---|---|---|---|
| Enrollment Services | 旧 CA を廃止するなら削除で OK | 新 CA の Enrollment Services が存在し、必要テンプレートを発行可能か | クライアントが CA を探索できず自動登録が鈍る |
| Certification Authorities / AIA | 旧 CA を信頼・参照する必要が無いなら整理 | 旧 CA 発行証明書が残る間、チェーン構築に使われないか | 一部端末だけパス構築が遅くなる/失敗する |
| CDP | 旧 CA 発行証明書が残るなら即削除しない | 旧 CA 発行証明書の有効期限、業務影響、CRL 継続配布方法 | 認証系（VPN/Wi-Fi/LDAPS）が突然失敗する |
| NtAuthCertificates | “証明書ログオン等で不要”を確認してから外す | スマートカードログオン、証明書マッピング、ドメインコントローラー用途 | ログオンや認証がドメイン全体で影響する可能性 |
| msPKI-PrivateKeyRecoveryAgent（KRA/KRI） | 鍵アーカイブ/鍵回復を使わないなら整理候補 | 「秘密鍵のアーカイブ」を有効にしたテンプレートが存在しないか | 過去の鍵回復ができなくなる（運用設計次第） |
msPKI-PrivateKeyRecoveryAgent（KRA/KRI）は削除対象か？判断基準
質問にある msPKI-PrivateKeyRecoveryAgent は、鍵回復（Key Recovery）や鍵アーカイブ（Key Archival）に関係するオブジェクトです。環境によっては「旧 CA を消したのに AD に残り続ける」ことがあります。
結論としては、旧 CA を参照している（旧 CA 由来の回復エージェント証明書が登録されている）のであれば、最終的に削除対象になり得ます。ただし、削除前に「その環境が鍵アーカイブ運用をしているか」を必ず確認してください。
削除判断のチェック表
| 状況 | 削除してよい可能性 | 確認ポイント | おすすめ対応 |
|---|---|---|---|
| 鍵アーカイブ/鍵回復を使っていない（使った記憶も無い） | 高い | テンプレートで「秘密鍵をアーカイブ」が有効なものが無いか | 旧 CA 由来の KRA オブジェクトを段階的に整理 |
| 過去に鍵アーカイブを使っていたが、今は使っていない | 中 | 過去にアーカイブした鍵を将来回復する要件が残っていないか | 要件確認後、保管・監査設計も含めて整理 |
| 現在も鍵アーカイブを使っている（回復運用がある） | 低い（慎重） | 新 CA で KRA 証明書を再構成できているか／旧 KRA が必要か | 新 CA の KRA を整備してから移行・整理 |
「残す理由がなければ消える」というより、実務では“残す理由があるかを確認してから消す”が安全です。鍵アーカイブが絡むと監査・コンプライアンス要件も関係しやすいため、手順書を残して作業すると後々困りません。
「テンプレートを消す」より安全な運用：発行停止・権限制御で“使わせない”
テンプレートが残っていること自体は問題ではないことが多いです。むしろ、テンプレートを削除すると、過去の調査や互換性確認が難しくなる場合があります。
よくある要件別のおすすめ対応
| やりたいこと | おすすめの方法 | 理由 | 注意点 |
|---|---|---|---|
| 旧 CA で発行させたくない | 旧 CA の「証明書テンプレート」から発行を外す | テンプレートは残しつつ、旧 CA では発行不能にできる | 新 CA 側で発行設定が必要 |
| 特定ユーザー/端末に発行させたくない | テンプレートのセキュリティで Enroll/Autoenroll を外す | “使わせない”を AD 権限で制御できる | 意図せず全社影響にならないよう範囲を明確化 |
| 完全に不要で、今後も使わない | 十分な調査の上でテンプレート削除を検討 | テンプレート定義を消すのは最後の手段 | 依存する自動登録やアプリ設定が無いか要確認 |
「旧 CA を廃止したい」＝「テンプレートを消したい」ではありません。多くのケースで、テンプレートは残したまま新 CA に発行を移すのが最も安全で、トラブルも少ない運用になります。
NtAuthCertificates を整理する時の注意点（影響が大きい）
NtAuthCertificates は、環境によってはドメイン全体の認証に影響する可能性があるため、削除対象として挙がっていても“最後に触る”くらいの慎重さが必要です。
NtAuthCertificates を触る前に確認したいこと
- スマートカードログオン（または証明書ログオン）を使っていないか
- 証明書マッピング（UPN/altSecurityIdentities 等）を運用していないか
- RADIUS/NPS、VPN、VDI などで証明書認証をしていないか
- 古い CA が「ドメイン認証に使われる CA」として登録されていないか
NtAuth の確認・削除（代表例）
一般に、NtAuth を直接 ADSI Edit で編集するより、certutil で内容を確認し、該当証明書だけを削除する方が安全です。
# NtAuth ストアの確認
certutil -viewstore -enterprise NTAuth
# 旧 CA 証明書だけを削除（シリアル番号等で指定）
certutil -delstore -enterprise NTAuth "SERIALNUMBER" コマンドの出力から旧 CA 証明書のシリアル番号や拇印を照合し、確実に旧 CA のみを対象にしてください。
CDP（CRL）を削除する前に考えるべきこと：旧 CA 証明書の“余命”
CDP は「旧 CA を消したら一緒に消してよい」と思われがちですが、実務では逆で、旧 CA の証明書が残る限り、CDP の参照は残しておく方が安全なケースが多いです。
なぜ CDP が重要なのか
- 証明書の検証では、チェーン（Issuer）だけでなく失効情報（CRL/OCSP）の参照が求められることがある
- 特に VPN/Wi-Fi/LDAPS のような認証系は、失効チェックに失敗すると接続できない設定になっていることがある
- 旧 CA 発行証明書が残っているのに CRL が取れなくなると、“旧証明書が失効していなくても”検証が失敗しうる
現実的な落としどころ（よく採られる運用）
| 方針 | 向いているケース | メリット | 注意点 |
|---|---|---|---|
| 旧 CA を一定期間残し、CRL も発行し続ける | 旧証明書が多い／置換に時間がかかる | 最も安全でトラブルが少ない | 旧サーバー維持コストが残る |
| 旧 CA は停止し、CRL だけ別サーバーで静的配布 | サーバー廃止が急務だが旧証明書が残る | 旧サーバーを消しつつ検証を成立させやすい | CRL の有効期限管理が必要 |
| 旧証明書が完全に消えてから CDP を整理 | 短命証明書のみで運用している | スッキリする | 本当に残っていないかの確認が必須 |
旧 CA のデコミッションを「サーバー撤去」で終わらせず、旧 CA が発行した証明書の有効期限まで含めて計画すると、運用トラブルを避けやすくなります。
廃止後の確認ポイント（“新 CA に完全移行できたか”の最終チェック）
最後に、旧 CA の役割削除や AD クリーンアップ後に確認しておくと安心なポイントをまとめます。
動作確認チェック表
| チェック | 確認方法例 | 期待結果 | 問題があったら |
|---|---|---|---|
| 新規発行が新 CA で行われる | テスト端末で証明書要求（自動登録含む） | Issuer が新 CA になっている | テンプレート発行設定・権限・GPO を再確認 |
| 証明書パスが正常 | MMC の証明書 → パス | 警告なし | AIA/中間証明書配布を見直す |
| CRL/AIA が取得できる | 証明書の拡張から URL を開いて確認 | HTTP/LDAP で取得成功 | Web 配布/公開場所/DNS/Firewall を点検 |
| 重要認証（VPN/Wi-Fi/LDAPS 等） | 実機で接続テスト | 問題なく認証できる | 旧 CA 証明書固定や CRL 参照の残存を疑う |
| AD に旧 CA 参照が残っていない | 構成コンテナー検索（旧 CA 名/ホスト名） | 旧 CA 関連の不要オブジェクトが見当たらない | 残存 DN を洗い出し、削除対象を再判定 |
よくある落とし穴（2008 R2 の旧 CA 置換で特に多い）
- テンプレートは残るのに、発行設定が新 CA に移っていない：テンプレートが存在するだけでは自動登録は動きません。新 CA の「発行」設定とテンプレート権限がセットです。
- CDP/AIA の URL が旧サーバー固定：旧 CA 発行証明書の拡張に旧サーバー URL が埋め込まれていることがあります。旧サーバー撤去後の到達性を設計してください。
- NtAuth を勢いで消してしまう：影響範囲が広いので、用途確認と段階移行を推奨します。
- KRA/KRI（msPKI-PrivateKeyRecoveryAgent）の存在に気づかず放置：鍵アーカイブ運用が無いなら整理候補ですが、運用があるなら“新 CA 側の再構成”が先です。
- 旧 CA を消すことが目的化して、旧証明書の置換が終わっていない：廃止は“発行停止→置換→参照整理→削除”の順が安全です。
まとめ：安全な廃止の考え方（テンプレートは残し、参照を整理する）
- AD CS をアンインストールしても証明書テンプレートは削除されません。テンプレートは AD（構成コンテナー）で管理されるためです。
- 旧 CA が利用できず手動クリーンアップする場合は、AIA / CDP / Enrollment Services / Certification Authorities / NtAuthCertificates など、旧 CA 参照の AD オブジェクトを整理します。
- msPKI-PrivateKeyRecoveryAgent（KRA/KRI）も、旧 CA 由来で不要なら最終的に削除対象になり得ます。ただし鍵アーカイブ運用の有無を必ず確認してください。
- 最大の事故ポイントは CDP と NtAuth です。旧 CA 発行証明書が残る間の CRL/AIA 提供計画まで含めて廃止を設計すると、切り戻しも容易になります。
コメント