オンプレミス環境でAD CS（Active Directory Certificate Services）を用いた証明書の自動登録を行う際、設定を変更すると急にエラーが出始めてしまうことがあります。今回は、ドメイン環境とスタンドアロン型のPKIサーバーを組み合わせた構成にフォーカスしつつ、原因究明やトラブルシュートのポイントを詳しく解説していきます。
AD CS環境での証明書自動登録がうまくいかない原因を探る
ドメインコントローラー（以下DC）2台とスタンドアロンのPKIサーバー（AD CSサーバー）を組み合わせた環境では、通常であればLDAP経由で証明書の自動登録（Autoenrollment）が行われます。しかし、何らかの事情でLDAPではなくHTTP(S)ポートを使ったCertificate Enrollment Policy (CEP) のURLに切り替えた途端、「利用可能な証明書テンプレートがない」といったエラーが発生するケースがあります。
環境変更後に起こりがちな不具合
AD CSの導入直後はスムーズに機能していたにもかかわらず、設定変更によって突如エラーが発生する場合、以下のようなことが原因になりやすいです。
- ルート証明書の信頼チェーンが正しく配布されていない
- Certificate Enrollment Policy (CEP) URLの設定ミスや通信ポートの問題
- 証明書テンプレートのセキュリティ設定の不備
- グループポリシーでのAutoenrollment設定が誤っている、あるいは適用されていない
スタンドアロンCA特有のポイント
スタンドアロン型で構築したCAサーバーは、エンタープライズCAと比べて自動登録機能が非対応だったり制限があったりします。ただし、AD CSサーバーに「Certificate Enrollment Web Service (CES)」「Certificate Enrollment Policy Web Service (CEP)」をインストールし、さらに適切な権限設定をすることでエンタープライズに近い運用も可能です。ここで設定を一部変更した場合に、既存の構成との整合性が取れなくなり、今回のような不具合を引き起こすことがあります。
ルート証明書が正しく配布されているか確認する
ドメイン参加しているPCやユーザーが、CAサーバーから発行された証明書を受け取るためには、まずルート証明書の信頼が不可欠です。信頼されたルート証明機関として認識されていない場合、各クライアントでの証明書登録プロセスが失敗する可能性が高くなります。
グループポリシー経由での配布チェック
グループポリシー (GPO) を利用すると、ドメイン全体に対してルートCA証明書を自動的に配布できます。以下に代表的な確認手順を示します。
- 「グループポリシーの管理」コンソールを開く
- ドメインレベル、または必要に応じてOUレベルにリンクされているGPOを選択
- GPOの「コンピューターの構成」→「ポリシー」→「Windowsの設定」→「セキュリティ設定」→「公開キーのポリシー」→「信頼されたルート証明機関」にルートCA証明書が登録されているか確認
もし手動でインポートしている場合は、クライアント側の「certmgr.msc」コンソール（ユーザーまたはコンピュータストア）を開いて証明書が配置されているかをチェックしてください。ここで見つからない場合や「ルート証明書が見当たらない」などの状態であれば、まずは配布設定を見直してみましょう。
証明書チェーンの整合性
中間CAを利用している場合は、中間CA証明書も含めたチェーンの状態を確認する必要があります。たとえば、以下のようにOpenSSLコマンドなどを使ってチェーンが正しいか検証できます（Linux環境での例）。
openssl verify -CAfile rootCA.crt -untrusted intermediateCA.crt server.crtこのコマンドを実行したときにエラーが出る場合は、ルートCAまたは中間CAの配布が不足している、あるいは証明書が期限切れになっている可能性があります。
Certificate Enrollment Policy (CEP) のURLとポート設定を見直す
LDAP URLからHTTP(S)ベースのURLへ切り替える際に、誤ったポート番号やホスト名の記述ミスでエラーになるケースがあります。また、ファイアウォールやプロキシ設定によって特定のポートがブロックされている場合も考慮が必要です。
URLの設定手順例
WindowsサーバーでCEPを構成する際は「サーバーマネージャー」の「役割と機能の追加」で「Certificate Enrollment Policy Web Service」と「Certificate Enrollment Web Service」を有効にします。設定完了後、下記のようなURLをクライアントのCertificate Enrollment Policy設定に手動で追加することができます。
https://<サーバーIP>:<ポート>/ADPolicyProvider_CEP_Kerberos/service.svc/CEPhttps://<ドメイン名>/ADPolicyProvider_CEP_UsernamePassword/service.svc/CEP
サーバーIPでの指定とFQDN（完全修飾ドメイン名）での指定は、DNS設定やSSL証明書との整合性を高めるため、基本的にはFQDNを推奨します。また、独自ポート（例:50000番）を使う場合は、Windows Firewallや中継機器でのポート開放を行っておきましょう。
PowerShellでのポリシー確認
Windowsクライアントやサーバーで、Certificate Enrollment Policyがどう設定されているかはPowerShellでも確認できます。以下はCEP設定を確認する簡単な例です。
# 証明書登録ポリシーを一覧表示
Get-CertificateEnrollmentPolicyServer -Scope CurrentUser
# 新規でCertificate Enrollment Policy Serverを追加
Add-CertificateEnrollmentPolicyServer -Url "https://mypkiserver:50000/ADPolicyProvider_CEP_Kerberos/service.svc/CEP" -FriendlyName "Custom CEP"設定が正しければ、Get-CertificateEnrollmentPolicyServerコマンドを実行した際に、FriendlyNameやURL情報が表示されます。万が一、URL未登録やステータスが失敗になっている場合は再登録が必要です。
証明書テンプレートの権限と配布設定
「利用可能な証明書テンプレートがない」というエラーが出るときは、証明書テンプレートに対するユーザーまたはグループの権限が不足している可能性があります。
テンプレートのセキュリティタブを要チェック
CAサーバー上の「Certificate Templates」コンソールで対象テンプレートを右クリック→「プロパティ」を選択すると、セキュリティタブで各グループ・ユーザーの権限を設定できます。必要となる主な権限は以下のとおりです。
| 権限名 | 説明 |
|---|---|
| Read | テンプレートが存在することを読み取るために必要 |
| Enroll | 証明書の手動登録・更新を行うために必要 |
| Autoenroll | 証明書の自動登録・更新を行うために必要 |
クライアントが認証用の証明書を取得する場合は、上記3つの権限がユーザーに付与されていないと「テンプレートが見つからない」あるいは「登録に失敗する」状況になります。また、ドメインユーザーに対して付与したつもりが、実は誤ったグループに権限を設定していたということもあるので、再度設定を丁寧に見直すことが大切です。
テンプレートの複数バージョンに注意
証明書テンプレートをコピーして新たに作成した場合、誤って古いバージョンのテンプレートを参照し続けていることがあります。特に自動登録ポリシーが新しいバージョンのテンプレートに対応していないと、同名のテンプレートがあっても取得できないケースがありますので、不要な古いテンプレートは無効化するなどの対応が必要です。
グループポリシーの自動登録（Autoenrollment）設定
証明書の自動登録を行うには、グループポリシーで「Autoenrollment」が有効化されている必要があります。ドメインコントローラー側での設定漏れや、ポリシーの適用タイミングの問題が起きていないか確認しましょう。
グループポリシーでのAutoenrollment有効化手順
- 「グループポリシーの管理」コンソールを開く
- ドメイン、または該当するOUのGPOを右クリック→「編集」
- 「コンピューターの構成」→「ポリシー」→「Windowsの設定」→「セキュリティ設定」→「公開キーのポリシー」→「自動登録の設定」をダブルクリック
- 「証明書を自動的に登録する」を有効にし、「以前に登録された証明書を更新する」「期限切れの証明書を更新する」オプションもチェック
ポリシー変更が終わったら「gpupdate /force」で強制更新を行うか、クライアントを再起動して、設定が反映されるのを待ちます。
トラブルシュートのコマンド例
グループポリシーが本当に適用されているかどうかは、以下のようにコマンドで確認できます。
gpresult /r上記コマンドをクライアントPCで実行すると、現在適用されているGPOの一覧が表示されます。問題のGPOが適用されていない場合は、リンク切れやフィルタリングの設定などに原因がある可能性があります。
サービスアカウントや証明書サービスの権限も要確認
AD CSサーバーの各コンポーネントや、CEP/CESサービス自体が動作しているサービスアカウントの権限が不十分なケースもあります。たとえば、サービスアカウントがローカル管理者権限を持たない場合や、ドメインコントローラーへの参照権限がなかったりすると、正しいポリシーが配信できないことがあります。
CEP/CESサービスの動作アカウント確認
Certificate Enrollment Web ServiceやCertificate Enrollment Policy Web Serviceをインストールすると、Internet Information Services (IIS) にWebサイトが作成されます。既定では「アプリケーションプールのID」がサービスを動作させる主体となる場合がありますので、以下のポイントをチェックしてください。
- アプリケーションプールに割り当てられているアカウント
- IISの「認証」設定でWindows統合認証が有効になっているか
- Kerberos認証に必要なService Principal Name (SPN) が正しく登録されているか
特にKerberosを利用する場合は、SPNの設定が欠落していると「認証に失敗する→テンプレート取得ができない」状態に陥ることがあります。setspnコマンドで対象のサービスアカウントに正しいSPNを登録するよう注意しましょう。
SPN登録コマンド例
setspn -S HTTP/<サーバーFQDN> <アカウント名>ここでHTTP/<サーバーFQDN> が必要で、かつアカウント名はアプリケーションプールで使っているドメインアカウントや仮想アカウントを指定します。既にSPNが二重登録されている場合、Kerberos認証が失敗する原因になりますので、setspn -Xで衝突をチェックしておくと安心です。
設定を洗い直しても解決しない場合は？
上記の項目を一通り見直しても問題箇所が見当たらないことがあります。今回のケースでは、結果的にPKI環境そのものを別サーバーに再構築したところ正常動作したということでした。PKI環境は複数のWindows機能やサービスが連携しているため、設定ファイルの破損やレジストリの不整合が起こっていると、原因究明が極めて困難になることもあります。
バックアップと再構築の手順を検討する
PKIはクリティカルなインフラ要素ですが、以下のような基本を押さえていれば比較的スムーズに再構築できます。
- CA証明書とプライベートキーのバックアップ
事前にcertutil -backupコマンドを利用し、CAデータベースや証明書をバックアップしておきましょう。 - テンプレートやGPO設定のエクスポート
PowerShellやGUIを利用してテンプレートの設定やグループポリシーをエクスポート・保存しておけば再構築後にすばやく復元可能です。 - ルート証明書の再配布
再構築したCAサーバーから新しいルート証明書を発行する場合は、ドメイン参加しているPCへ迅速に配布する仕組みを整えます。 - 移行計画を立てる
新旧のCAサーバーがしばらく共存する場合は、タイミングを見計らって切り替える必要があります。更新手順が複雑になるため事前に計画書を作成し、影響範囲を明確化しておきましょう。
まとめ
今回の事例では、最終的にPKI環境を別サーバー上で新たに構築することで問題を解消できました。証明書の自動登録にまつわるトラブルは、ルート証明書の配布やテンプレートの権限設定、CEP/CESのURLミス、Kerberos/SPNの不具合など多岐にわたります。特定の箇所を修正するだけで一気に解決する場合もありますが、複数の要素が絡み合うと原因究明が非常に困難です。
もし同様の事象に再度遭遇したら、以下の点を改めてチェックしましょう。
- ルート証明書と中間証明書のチェーンは正しいか
- CEP/CESのURLとポート設定は適切で、ファイアウォールで許可されているか
- 証明書テンプレートの「Read」「Enroll」「Autoenroll」権限は正しく付与されているか
- グループポリシーによる自動登録設定が適切に行われ、クライアントに適用されているか
- IISのWebアプリケーションプールや認証設定、SPN登録など、サービス側の要件を満たしているか
これでも解決しない場合には、OSやAD CSのバージョン、アップデート状況、セキュリティパッチによる影響なども踏まえながら、思い切って再構築を検討するのも一つの方法です。PKIは企業のセキュリティ基盤を支える重要要素のため、万が一トラブルが長引くと業務に大きな支障を来す可能性があります。定期的なバックアップや移行計画を立て、いつでもスムーズに環境を再構築できるようにしておくことが大切です。
コメント