新しいサーバーに認証局を移行したのに、なぜか証明書失効リスト(CRL)の参照が上手くいかない…。そんなトラブルに頭を抱えている方も多いのではないでしょうか。本記事では、旧サーバーで動いていたCA環境を新サーバーへ移行した際に起こりがちなCDP(Certificate Revocation List Distribution Point)ダウンロード失敗やAIA(Authority Information Access)設定の不整合を中心に、解決までの流れをわかりやすく解説していきます。
旧サーバーから新サーバーへの移行で起こる主な問題とは
移行プロセスで特に悩まされるのは、Active Directory(AD)に残る古いサーバーの参照や、CAの設定情報が意図せず残り続けることでしょう。移行後もCRLを旧サーバーから取りに行こうとして失敗するケースや、AIAのURLが過去のまま更新されないケースが多く見られます。ここでは、具体的にどのような問題が起きるのか、またその原因は何なのかを深堀りしていきます。
CDPダウンロード失敗の理由
CDPダウンロード失敗の典型的な原因の一つは、証明書に埋め込まれているCRLの配布ポイントが古いままになっていることです。旧サーバーで運用していた際のURLやホスト名が参照され続けていると、新サーバー側にデータが存在していても正しくアクセスできません。証明書が失効リストを正常に取得できないと、クライアントは証明書の有効性検証に失敗してしまいます。
AIA(Authority Information Access)の参照先が古い
AIAとは、証明書から発行者情報やOCSPレスポンダーの場所などを取得するためのエンドポイントが定義される部分です。この設定が古いサーバーのままになっていると、証明書のチェーンを正しく検証できず、最終的には「認証局の情報にアクセスできません」「チェーンの整合性が取れません」といったエラーが発生する可能性があります。
Active Directory上の古いエントリが残る
旧サーバーを完全にアンインストールする、もしくは名前を変更する前にAD上の情報を消しきれていないと、AIAやCDP、または他の証明書関連情報が残存し、移行後のCA設定と競合することがあります。証明書のテンプレート設定やLDAP参照先も複雑に絡んでおり、細部を見落とすと問題を引きずることになりがちです。
移行時の基本的な流れと注意点
ここでは、CAサーバーを移行する際の一般的な流れと、それぞれのステップで気をつけるべきポイントを具体的に紹介します。単純に新サーバーにRoleをインストールして古いデータを移すだけではなく、ADやDNSなど、ネットワーク全体の整合性を考慮することが大切です。
1. 新サーバーでのAD CSサービスのインストール
Windows Serverの「役割と機能の追加」でActive Directory Certificate Servicesをインストールします。インストールウィザードで、「証明機関(CA)」「証明書登録ポリシーWebサービス」「証明書登録Webサービス」など必要に応じてコンポーネントを選びましょう。
インストール時の注意点
- CAの種類(エンタープライズCAなのかスタンドアロンCAなのか)
- ルートCAか下位CAかの階層構造
- インストール先のサーバーがドメインに参加済みかどうか
特にエンタープライズCAとして運用する場合は、ドメインに正しく参加しているか事前に確認してください。
2. 旧サーバーからのCA設定エクスポート
証明書サービスの設定やキー情報は、バックアップ機能を用いてエクスポートします。以下の手順例を示します。
1. certsrv.mscを開く
2. CA名を右クリックして「すべてのタスク」→「バックアップ」を選択
3. 秘密キー(プライベートキー)とCA構成情報を含むように選択
4. パスワードを設定し、バックアップファイルを安全な場所に保存このバックアップファイルを使い、新サーバー側に同じ設定を復元するのが基本的なやり方です。ただし、復元する前にAIAやCDPのパス設定を再度確認し、旧サーバーの情報がハードコードされていないかチェックするのが賢明です。
3. 新サーバーへの設定インポートとCA起動
新サーバーでAD CSをインストールした後、同じウィザードもしくは「certsrv.msc」管理コンソールからバックアップファイルを読み込みます。移行後のサーバー名やディレクトリ構成に応じて、細部のパスを修正することを忘れないようにしましょう。
インポート時のポイント
- プライベートキーの保護パスワードを正しく入力
- CA名が旧サーバーと異なる場合は整合性をよく確認
- ドメインコントローラーやDNSのレコードが新サーバーを正しく指すようにしておく
CAを起動した後に、イベントビューアーやcertsrv.msc上でエラーが出ていないかを必ず確認してください。
AIAとCDP設定を正しく更新する方法
旧サーバーへの参照を断ち切るためには、AIAとCDPの設定を正しく更新することが最重要ポイントです。以下では、具体的な操作手順を紹介します。
certsrv.mscでの設定確認
- 「certsrv.msc」を起動し、左ペインで移行先のCAを右クリックしてプロパティを開きます。
- 「拡張機能」タブを選択すると、AIAやCDPのURL一覧が表示されます。
- 古いサーバー名が含まれるURLがあれば、以下のように編集または削除します。
| 操作手順 | 説明 |
|---|---|
| 選択して「削除」 | 不要なURL（旧サーバー名を含む）の行を削除します |
| 「編集」ボタンを押す | 新しいサーバー名、FQDN、パス（例：http://新サーバー名/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl）などを正しく設定 |
| 「場所を追加」 | 必要があれば、新しいURLを追加し複数の配布ポイントを設定可能。可用性を高めるためにHTTPやLDAPなど複数パスを持たせることを推奨 |
設定を反映するためには、変更を確定後にCAサービスを再起動するか、しばらく待機してADにレプリケーションされるのを待つ必要があります。
adsiedit.mscでのAD上の古いエントリ削除
AIAやCDPの情報はAD上にも格納されています。旧サーバー名が残っていると、証明書のチェーンビルド時やCRL取得時にそちらを参照してしまうことがあります。不要エントリを削除する場合は以下のような手順をとります。
- 「adsiedit.msc」を起動。
- コンテキストメニューから「接続先」を選択し、「コンフィグレーション コンテキスト」を指定。
CN=Public Key Services,CN=Services,CN=Configuration,DC=ドメイン名,DC=comを展開。- 「AIA」「CDP」「Enrollment Services」などのコンテナを見て、古いサーバー名が含まれるオブジェクトを確認。
- 不要なオブジェクトを右クリックして「削除」を選択。
- ADに複数DCがある場合、レプリケーションが行われた後に再度設定を確認。
注意点として、誤って必要なエントリを消すと環境全体のPKIが破綻する恐れがあります。削除前には対象オブジェクトのプロパティをスクリーンショットで残すなど、念入りなバックアップ・確認を行いましょう。
PKIViewでの状態確認とトラブルシューティング
移行後の動作確認には「pkiview.msc」が便利です。このツールを使うことで、証明書チェーンの状態やCRL取得の可否を一元的にチェックできます。古いサーバー名の参照が残っている場合、「エラー」や「警告」が表示されるので、一目で問題を特定しやすくなります。
PKIViewの主な画面と項目
- Enterprise PKI: AD上のPKI全体のステータスを一覧表示
- Revocation: CRLの有効期限や取得先URLを一覧表示
- CA Certificates: 各CAのAIA情報などをまとめて確認
特にCRLの項目で古いURLが残っているかをチェックします。もしリストに古いサーバー名が表示されていたら、前述のcertsrv.mscやadsiedit.mscでの修正が完了していない可能性があります。
よくあるトラブルシューティングのポイント
- DNS設定を再確認
新サーバーのFQDNが正しくDNSに登録されているか、旧サーバーのエントリが残っていないかなど、DNS周りの不備は意外と多いです。 - ファイアウォールの通信設定
HTTPやLDAPでの参照時に、ファイアウォールやプロキシが原因で通信がブロックされていないか確認しましょう。 - タイムアウト・認証設定
サーバー移行によってSPN(Service Principal Name)やKDC(Key Distribution Center)との兼ね合いで認証が失敗している可能性も考慮しましょう。
CA証明書の再発行(更新)が必要になるケース
移行後にどうしても古い設定が残ってしまい、上書きや削除がうまく行かない場合、CA証明書そのものを更新(Renew)する方法があります。CA証明書を更新すると、CRL Distribution PointやAIAの情報が新規発行時に再度書き込まれるため、結果的に正しいサーバー名で配布されるようになるケースが多いです。
CA証明書更新の手順
- 「certsrv.msc」を開いてCAを右クリック
- 「すべてのタスク」→「CA証明書の更新(Renew CA Certificate)」を選択
- 秘密キーを再利用するか、新規の秘密キーを生成するか選択
- 更新後、PKIViewなどでAIA・CDPが正しく新サーバーを指しているか確認
ただし、ルートCAを更新する場合は、子CAや配下の証明書に影響を与える可能性があるため、慎重に検討してください。場合によっては、新しいルート証明書を組み込むために全クライアントに再設定が必要になることもあります。
具体的な対処事例とベストプラクティス
実際の運用現場では、移行後に「古いサーバー名が参照され、CRLを取得できない」というエラーが起きたものの、adsiedit.mscで明示的に不要エントリを削除し、最終的にCA証明書を更新することで解消されたという事例があります。
ここでは、そんな事例を参考にしたベストプラクティスを示します。
ベストプラクティス
- 移行前に現行の設定をフルバックアップ
- CAの設定のみならず、AD DS全体のシステムステートバックアップなど、万が一に備えたフルバックアップを取得。
- 移行先サーバーでのテスト環境用CAで動作確認
- 本番CAと同じ設定をテスト用環境に復元して、AIAやCDPが正しく参照されるか検証。
- 段階的な削除とPKIViewでの検証
- adsiedit.mscで古いエントリを削除したらすぐにPKIViewをチェックし、ステータスがどう変化するか確認。
- 必要に応じてCA証明書の更新を検討
- どうしても古い設定を上書きできない場合に更新を行うと、AIA・CDPが正しい状態に再構築される。
- DNSと証明書の有効期限にも注意
- 移行のタイミングでDNSの参照先が変わり、旧サーバーへ名前解決していないか定期的に確認。
- 証明書の有効期限が迫っている場合、更新作業と移行作業を同時に進めると混乱が生じる可能性がある。余裕をもって計画する。
具体的な操作例
以下は、移行後のPKIトラブルシューティングを行う際によく利用されるコマンド例です。
# CAの構成情報を確認
certutil -cainfo config
# CRLを強制的に再発行
certutil -dspublish -f <CRLファイルへのパス> "SubCA"
# AD上のCRL参照を確認
certutil -url <証明書ファイルへのパス>
# CAサービスの再起動(サービス名が"CertSvc"の場合)
Restart-Service CertSvcこれらを組み合わせて、CRLが正しく配布されているかどうかを逐一確認することが大切です。
まとめ
CA移行後にCDPダウンロードが失敗し、PKIViewにエラーが出る原因の大半は、旧サーバー名がAIAやCDPの設定として残っていることにあります。移行前に適切な手順で設定を引き継ぐだけでなく、移行後にadsiedit.mscやcertsrv.msc、さらにpkiview.mscを活用して不要なエントリを削除・修正し、正しいURLを反映させることが重要です。それでも問題が解消しない場合、CA証明書を更新することでAIAやCDP情報が再発行され、解決するケースがあります。
運用環境によっては、独自のセキュリティ要件やDNS構成、GPOの設定など、さまざまな要素が絡み合う可能性があります。そのため、本番環境での移行前にテスト用環境で十分に検証し、リスクを最小化することが理想です。
本記事で紹介したポイントと手順を押さえておけば、旧サーバーから新サーバーへのCA移行で起こりがちなトラブルを大幅に軽減し、スムーズな運用を実現できるはずです。
コメント