MENU

Windows Server 2012 R2の2層PKI（AD CS：オフライン ルートCA＋発行サブCA）を2019へ安全に移行する手順

Windows Server

Windows Server 2012 R2で運用している2層PKI（オフライン ルートCA＋発行用サブCA／発行CA）をWindows Server 2019へ上げるなら、OSをそのままインプレースアップグレードするより「新しい2019サーバーへCAを移行（マイグレーション）する」方がトラブルを抑えやすく安全です。鍵・DB・設定を引き継ぎつつ、CDP/AIA/CRLを崩さない手順を整理します。

目次

なぜ「インプレースアップグレード」より「移行（新サーバーへ乗せ替え）」が現実的なのか

AD CS（Active Directory Certificate Services：証明書サービス）は、稼働実績の長い環境ほど拡張設定や例外運用が積み重なり、OSアップグレード時の想定外が出やすい役割です。特に2層PKIでは、発行CAの停止＝社内の証明書更新や自動登録が止まるだけでなく、CRL（失効リスト）の公開に失敗すると「既存の証明書の検証」まで影響します。そこで多くの現場では、既存CAを温存しつつ、新サーバー側で復元して切り替える移行方式が選ばれます。

方式メリットデメリット／リスクおすすめ度
OSのインプレースアップグレードホスト名やIP、公開先が変わらず見た目は簡単失敗時の切り戻しが重い／役割・ミドルウェアの依存で不具合が出る／原因切り分けが難しい低〜中（要検証）
新Server 2019へCAを移行（鍵・DB・設定を復元）旧環境を残して切り戻せる／新OSへ段階的に移れる／構成が整理できるCDP/AIA/CRL設計が悪いとホスト名変更で影響が出る高（一般に現実的）

2層PKI移行の大原則（ここを外すと信頼関係が崩れます）

  • ホスト名は変わってもよい（新しいServer 2019でOK）。ただし、クライアントが参照するURLやDNSは別問題です。
  • CA名（Certification Authority 名）は旧環境と同一にする（最重要）。
  • CA証明書＋秘密鍵は引き継ぐ（新規作成しない）。鍵が変わると「別の認証局」になり、既存の信頼・証明書チェーンが崩れます。
  • 移行に必要なバックアップは概ね「鍵」「DB/ログ」「レジストリ（CertSvc配下）」の3点セット。
  • 2層は1台ずつ切り替える。ルートCAと発行CAを同時に触らない。

まずやるべき事前調査（このメモが移行成功率を上げます）

移行作業そのものより、「現状把握」と「公開先の安定化」が重要です。作業前に、最低限次の情報を控えておきます。

確認項目目的確認のしかた（例）
CA種別（Enterprise/Standalone、Root/SubCA）手順・AD連携の有無が変わる認証局コンソール、certutil -cainfo
鍵プロバイダー（CSP/KSP、HSM有無）新サーバー側に同じプロバイダーが必要認証局のプロパティ、イベントログ
CA DB/ログの格納パス復元時のパス差異を潰す認証局のプロパティ「データベース」
CDP/AIA（CRL公開先／CA証明書公開先）失効確認トラブルを防ぐ認証局の拡張、certutil -getreg CA\CRLPublicationURLs
CRLの有効期限（Next Update）移行中にCRLが切れる事故を防ぐ発行済みCRLを確認、certutil -dump
発行テンプレート（発行CAが何を出しているか）自動登録や更新停止を防ぐcertutil -catemplates、CAコンソール

バックアップで押さえる3点セット

「CA証明書＋秘密鍵」「CAデータベース＋ログ」「CAのレジストリ設定（CertSvc配下）」が揃うと、ほとんどの移行が成立します。加えて、運用で変更しているファイル類（CAPolicy.inf、スクリプト、CRL公開用の共有やIIS設定など）も忘れずに控えます。

