AD CSで期限切れルート証明書・クロス証明書が新規サーバーに入る原因と止め方（GPO配布の特定と掃除手順）

AD CS（2階層PKI：Root CA＋発行CA）環境で、新しいサーバーをドメイン参加させるたびに「期限切れのルート証明書／クロス証明書」が証明書ストアへ入ってきて困っていませんか。まずは配布元を特定して止血し、そのうえで既存サーバーから安全に掃除する手順を、運用目線で整理します。

現象を整理する：どのストアに、どんな証明書が入っているのか

今回のケースは「新規参加サーバーに、期限切れ証明書が毎回混入する」ことがポイントです。まず、状況を言語化しておくと切り分けが速くなります。

観点	今回の状況（例）	重要な理由
PKI構成	2階層（Root CA＋発行CA）	AD CSでは証明書が「ADに公開」「GPOで配布」されやすい
混入先	ローカルコンピューターの「中間証明機関（Intermediate CA）」ストア	チェーン構築に影響しやすく、監査・棚卸しでノイズになる
混入する証明書	期限切れのルート証明書が2つ（Cross系テンプレ由来／Root系テンプレ由来）	過去のクロス認証の残骸が、配布経路に残っている可能性が高い
再現条件	新規サーバーをドメイン参加するたびに発生	手作業や1台限定ではなく「仕組み（GPO/AD公開）」起因が濃厚

この時点で最優先の仮説はシンプルです。

「ドメイン参加＝GPO適用やAD公開情報の取り込みが走る」ため、期限切れ証明書が“配られている”可能性が高い、ということです。

まず疑うべき原因：GPO（公開キーのポリシー）で証明書が配布されている

結論から言うと、同じ現象の多くはGPOによる証明書配布が原因です。理由は単純で、GPOはOU配下に新規参加した端末へ、同じ証明書を何度でも確実に届けられる仕組みだからです。

GPOで配布できるストアは意外と多い

GPO（グループポリシー）では、次のような証明書ストアへ証明書を配布できます。

配布先ストア（端末側）	GPO上の場所（典型）	用途	今回の現象との関係
信頼されたルート証明機関（Trusted Root）	コンピューターの構成 → Windows の設定 → セキュリティの設定 → 公開キーのポリシー → 信頼されたルート証明機関	ルートとして信頼する	「期限切れルート」がここにあると、棚卸し・監査で問題視されやすい
中間証明機関（Intermediate CA）	同 → 公開キーのポリシー → 中間証明機関	チェーン構築に使う中間CA	今回の混入先。ここにGPOで登録していると新規参加ごとに増える
エンタープライズ信頼（Enterprise Trust）	同 → 公開キーのポリシー → エンタープライズ信頼（環境により表示）	企業内の信頼（CTL等）	過去のクロス認証（クロス証明書）に絡む残骸が居座りやすい
証明書パスの検証設定（Certificate Path Validation Settings）	同 → 公開キーのポリシー → 証明書パスの検証設定	失効確認やAIA/CDP参照など	直接「証明書を配る」ではないが、チェーン構築の挙動に影響する

特に、過去に他PKIとクロス認証していた環境では、当時の名残として「Cross Certification Authority」や「Root Certification」的な名前の証明書がGPOに登録されたまま残り、今になって期限切れになっても配布が続いているケースがよくあります。

原因特定の最短ルート：端末側で「どのGPOが配っているか」を洗い出す

最初にやるべきことは、期限切れ証明書そのものを眺めて悩むことではなく、どの仕組みが入れているかを確定させることです。ここが曖昧だと、手動削除しても再発します。

証明書情報は必ず控える（掃除の事故を防ぐ）

削除や配布停止をする前に、まず期限切れ証明書の情報を控えます。最低でも次を記録してください。

• サブジェクト（Issued to）
• 発行者（Issued by）
• 有効期間（Not Before / Not After）
• 拇印（Thumbprint）（最重要）
• どのストアに入っているか（今回ならローカルコンピューター → 中間証明機関）

GUIなら certlm.msc（ローカルコンピューター証明書）で確認できます。台数が多いならPowerShellで抽出して「証跡」を残すのも有効です。

