「マネージャ承認が必要な証明書テンプレートだけ自動登録が完了しない」。企業の PKI 運用で非常に起こりやすいこの現象は、ほとんどの場合クライアント側の Autoenrollment（自動登録）の設定や動作トリガが噛み合っていないことが原因です。本稿では、現象の整理から根本原因、正しいグループポリシー設定、即時反映の手順、暫定自動化までを体系立てて解説し、手作業の certreq 実行から卒業できる実務的なチェックリストを提示します。
現象の整理と期待される挙動
まずは現象を明確化し、正しい挙動とのギャップを把握します。
| 項目 | 承認不要テンプレート | マネージャ承認付きテンプレート |
|---|---|---|
| 要求の送信 | MMC（証明書スナップイン）や自動登録により送信。 | 同様に送信され、CA に「保留中」として到達。 |
| CAでの処理 | 即時発行（承認不要）。 | CA/承認者が手動承認後に発行。 |
| クライアントの最終状態 | 自動で受信し「個人（My）」ストアへ格納。完全なチェーンも保存。 | 本来は同様に自動受信だが、現象発生環境では「証明書登録の要求」に留まり、発行済みが取り込まれない。 |
| 暫定対処 | 不要。 | SYSTEM で certreq -retrieve → certreq -accept により手動で取得・バインドは可能。 |
ポイントは、「承認の有無」によって CA 側の発行フローが変わるだけで、クライアントの最終受信方法（Autoenrollment による取り込み）は同一であるべき、という点です。つまり、承認後に自動で取り込めていないなら、Autoenrollment の有効化とポーリングを見直す必要があります。
根本原因：Autoenrollment の役割と“保留中”の再試行
Autoenrollment は、クライアントがドメイン ポリシーに従い、証明書の要求・更新・失効・削除を定期的に実行する仕組みです。承認付きテンプレートでは、最初の要求時点では「保留中（Pending）」で止まるため、承認後の次回ポーリングでクライアントが「発行済み」を検知し、証明書本体を自動受信してストアへ格納します。
この“承認後の取り込み”を司るのがポリシー項目の「保留中の要求を更新して再試行する」。これが無効、または Autoenrollment 自体が有効化されていないと、承認後もクライアントは取り込みを実行せず、「証明書登録の要求」フォルダーに残り続けます。
最短の恒久解：グループポリシーで Autoenrollment を正しく有効化
恒久対策はシンプルです。対象スコープ（ユーザー／コンピューター）に対して、Autoenrollment を有効化し、保留中の再試行を許可します。
設定パス
コンピューターの構成 → ポリシー → Windows の設定 → セキュリティの設定 → 公開キー ポリシー → Certificate Services Client – Auto-Enrollment
推奨構成
- 「証明書の自動登録を有効にする」＝ 有効
- 「保留中の要求を更新して再試行する」＝ 有効
- （必要に応じ）「テンプレートを使用した証明書を更新」＝ 有効
適用手順（例：コンピューター証明書）
- ドメイン コントローラーで
gpmc.msc（グループ ポリシーの管理）を開く。 - 対象コンピューターが属する OU に新しい GPO を作成し、リンク。
- 上記パスの「Certificate Services Client – Auto-Enrollment」を開き、推奨構成に設定。
- テンプレートの セキュリティ で対象コンピューター（またはグループ）に「Enroll」「Autoenroll」権限が付与されていることを確認。
- クライアントで
gpupdate /forceを実行し、適用を即時化。
動作確認（即時トリガ）
ポーリングを待たずに確認する場合は、管理者権限のシェルで以下を実行します。コンピューター証明書なら SYSTEM コンテキストが確実です。
certutil -pulse成功すれば、「証明書登録の要求」から発行済みが自動で取り込まれ、個人（My）ストアに完全なチェーン付きで格納されます。
暫定対処：certreq による手動取得（自動化のヒント付き）
ポリシー展開の事情により即時の GPO 適用が難しい場合は、手動での取得が可能です。証明書は承認後、CA 上に存在しているため、RequestID を指定して取り込みます。コンピューター証明書なら SYSTEM で実行してください。
certreq -retrieve <RequestID> cert.cer
certreq -accept cert.cer
暫定的に自動化したい場合は、タスク スケジューラで NT AUTHORITY\SYSTEM 実行のタスクを作成し、承認後の一定間隔で次のいずれかを実行します。
- 推奨：
certutil -pulse（Autoenrollment のポーリングを強制） - やむを得ない場合：
certreq -retrieve→certreq -accept（ただし RequestID の管理が必要）
ただし、あくまで暫定策です。最終的には GPO での自動登録に戻すことを強く推奨します。
テンプレートとアクセス権のチェックリスト
承認付きテンプレートの動作を安定させるために、以下を必ず点検します。
| カテゴリ | チェック項目 | 要点 |
|---|---|---|
| テンプレート構成 | 「要求者がマネージャ承認を要する」を有効化 | 発行は CA 側での承認後。承認後は Autoenrollment が取得可能。 |
| テンプレート セキュリティ | 対象（ユーザー／コンピューター）に「Enroll」「Autoenroll」 | 権限不足はよくある原因。スコープを絞ったグループで付与すると安全。 |
| サブジェクト名 | AD 情報から自動生成 or 供給 | アプリ要件に合わせる。手動供給が必要な設計だと自動化は難しくなる。 |
| 秘密キー | エクスポート可否、キー用途、長さ/アルゴリズム | アプリ連携要件に合致させる。誤ると取得後のバインドで失敗。 |
| 対象ストア | ユーザー or コンピューター コンテキスト | MMC の「現在のユーザー」「ローカル コンピューター」を混同しない。 |
GPO の即時反映と確認コマンド
ポリシー更新は通常のバックグラウンド更新を待たず、手元で即時化・検証できます。
- ポリシー更新：
gpupdate /force - Autoenrollment トリガ：
certutil -pulse - 適用結果レポート：
gpresult /h %TEMP%\gp.html - 証明書ストア確認（個人）：
certutil -store my - チェーン検証：
certutil -verifystore my
トラブルシューティング：ログとネットワーク、CA 側の前提条件
自動取得に失敗する場合は、次の観点を順に潰します。
クライアント ログ
- イベント ビューアー：「アプリケーションとサービス ログ → Microsoft → Windows → CertificateServicesClient-AutoEnrollment」
- 補助ログ：「CertificateServicesClient-CertEnroll」
エラーや警告があれば、その内容から「アクセス権」「テンプレート不一致」「ネットワーク到達性」「失効情報・チェーンの問題」などの切り口で原因を特定します。
ネットワーク要件（エンタープライズ CA へ到達できること）
| 通信先 | プロトコル/ポート | 目的 |
|---|---|---|
| CA サーバー | RPC（TCP 135） + 動的ポート | DCOM を用いた要求の送信・取得。 |
| HTTP/LDAP（AIA/CDP） | 80/443, 389/636 等 | 中間/ルート証明書および CRL の取得。チェーン構築に必須。 |
ファイアウォールやセグメント越えの通信制御により RPC の確立が阻害されていると、承認後の取り込みが失敗します。ポリシー配布の有無だけでなく、CA への到達性を常に確認してください。
CA 側の権限
- CA サーバーのローカル グループ（例：CERTSVC_DCOM_ACCESS）に対象のユーザー/コンピューターが含まれているか。
- テンプレートの公開状態と CA における発行権限の整合。
- 承認フロー：承認後にステータスが“発行済み”になっているか（取り消しや期限切れになっていないか）。
ケース別の原因と対処の対応表
| 症状 | 想定原因 | 確認ポイント | 推奨対処 |
|---|---|---|---|
| 承認後も取り込まれない | Autoenrollment 無効／保留中再試行が無効 | GPO 設定、RSOP、レジストリ（ポリシー適用） | GPO を有効化し gpupdate → certutil -pulse |
| エラーなしだが反映が遅い | ポーリング待ち | イベント ログにエラーなし | certutil -pulse で即時トリガ |
| MMC の要求に残り続ける | ユーザー/コンピューター コンテキストの不一致 | MMC スナップインの接続先 | 正しいコンテキストで要求を作成し直す |
| 取得はできるがバインドに失敗 | キー用途／エクステンション不一致 | テンプレートの EKU、Key Usage | テンプレート再設計（アプリ要件に合わせる） |
| チェーン不完全 | AIA/CDP 参照不可、ルート/中間未信頼 | チェーン検証（certutil -verify 等） | 信頼チェーンの配布・到達性を確保 |
| CA 到達不可 | ファイアウォール／ネットワーク制御 | RPC 135・動的ポート疎通、certutil -ping | 通信許可、エンドポイント制御見直し |
よくある落とし穴
- テンプレート権限の付与漏れ：「Enroll」は付けたが「Autoenroll」を忘れる、あるいは適用グループを誤る。
- OU リンク／WMI フィルターの不整合：GPO が対象に適用されていない。
gpresultで必ず確認。 - 現在のユーザー vs ローカル コンピューター：要求を作成したコンテキストと、ポリシーの適用スコープが一致していない。
- ネットワーク遮断：承認付きテンプレートでは「承認後の受信」に RPC/DCOM が必要。クライアントから CA への疎通を確保。
- 失効情報の未取得：CRL/AIA の配布が不達だとチェーンが完成せず、アプリ側でエラー化することがある。
実務で役立つ運用小技
即時収束スクリプト（コンピューター証明書）
管理者権限の PowerShell（SYSTEM での実行が望ましい）から、GPO 再適用→ポーリング→ストア確認を一括で実行して収束させます。
gpupdate /force
certutil -pulse
certutil -store my
タスク スケジューラでの暫定自動化（最小リスク案）
承認後の取り込みだけを確実にしたい場合は、暫定的に certutil -pulse を SYSTEM で定期実行するタスクを構成します。RequestID の管理を伴わず、安全に Autoenrollment を呼び出せます。
CA 到達性のヘルスチェック
クライアントから CA 構成名（例：CAHOST\Contoso-Issuing-CA）に ping を実施し、RPC/DCOM の初期疎通を評価します。
certutil -ping -config "CAHOST\Contoso-Issuing-CA"セキュリティと設計上の考慮点
- 権限は最小化：テンプレートの「Autoenroll」は必要なセキュリティ グループに限定。
- 監査：承認付きテンプレートの運用では、承認者のアクションがログに残るよう CA 監査を有効化。
- キー保護：高機密用途では、TPM または HSM バッキングを選択できる設計を検討。
- ライフサイクル：更新期限のしきい値（更新猶予期間）が短いと駆け込み更新が集中。Autoenrollment の負荷とネットワークを勘案して設計。
- テンプレート分割：承認の要否や EKU が異なる用途（IIS, RDS, VPN など）はテンプレートを分け、権限と配布を明確化。
手順のまとめ（最短経路）
- テンプレートの「セキュリティ」で対象に「Enroll」「Autoenroll」を付与。
- GPO：Certificate Services Client – Auto-Enrollment を有効化し、「保留中の要求を更新して再試行する」を有効。
- クライアントで
gpupdate /force→certutil -pulse。 - イベント ログ（AutoEnrollment/CertEnroll）で成否を確認。
certutil -store myでストアを検証。 - 必要に応じて CA 到達性、AIA/CDP 参照、ファイアウォールを確認。
原因別・チェックリスト（印刷用）
| # | チェック | コマンド/場所 | 期待結果 |
|---|---|---|---|
| 1 | 対象に Autoenroll 権限 | テンプレート「セキュリティ」 | 対象グループに「Enroll」「Autoenroll」 |
| 2 | GPO が適用 | gpresult /h, RSOP | 該当 GPO が「適用済み」 |
| 3 | Autoenrollment 有効 | GPO 編集画面 | 「有効」＋「保留中の要求を更新して再試行」 |
| 4 | ポーリング実行 | certutil -pulse | 発行済みが取り込まれる |
| 5 | CA 到達性 | certutil -ping -config | DCOM/RPC の確立 |
| 6 | チェーン完成 | certutil -verifystore my | エラーなし（CRL/AIA 到達可） |
なぜ「SYSTEM」で実行するのか
コンピューター証明書は、ローカル コンピューター コンテキストの「個人」ストアに格納されます。certreq/certutil をユーザー権限で実行すると、ユーザーの個人ストアに作用してしまい、目的のストアへ取り込めません。タスク スケジューラで「NT AUTHORITY\SYSTEM」として実行するか、PsExec -s などで SYSTEM シェルを用いると確実です。
発行後のアプリ連携（IIS など）
Autoenrollment は「取得まで」を自動化しますが、IIS の HTTPS バインドや RADIUS の証明書指定は別操作です。テンプレートの Friendly Name を付与する、Thumbprint を運用管理台帳に記録する、IIS の自動バインド スクリプト（netsh http / PowerShell の New-WebBinding など）を併用するなど、取得後の自動化も合わせて検討してください。
まとめ
マネージャ承認付きテンプレートで自動登録が完了しない多くのケースは、クライアント側 Autoenrollment の「有効化」と「保留中の要求の再試行」が未設定、あるいはポーリング未実行に起因します。GPO を正しく構成し、certutil -pulse で即時トリガ、必要なら暫定的にタスクでポーリングを自動化。テンプレート権限・ネットワーク到達性・チェーン配布の 3 点を外さなければ、承認付きでも承認不要テンプレートと同様に、承認完了直後にクライアントへ証明書が自動配布・インストールされ、手動の certreq から解放されます。
付録：実行コマンド集（コピー用）
:: ポリシー即時適用
gpupdate /force
:: Autoenrollment のポーリングを今すぐ実行
certutil -pulse
:: CA への到達確認（構成名は環境に合わせて変更）
certutil -ping -config "CAHOST\Contoso-Issuing-CA"
:: 個人（My）ストアの確認（コンピューターの場合は SYSTEM で）
certutil -store my
certutil -verifystore my
:: （暫定策）承認済みの取得と受け入れ（RequestID は CA で確認）
certreq -retrieve cert.cer
certreq -accept cert.cer 付録：運用ベストプラクティス要約
- テンプレートごとに用途を分離し、最小権限で「Enroll」「Autoenroll」を付与。
- 承認付きテンプレートは、承認者の監査とワークフロー（手順書）を整備。
- クライアント側は GPO で Autoenrollment を標準化し、イレギュラー対応をなくす。
- CA／AIA／CDP の到達性監視（死活監視）を導入し、チェーン不全を未然に防止。
- 更新期日のばらつきを設計し、更新集中を避ける。
コメント