バックアップ対象なぜ必要か取得方法の例注意点
CA証明書＋秘密鍵（PFX等）同一CAとして継続するため認証局コンソール「CAのバックアップ」、またはcertutil -backupKey強力なパスワードで暗号化し、オフライン保管
CA DB（certsrv.mdb）＋ログ発行履歴・失効情報・連番など継続認証局コンソール「CAのバックアップ」、またはcertutil -backupDBサービス停止中に取得（整合性）
レジストリ（CertSvc\Configuration配下）CDP/AIA、監査、拡張設定の復元reg export でエクスポート復元は慎重に（上書き範囲を限定）
CAPolicy.inf、カスタムスクリプトポリシーや発行要件が変わる事故防止ファイルコピー手順書と一緒に保管
CRL公開用のWeb/共有設定CDP到達性を維持するIIS設定控え、共有権限控えホスト名変更の影響が出やすい

バックアップ取得の実行例（発行CA／ルートCA共通の考え方）

GUI（認証局コンソールのバックアップ/復元）で揃えるのが一番安全ですが、コマンドで記録を残したい場合の例も載せます。環境によりパスや権限は調整してください。

REM 1) サービス停止（発行中の要求がある場合は業務影響に注意）
net stop certsvc

REM 2) CAデータベース＋ログのバックアップ
certutil -backupDB D:\CA_Backup\DB

REM 3) CA証明書＋秘密鍵のバックアップ（パスワードが求められます）
certutil -backupKey D:\CA_Backup\Key

REM 4) レジストリ（CertSvc配下）をエクスポート
reg export "HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration" D:\CA_Backup\CertSvc_Configuration.reg /y

REM 5) サービス再開（移行当日に停止するなら不要）
net start certsvc

バックアップは「盗まれたら終わり」です。特にルートCAの秘密鍵は、暗号化・物理保管・アクセス権の最小化を徹底してください。

移行の全体像（2層PKIを安全に切り替える順序）

移行順序は環境次第ですが、よくある現場の進め方は次の2パターンです。

  • パターンA（おすすめ）：発行CA（サブCA）→ ルートCA（オフライン）
    業務影響が大きい発行CAを先に片付け、ルートCAは発行業務が少ないため最後に落ち着いて実施できます。
  • パターンB：ルートCA（オフライン）→ 発行CA（サブCA）
    「まず最上位を固めたい」場合はこちら。ただし発行CA移行と同時期にCRL公開先を触ると事故りやすいので、変更点を分離します。

どちらでも共通なのは、同じCA証明書＋秘密鍵を使うCAを2台同時に稼働させないことです（重複発行や状態不整合の原因になります）。

発行用サブCA（発行CA）を Windows Server 2019 に移行する手順

ここでは一般的な「ドメイン参加のEnterprise Subordinate CA（発行CA）」を想定します。NDESやOCSP、Web Enrollmentなどを併設している場合は追加作業が発生するため、役割を分離するか、別途移行計画を立ててください。

移行前にやっておくと効く“地味な準備”

  • CRLの期限を確認し、切り替え期間をまたいで有効なCRLを発行する（Next Updateが近いと、移行中に検証エラーになります）。
  • 「CDP/AIAに旧サーバー名が埋め込まれている証明書」が社内にどれだけ残っているか把握する（特に長期証明書）。
  • CAサーバーに依存している公開（IISのCertEnroll、ファイル共有、DNS名）を棚卸しする。