PowerShell（管理者）例：中間証明機関（CA）ストアの期限切れ証明書を一覧
Get-ChildItem -Path Cert:\LocalMachine\CA |
  Where-Object { $_.NotAfter -lt (Get-Date) } |
  Select-Object Subject, Issuer, NotAfter, Thumbprint |
  Format-Table -Auto

gpresultで「適用されているGPO」を固定する

対象サーバー（期限切れ証明書が入ってくる端末）で、管理者権限のコマンドプロンプトから次を実行します。

gpresult /h C:\temp\gpresult.html

生成されたHTMLを開き、次を重点的に確認します。

• 適用されているGPOの一覧（コンピューター側）
• セキュリティの設定 → 公開キーのポリシーに相当する設定が出ていないか
• 「証明書サービス クライアント – 自動登録」関連のポリシー（環境による）

gpresultで候補GPOが絞れたら、次はGPMC（グループポリシー管理）側で当該GPOを開いて確認します。

追加の切り分け：GPO由来の証明書はレジストリに痕跡が残る

オリジナルの切り分けとしておすすめなのが、GPO配布証明書の格納場所（ポリシー管理下の証明書領域）を確認する方法です。GPOで配られた証明書は、概ね次のようなポリシー配下に格納されます。

例（参照用）：GPO配布の証明書が入ることがある場所
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\

ストアによってサブキー名が異なります（Root、CA、TrustedPublisher等）。ここに該当の拇印が見える場合、「手作業で消してもGPOが戻す」状況になっている可能性が高いです。

ポイント：レジストリ確認は「原因の当たりを付ける」目的です。編集（削除）をここで直接やるのではなく、必ずGPO側の修正を正攻法にしてください。

配布停止の手順：GPMCで該当GPOから期限切れ証明書を外す

原因がGPOだと分かったら、やるべきことは明確です。GPOから期限切れ証明書を削除し、以後配布されない状態にします。

GPO編集で確認する場所（典型）

GPMC（グループポリシー管理）で対象GPOを編集し、次を辿ります。

• コンピューターの構成
  • ポリシー
    • Windows の設定
      • セキュリティの設定
        • 公開キーのポリシー
          • 信頼されたルート証明機関（Trusted Root）
          • 中間証明機関（Intermediate）
          • （環境により）エンタープライズ信頼（Enterprise Trust）
          • （環境により）証明書パスの検証設定

該当ストアの中に、期限切れのルート証明書／クロス証明書が登録されていたら、GPOから削除します。OUリンクやセキュリティフィルタで配布範囲を調整している場合は、削除と合わせて「そもそもこのGPOを配る必要があるのか」も見直してください。

「削除する証明書」の判断基準（Thumbprintで一致させる）

証明書名（表示名）やサブジェクトだけで削除対象を決めると、似た名前の別証明書を消して事故になります。必ず次の3点で一致確認します。

確認項目	なぜ必要か	おすすめの運用
拇印（Thumbprint）	同名・同サブジェクトでも別証明書が存在しうる	最終判断はThumbprint一致
発行者（Issuer）	古いクロス認証の残骸はIssuerが特徴的なことが多い	Root/クロス先の名称を照合
用途（EKU等）	異なる用途の証明書を誤削除しないため	「CA証明書」かどうかを確認

配布停止後にやること：ポリシー更新と反映確認

GPOを修正したら、対象端末でポリシーを更新します。

gpupdate /force

証明書ストア系の変更は、環境やタイミングによっては再起動で安定することがあります（特にサーバー用途で影響が許容される場合）。反映確認は、再度 certlm.msc でストアを見て、対象の期限切れ証明書が「新規参加で入ってこない」状態になったかを確認します。

最重要：先にGPOを直さず、先に端末から削除すると高確率で再発します。必ず「止血 → 掃除」の順で進めてください。

それでもGPOに見当たらない場合：ADに公開された証明書を端末が取り込みに行っている

GPOを確認しても該当証明書が見つからない場合、次に疑うのはAD CSの証明書がActive Directoryに公開されているパターンです。

