MENU

Enterprise CA移行で証明書テンプレートは残る？保存場所と再公開手順（AD CS）

Active Directory

Windows Server の AD CS（Enterprise CA）を新サーバーへ移行するとき、「カスタムした証明書テンプレートの設定は残るのか？」「どこに保存されていて、移行後に作り直しが必要なのか？」で手が止まりがちです。テンプレートの“本体”と“CAで発行できる状態にする設定”を分けて理解すると、移行作業が一気に整理できます。

目次

結論：テンプレートは「ADに残る」、移行後に確認すべきは「CAで発行できる状態か」

Enterprise CA（AD連携CA）の「証明書テンプレート」は、CAサーバーのローカルに“設定値として保存されている”のではなく、Active Directory の構成情報（Configuration）側にオブジェクトとして保存されています。つまり、同一フォレスト内での Enterprise CA 移行であれば、テンプレート定義（カスタム設定）自体は基本的に残り、作り直しは不要です。

一方で、移行後の新しいCAが「そのテンプレートを発行してよいCA」として公開されていない場合、クライアントから見える挙動は“テンプレートが無い”ように見えます。ここが混乱ポイントです。

論点答え移行後にやること
カスタム証明書テンプレートの設定は残る？同一フォレストなら基本残る（ADに保存）テンプレート定義の再作成は通常不要
設定はどこに保存？Active Directory（Configuration）配下のテンプレートオブジェクトAD上に存在するか確認（certtmpl.msc / AD照会）
移行後に再設定が必要？多くは不要。ただし“CAが発行するテンプレート”の設定は確認必須新CAでテンプレートを「発行（公開）」する
別フォレストへ移す場合は？テンプレートが存在しないため原則再作成ターゲット側でテンプレートを作り直し、権限も再設計

まず押さえる前提：Standalone CAには「証明書テンプレート」機能がない

証明書テンプレートは、Active Directory と連携する Enterprise CA（AD CS の Enterprise Root/Enterprise Subordinate）で使う仕組みです。Standalone CA ではテンプレートを使った自動登録（Autoenrollment）や、テンプレートに基づく申請制御は行いません。

項目Enterprise CAStandalone CA
証明書テンプレート利用する（ADにテンプレート定義）利用しない
自動登録（Autoenrollment）可能（GPOとテンプレート権限で制御）基本不可
テンプレートの管理ツールcerttmpl.msc（AD上のテンプレートを管理）対象外
移行での焦点AD上の定義＋新CAでの公開（発行）状態CAローカル設定中心

「テンプレートの設定」はどこに保存されているのか

Enterprise CA の証明書テンプレートは、Active Directory の構成パーティション（Configuration naming context）に格納されます。代表的な保存先（LDAPパスのイメージ）は以下です。

CN=Certificate Templates,
CN=Public Key Services,
CN=Services,
CN=Configuration,
DC=example,DC=com

ここにある各テンプレートは「オブジェクト」として存在し、テンプレートのプロパティで設定する内容（有効期間、秘密鍵設定、拡張キー使用法、サブジェクト名のルール、発行要件、セキュリティなど）が属性として保持されます。フォレスト内のドメインコントローラー間でレプリケーションされるため、CAサーバーを入れ替えてもテンプレート定義自体は“残って見える”のが基本動作です。

テンプレート設定の“中身”を分解すると理解が早い

「テンプレート設定」と一口に言っても、実務上は次のような要素の集合です。移行で残る／残らないを切り分けるために、ここを押さえておくと事故が減ります。

設定カテゴリ具体例主な保存先の考え方
証明書の仕様有効期間、更新期間、キー長、ハッシュ、EKU/KUテンプレート定義（AD）
件名（Subject）ルールCN自動生成、SAN、AD属性からの展開テンプレート定義（AD）
発行要件マネージャ承認、署名数、登録エージェント要否テンプレート定義（AD）
セキュリティ（誰が申請できるか）Enroll / Autoenroll の権限、読み取り権限テンプレートのACL（AD）
“どのCAがこのテンプレートを発行するか”CAコンソールで「発行するテンプレート」に追加CA側の公開（発行）設定（CAローカル＋AD側に反映）

「CAで発行できるテンプレート一覧」はどこに保存されるのか

テンプレートの定義そのものはADにありますが、「このCAはどのテンプレートを発行するCAか」という“公開（発行）状態”は、CAごとの情報として扱われます。ここが、移行時に再設定が必要になりやすいポイントです。

実務的には次の2段構えで理解すると安全です。

  • テンプレート定義：AD（Configuration）に存在
  • CAが発行対象として公開しているテンプレート：CAコンソールの「発行するテンプレート」設定（移行後に要確認）