手順（発行CA）

  1. 旧発行CAでバックアップ取得
    • CA証明書＋秘密鍵
    • CAデータベース／ログ
    • レジストリ（CertSvcのConfiguration配下など）
    • （任意）テンプレート一覧、監査設定、発行停止リスト、CRL公開先の控え
  2. 新Server 2019を用意
    • Windows Update適用、時刻同期、バックアップ先の確保
    • Enterprise CAの場合はドメイン参加（旧と同等のOU/ポリシーに置くと管理が楽）
    • 旧CAがHSMや特定の暗号プロバイダーを使っているなら、ドライバーやミドルウェアを先に導入
  3. AD CS（証明書サービス）をインストール
    • 役割：Active Directory Certificate Services
    • 役割サービス：Certification Authority（必要に応じて追加）
  4. AD CS構成（ここが肝）
    • CA種別は旧と同じ（Enterprise Subordinate CA 等）
    • 「既存のCA証明書（秘密鍵）を使用」を選択し、バックアップした鍵をインポート
    • CA名は旧と同一にする
    • DB/ログの保存先も旧に寄せる（パス差異による復元トラブルを避ける）
  5. CAデータベース／ログを復元
    • 認証局コンソールの「CAの復元」または certutil -restoreDB
    • 復元後はサービスの起動確認、イベントログ確認
  6. レジストリ設定を復元
    • Exportした CertSvc_Configuration.reg を必要範囲だけ取り込む
    • 特にCDP/AIA、監査、CRL発行間隔、署名アルゴリズム関連は念入りに確認
  7. CRL/AIA/CDPの公開設定を確認し、CRLを再発行して配置
    • CRLを新サーバーから発行し、HTTP/LDAP等の公開先に配置されること
    • 旧証明書が参照するURLが継続して到達できること（ここが最大の落とし穴）
  8. 発行テストと動作確認
    • テスト用テンプレートで発行（手動要求＋自動登録）
    • 失効確認（CRL到達性）
    • 証明書チェーン（ルート→発行CA）が正しいこと
  9. 問題なければ旧発行CAを退役
    • しばらくは電源断＋隔離で保管（切り戻し余地）
    • 最終的に役割削除、証明書サービスの登録情報整理

発行CA移行でよくある失敗パターン

  • CRL配布先（CDP）が旧サーバー名のままで、旧サーバー停止と同時に失効確認が失敗する。
  • DBを復元する前に新CAで証明書を発行してしまい、連番や履歴がずれる（追跡・監査に支障）。
  • 鍵プロバイダーが違う（HSM、CSP/KSPの差）ため、既存鍵が読み込めない。
  • テンプレート発行の設定が戻っておらず自動登録が止まる（発行CAの設定とAD側の両面を確認）。

オフライン ルートCA を Windows Server 2019 に移行する手順

オフライン ルートCAは「普段電源を入れない」前提のため、移行タイミングの自由度は高い一方、秘密鍵の取り扱いが最重要です。移行作業は、できれば“儀式（セレモニー）”として記録が残る形にし、担当者・持ち出し・保管を明確にします。

手順（オフライン ルートCA）

  1. 旧ルートCAでバックアップ取得（オフラインで実施）
    • CA証明書＋秘密鍵（最重要）
    • CAデータベース／ログ（発行履歴が必要なら）
    • レジストリ（CertSvc設定）
  2. 新Server 2019（オフライン用）を構築
    • ネットワークから切り離した状態でセットアップ（必要なパッチはオフライン適用を検討）
    • 管理者アカウント、BitLocker等のディスク保護、物理保管場所を決める
  3. AD CSをインストールしてルートCAを構成
    • Standalone Root CA（一般的）
    • 既存のCA証明書（秘密鍵）を使用
    • CA名は旧と同一
  4. DB/ログ、レジストリを復元
    • 認証局コンソールで復元し、サービス起動を確認
    • CRL発行間隔や公開先設定が想定通りか確認
  5. ルートCRL（必要ならデルタCRLも）を再発行し、公開先へ配置
    • ルートCRLはクライアントが失効確認で参照するため、公開先の到達性が最優先
    • 公開先がWebサーバーなら、アップロード手順（USB→中継→配置など）を固定化
  6. チェーン検証と運用手順の更新
    • 発行CA証明書の検証、ルートCRLの取得、期限確認
    • 「次にルートCAを起動するタイミング」「CRL更新手順」を手順書に反映

最大の落とし穴：CDP/AIAが“サーバー名依存”だと詰みやすい

CA移行で一番事故が多いのが、クライアントが参照するURL（CDP/AIA）が旧サーバー名のまま消えるケースです。重要なのは次の2点です。

  • 新しく発行する証明書：移行後のCDP/AIA設定が反映される
  • すでに発行済みの証明書：埋め込まれた旧URLのまま（書き換わらない）

つまり、旧URLは「対象証明書が全部失効・更新・期限切れ」になるまで生かす必要があります。