AD CSでは、CA証明書やクロス証明書、失効リストなどが、Active Directoryの構成パーティション（Configuration）配下に公開されることがあります。ドメイン参加端末は、これらを信頼やチェーン構築の材料として参照し、結果としてローカルの証明書ストアに現れることがあります。

確認すべき代表的な公開先（概念）

具体的なコンテナ名や構造は環境差がありますが、代表例として「Public Key Services」配下に、CA・クロス証明書・AIA・CDPなどの情報が配置されるイメージです。

公開情報の種類	想定される内容	今回の現象との関係
CA証明書（ルート/発行CA）	企業内で信頼させたいCAの証明書	期限切れのルート証明書が残っていると、ドメイン参加で現れる可能性
クロス証明書（Cross Certificate）	他PKIとクロス認証するための証明書	過去のクロス認証を廃止しても、AD上に残っていると混入しやすい
AIA/CDP情報	CA証明書の参照先、失効リスト	チェーン構築の途中で参照され、結果的にストアに見えることがある

AD公開が原因かを切り分ける現実的な方法

「GPOに無い」ことを確認できたら、次の順で疑うと遠回りしにくいです。

• 同じOU・同じGPO範囲でも発生するか（新規参加を複数回で再現）
• 端末側のストアで、期限切れ証明書の「発行者」「AIA」などにAD由来（LDAP参照）の痕跡がないか
• 管理端末/ドメインコントローラーで、PKI関連の管理スナップイン（例：Enterprise PKI）やディレクトリ参照（ADSI Editなど）で、古い証明書が公開状態で残っていないか

注意：AD上の公開証明書を削除する作業は影響範囲が大きくなりやすいです。削除前に「本当に現行チェーンで不要か」「過去データ検証に不要か」を判断し、必ずバックアップ（エクスポート）と変更手順書を用意してください。

既存サーバーに入ってしまっている期限切れ証明書の掃除（安全第一）

配布元（GPOまたはAD公開）を止めたら、次は既存サーバーのクリーンアップです。ここで大事なのは、台数や運用要件に合わせて手段を選ぶことです。

掃除の手段は3パターンに分けると失敗しにくい

手段	向いている状況	メリット	注意点
手動削除（certlm.msc）	台数が少ない／まず1台で検証したい	目で見て確認しながら進められる	スケールしない。誤削除に注意
PowerShellで対象Thumbprintを削除	台数が多い／確実に同一証明書だけ消したい	再現性が高い。ログを残せる	誤ったThumbprint指定が最大リスク
運用基盤（SCCM/Intune/スクリプト配布）で一斉適用	サーバー台数が多い／定期棚卸しが必要	統制が効く	承認フロー・検証が必須

手動削除の基本手順（certlm.msc）

• 配布停止（GPO修正）を先に完了していることを確認
• certlm.msc を開く（ローカルコンピューター）
• 「中間証明機関」または該当ストアを開く
• 期限切れ証明書を開き、Thumbprintが削除対象と一致することを確認
• 削除

「削除」ボタンが押せない、削除しても戻ってくる場合は、GPO配布（または管理下ストア）に残っている可能性が高いので、配布停止の作業に戻って再確認します。

PowerShellでの掃除例（Thumbprint指定で安全側に倒す）

台数が多い場合は、Thumbprintを固定して削除するのが事故りにくいです。以下は一例です（実行は十分に検証してから、変更管理のもとで行ってください）。

# 管理者PowerShell例：指定Thumbprintを中間証明機関（CA）ストアから削除
$targetThumbprints = @(
  "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA",
  "BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB"
)

$storePath = "Cert:\LocalMachine\CA"