さらに深掘りすると、CAの情報もAD側に“CAオブジェクト”として登録されます。よく参照される場所のイメージは以下です（CA名の部分は環境で異なります）。

CN=<CAの表示名>,
CN=Enrollment Services,
CN=Public Key Services,
CN=Services,
CN=Configuration,
DC=example,DC=com

ここには「そのCAが発行可能として公開しているテンプレート」の情報が載ります。移行時にCAを“復元”するのか、“新規に別CAとして作る”のかで扱いが変わりますが、どちらのパターンでも最終的には新CAのコンソールで「発行するテンプレート」が正しく設定されているかが重要です。

同一フォレスト内のEnterprise CA移行：テンプレート定義は基本そのまま、公開状態を整える

同一フォレスト内での移行（既存ADの中でCAサーバーを入れ替える）なら、カスタムテンプレートの“定義”はAD上にあるため、テンプレートを作り直す必要は通常ありません。移行後にやるべき作業は、次の確認・整備です。

  • 新サーバーのCAがEnterprise CAとして構成されている（Standaloneになっていない）
  • AD上にテンプレートが存在する（certtmpl.msc で確認）
  • 新CAで必要テンプレートが「発行するテンプレート」に追加されている
  • テンプレートの互換性（最小CA/OSなど）が新CAに合っている
  • テンプレートのセキュリティ（Enroll/Autoenroll）とGPOが意図どおり

移行パターン別：何が残って、何を手当てするか

移行パターンテンプレート定義CAが発行するテンプレート設定現場での推奨アクション
同一フォレストでCAを復元（バックアップから復元）ADに残る復元内容次第だが、最終確認は必須CAコンソールで「発行するテンプレート」を必ず点検
同一フォレストで“新しいCA”として作成（CA名も別）ADに残る新CAは未設定になりやすい必要テンプレートを新CAで発行（公開）する
別フォレストへ移行存在しない存在しないターゲット側でテンプレートを再作成し、権限も再設計

新しいCAでテンプレートを「発行（公開）」する具体手順

テンプレート定義がADに残っていても、新CAがそのテンプレートを発行対象として公開していないと、申請や自動登録で使えません。移行後は、まずここを整えます。

  1. 新CAサーバーで「証明機関」管理ツール（Certification Authority / certsrv.msc）を開く
  2. 左ペインの「証明書テンプレート（Certificate Templates）」を選択
  3. 右クリックして「新規作成（New）」→「発行する証明書テンプレート（Certificate Template to Issue）」を選択
  4. 一覧から必要なテンプレート（カスタムテンプレート含む）を選んで追加
  5. 必要に応じてCAサービスや管理コンソールを再起動し、クライアント側の表示も確認

ここで追加するのは「テンプレートを作り直す」作業ではなく、“このCAはこのテンプレートを発行してよい”という公開設定です。テンプレートの本体（定義）がADにあるからこそ、同一フォレスト移行ではこの作業で整うことが多いです。

「certutilでエクスポートすると一覧しか出ない」理由と、正しい確認ポイント

certutil でテンプレートを“エクスポート”しようとして一覧しか見えないのは、そもそもテンプレート定義がCAローカルに閉じていないためです。CAバックアップ（DB/秘密鍵/レジストリ）に含めて移動する対象ではなく、ADのオブジェクトとして管理されます。

テンプレート設定の確認は、次のどれかで行うのが実務的です。

確認方法向いている用途ポイント
certtmpl.msc（証明書テンプレート）GUIで設定値を目視確認カスタムテンプレートのタブ構成（一般/要求処理/暗号化/互換性/セキュリティ等）をそのまま確認できる
ADの属性をPowerShellで取得監査・棚卸し、差分管理、バックアップの控え“設定の証跡”をCSVなどで残せる（ただし完全再現は別作業）
CAコンソール（certsrv.msc）そのCAで発行可能かの確認「発行するテンプレート」に載っているかが最重要

PowerShellで「テンプレートがADに存在するか」を棚卸しする例

移行前後で「テンプレート定義が残っているか」を客観的に確認したい場合は、ADから一覧を取得して控えを作るのが有効です（RSAT/ActiveDirectoryモジュールが使える端末で実行）。

$base = "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com"
Get-ADObject -SearchBase $base -LDAPFilter "(objectClass=pKICertificateTemplate)" -Properties displayName,whenChanged |
  Select-Object Name,displayName,whenChanged |
  Sort-Object displayName |
  Export-Csv ".\certificate-templates.csv" -NoTypeInformation -Encoding UTF8

このCSVを移行前に取っておくと、「移行で消えた」のではなく「発行設定が外れている」「互換性で表示されない」など、原因切り分けがしやすくなります。

移行後に「テンプレートを発行できない／一覧に出ない」時の典型チェック