よくあるCDP/AIAの例ホスト名変更の影響現実的な回避策
http://OLD-CA/CertEnroll/...旧サーバー停止で失効確認が失敗しやすいDNS CNAMEでOLD-CAを新公開先へ向ける／HTTPリダイレクト
file://\\OLD-CA\CertEnroll\...（SMB）CNAME運用が難しい（SPN/Kerberos等）可能ならHTTPへ寄せる／当面は旧名で共有を提供する仕組みを用意
ldap:///CN=... ,CN=CDP,CN=Public Key Services,...ADが生きていれば比較的強いEnterprise CAならLDAP公開を有効にし、HTTPと併用して冗長化
PKI専用DNS（例：http://pki.example.jp/pki/...）CAホスト移行の影響が最小“CAサーバー名をURLに入れない”設計へ段階的に移行

今後の移行を楽にするなら、CDP/AIAは「CAサーバーの実名」ではなく、PKI用の安定した名前（pki.company.exampleなど）に寄せておくのが定石です。既存証明書の旧URLは残しつつ、新規発行分から徐々に安定URLへ誘導できます。

移行後に必ずやる動作確認（チェックリスト）

「証明書が発行できた」だけでは不十分です。失効確認と自動登録まで通して初めて完了です。

確認項目確認内容合格ライン
CAサービス稼働CertSvcが正常起動、イベントログに致命的エラーなし再起動しても安定
証明書発行手動要求とテンプレート発行ができる発行・更新が通る
自動登録（Autoenrollment）クライアントがテンプレートに従い自動取得/更新できるGPO適用後に自動取得
失効確認（CRL到達性）クライアントがCDPからCRLを取得できる社内主要セグメントでOK
チェーン検証ルート→発行CA→エンド証明書が正しい警告なく検証OK
運用タスクCRLの定期発行、バックアップ、監査ログ取得が従来通り手順書通りに回る

切り戻し（ロールバック）の考え方

移行方式の強みは、旧CAを温存できることです。ただし「同じCA鍵」を2台で同時稼働させないルールは守ります。

  • 新CAで問題が出たら、新CAを停止し、旧CAを再度起動して発行を再開する。
  • CRL公開先を変更している場合は、旧CA復帰時に旧URLにCRLが置かれる状態へ戻す（DNS戻し／公開ファイル差し替え）。
  • 「移行中に発行した証明書」があると混乱するため、テストと本番切替の境界を明確にする。

2019化のタイミングで見直すと効果が大きい運用改善

  • CRL公開をCAサーバーから分離：CAは発行に専念し、公開はWebサーバー（DMZ含む）へ。次回移行が劇的に楽になります。
  • CAバックアップの定期化：鍵とDBのバックアップ世代管理（オフサイト保管）をルール化。
  • 監査ログの保全：発行・失効の証跡はインシデント時に効きます。保存期間・転送先を明確に。
  • “OS移行”と“暗号強度変更”を分ける：鍵長やアルゴリズム（SHA-1→SHA-256等）変更は別プロジェクトとして設計し直す方が安全です。

よくある質問

ホスト名を変えても本当に大丈夫？

CAそのもの（CA名と鍵）が同じであれば動きますが、クライアントが参照するCDP/AIA/CRLに旧ホスト名が埋め込まれていると失効確認で詰みます。“ホスト名変更OK”と“公開URL維持”は別問題として設計してください。

ルートCAと発行CA、どちらを先に移行すべき？

一般には、業務影響が大きい発行CAを先に移し、最後にオフライン ルートCAを落ち着いて移行する流れが多いです。ただし、CDP/AIAの変更を絡める場合は、変更点が同時にならないよう分けて進めるのが安全です。

鍵を新規作成して“ついでに強化”してもいい？

やりたくなるポイントですが、鍵を変えると「別のCA」になり、既存の信頼とチェーンに影響が出ます。まずは同一CAとして移行し、その後に計画的な更新（新CAの並行稼働、信頼配布、テンプレート切替）として実施するのが現実的です。

2層PKIの移行は、手順そのものより「依存関係（特にCRL公開）」の設計が勝負です。鍵・DB・設定を正しく引き継ぎ、1台ずつ切り替え、公開URLを崩さない。これを守れば、Windows Server 2012 R2から2019への更改は高確度で成功します。

Windows Server
Windows Server 2019 PKI AD CS CRL 認証局

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次