Get-ChildItem -Path $storePath | ForEach-Object {
  if ($targetThumbprints -contains $_.Thumbprint) {
    Write-Host "Removing: $($_.Subject) / $($_.Thumbprint)"
    Remove-Item -Path ($storePath + "\" + $_.Thumbprint) -Force
  }
}

「期限切れなら何でも消す」方式は便利に見えますが、環境によっては過去データ検証やアーカイブ用途で必要になることもあるため、まずはThumbprint固定を推奨します。

掃除後の確認観点（“消した”だけで終わらせない）

削除したら、次の観点で問題が起きていないか確認します。

• サーバー上でTLS通信（IIS、LDAPS、WinRM、アプリ間通信など）が問題なく成立するか
• 内部サイト／管理ポータル等の証明書チェーンが正しく表示されるか
• イベントログに証明書チェーン関連のエラーが出ていないか
• 新規参加サーバーで同じ期限切れ証明書が再度出現しないか（再発防止の確認）

再発防止：期限切れ証明書が「配布され続ける」運用を断ち切る

同じ問題が再発しやすい理由は、証明書が「作る」「更新する」運用に比べて、「廃止する」「配布を止める」運用が後回しになりがちだからです。再発を防ぐための実務的な工夫をまとめます。

PKI用のGPOは分離して管理する

証明書配布の設定を、Default Domain Policyや雑多なGPOに混ぜると、誰も全体像を追えなくなります。次のような運用が効果的です。

• PKI用のGPOを1本（または用途別に数本）に分離する
• GPO名に用途を明記（例：PKI-TrustedRoots、PKI-IntermediateCA、PKI-EnterpriseTrust）
• 証明書を追加・削除したら、GPOのコメント欄に追加理由／削除理由／実施日／担当を記録

クロス認証を廃止する時は「残骸チェック」を手順に入れる

クロス認証を終了したら、次の残骸が残っていないかをチェック項目に入れておくと、今回のような「後から期限切れで発覚」が減ります。

残骸ポイント	チェック対象	よくある見落とし
GPO	公開キーのポリシー（Root/Intermediate/Enterprise Trust）	OUリンクが複数あり、片方だけ直して安心してしまう
AD公開	PKI関連コンテナに古いクロス証明書が残っていないか	「廃止＝CA停止」で終わり、公開情報の掃除を忘れる
ドキュメント	有効な信頼チェーン一覧／失効確認先／例外設定	担当者が変わると背景が消える

証明書棚卸しを「期限前」に自動化する

期限切れになってから気付くと、緊急対応になりがちです。次のような棚卸しを月次・四半期で回すと安定します。

• 各ストア（Root/CA/Enterprise Trust）で「期限が近い証明書」「期限切れ証明書」を抽出し、レポート化
• Thumbprintベースで、過去の廃止証明書リストと照合
• 配布経路（GPO/AD公開/イメージ）ごとの責任分界点を明確にする

よくある落とし穴：このパターンでハマりやすいポイント

最後に、現場でよくハマるポイントをまとめます。原因が分かっていても、ここで時間を溶かしがちです。

• 手動削除しても戻る：GPO配布が生きている典型。止血が先。
• 同名の証明書が複数ある：Subject名で判断しない。Thumbprintで判断。
• OUが複雑でGPOが見えない：gpresultで端末起点に追う。GPMCの「グループ ポリシーの結果」も有効。
• Rootにあると思い込む：今回のようにIntermediate（CA）に入るケースもある。実際の混入先ストアを基準に追う。
• “期限切れ＝即削除”で進めてしまう：過去データ検証や署名検証の要件がある環境は要注意。削除前に影響確認を設計する。

この問題の最短解：実務チェックリスト

最後に、やることを順序付きでまとめます。これに沿って進めると、再発と手戻りを減らせます。

フェーズ	やること	完了条件
把握	期限切れ証明書のSubject/Issuer/NotAfter/Thumbprint/混入ストアを控える	Thumbprintが確定している
原因特定	gpresultで適用GPOを洗い出し、公開キーのポリシー設定を確認	配布元GPOが特定できる（またはGPO起因を除外できる）
止血	GPMCで該当GPOから期限切れ証明書を削除（必要に応じてリンク/フィルタ見直し）	新規参加サーバーで混入しない
掃除	既存サーバーからThumbprint指定で削除（手動またはスクリプト）	対象ストアから消えている
再発防止	PKI用GPOの分離、廃止手順の整備、期限前棚卸しの仕組み化	期限切れ証明書が配布され続けない運用になっている