コメント等で多いのが「証明機関コンソールの“発行するテンプレート”追加画面に、目的のテンプレートが出てこない」パターンです。よくある原因を上から潰すと復旧が早いです。

症状よくある原因チェック／対処
テンプレート機能そのものが見当たらない新CAがStandalone CAになっているAD CSの構成を確認し、Enterprise CAとして構成されているか点検
テンプレートはADにあるのに、発行一覧に出ない互換性要件が合わない（最小CA/OSなど）certtmpl.mscでテンプレートの「互換性」タブを確認し、新CAのバージョン要件に合わせる
一部の管理者だけ操作できない権限不足Enterprise Admin相当の権限、またはCA管理権限/テンプレート管理権限を確認
移行直後だけ見えない／他のDCでは見えるADレプリケーション未反映レプリケーション状況確認、時間を置く、管理コンソール再起動
テンプレートが“別フォレスト由来”移行先フォレストにテンプレートが存在しないターゲット側でテンプレートを再作成（後述）

見落としがちなポイント：クライアントは「テンプレートのキャッシュ」と「GPO」の影響を受ける

CA側で発行設定を追加しても、クライアントがすぐに新しいテンプレートを表示しないことがあります。自動登録を使っている場合は特に、次の要素が絡みます。

  • グループポリシー（自動登録の有効化、更新タイミング）
  • テンプレートのセキュリティ（Enroll / Autoenroll 権限）
  • クライアント側の更新（gpupdate、証明書ストアの再評価）

「テンプレートが消えた」と早合点せず、まずはAD上にテンプレートが存在することと新CAで発行設定が入っていることを確認すると、原因に最短で到達できます。

別フォレスト（フォレスト間）移行が別物になる理由

別フォレストへ移行する場合、テンプレート定義は“元フォレストのAD”にしか存在しません。移行先フォレストにはテンプレートが存在しないため、原則としてターゲット側でテンプレートを再作成します。

また、テンプレートのセキュリティは「元フォレストのユーザー／グループ」に紐づくため、たとえ設定値をコピーできたとしても、そのままでは運用に耐えません。フォレスト間移行は、テンプレートの再設計（権限・申請フロー・名前ルール）を含む“PKI再構築”として扱うのが安全です。

別フォレスト移行での現実的な進め方

  • 元フォレストで、カスタムテンプレートの設定を棚卸し（画面キャプチャ、CSV化、要件書化）
  • 移行先フォレストで、標準テンプレートを複製して新しいカスタムテンプレートを作成
  • 互換性・暗号設定・EKU/Subjectルール・発行要件を合わせる
  • 移行先のグループ（セキュリティグループ）に対してEnroll/Autoenroll権限を設定
  • 新CAでテンプレートを発行（公開）し、テスト端末で申請〜発行まで検証

移行後の最終確認：テンプレートと発行の“両方”をチェックする

最後に、移行作業が完了したかをテンプレート視点で確認するチェックリストを置いておきます。ここまで確認しておくと、翌週に「急に自動登録が止まった」「VPN用証明書が出ない」といった二次トラブルを減らせます。

チェック項目確認場所合格ライン
テンプレート定義が存在するcerttmpl.mscカスタムテンプレートが一覧にあり、プロパティが意図どおり
新CAがEnterprise CAであるAD CS構成／CAの種類テンプレートを発行できる（Standaloneではない）
新CAでテンプレートを発行（公開）しているcertsrv.msc（証明機関）「証明書テンプレート」配下に必要テンプレートが並ぶ
テンプレートの権限が正しいcerttmpl.mscのセキュリティ対象ユーザー/端末にEnroll/Autoenrollが付与されている
クライアントで申請できるMMC（証明書）/ 自動登録対象テンプレートで申請→発行まで通る

将来の移行に備える：テンプレート“設定の控え”を残すコツ

同一フォレスト移行であっても、監査や更改対応で「そのテンプレートは何を根拠にこう設定しているのか」を説明できる状態にしておくと、次の担当者が助かります。テンプレートはADにあるため、バックアップの発想としては「復元」よりも「設定の可視化・棚卸し」が効きます。

  • カスタムテンプレート一覧：名前、用途、発行対象、依存するGPO/グループを表で残す
  • 重要テンプレートの設定値：有効期間、キー長、EKU、Subject/SANルール、発行要件を控える
  • 権限設計：Enroll/Autoenrollを付けたグループと理由（運用ルール）を残す

「certutilで設定が抜けない」こと自体は異常ではなく、テンプレートがAD管理の設計だからこそ起きる現象です。保存場所と公開ポイントを分けて捉えれば、Enterprise CA移行時のテンプレート問題はほぼ整理できます。

Active Directory
Active Directory 移行 AD CS 証明書テンプレート Enterprise CA

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次