Active Directory 環境の AD CS では、発行 CA（エンタープライズ下位 CA）が止まると新規発行や更新ができず、認証基盤が単一障害点になります。本記事では、ルート CA をスタンドアロンのまま維持しつつ、発行 CA を2台で冗長化する設計（クラスタ／並列）と、クライアントがどの CA を使うのかを具体的に解説します。
前提整理：AD CS の「ルート CA」と「発行 CA」で止まったときの影響は違う
AD CS（Active Directory Certificate Services）をドメイン環境で運用する場合、よくあるベストプラクティスは「スタンドアロンのルート CA（オフライン）」＋「エンタープライズ下位 CA（オンラインで発行）」という二層構成です。ここで冗長化の議論をする前に、停止時の影響範囲を切り分けておくと設計がブレません。
- ルート CA（スタンドアロン）：普段はオフライン。止まっていても通常運用に影響は小さい（ただし、下位 CA の新規発行・更新、失効リスト更新、CRL 署名など、特定の作業ではオンライン化が必要）。
- 発行 CA（エンタープライズ下位 CA）：日々の「新規発行」「更新」「（アプリ次第で）失効確認」が集中する。ここが止まると証明書ライフサイクルが止まりやすい。
さらに重要なのは、「CA が止まる＝証明書が即使えなくなる」ではない点です。多くのケースでは、既存証明書は有効期限内なら継続利用できます。一方で、アプリや認証方式によっては CRL/OCSP の参照要件が厳しく、失効情報の配布点（CDP）や OCSP 応答が落ちると認証が失敗することもあります。発行 CA の冗長化を考えるなら、同時にCRL/OCSP の可用性も必ずセットで設計します。
まず押さえる：クライアント証明書は「配布」ではなく「登録（Enrollment）」で入る
質問でよく混ざるのが「証明書をどう配布するのか」という観点です。AD CS の一般的な運用では、証明書は CA 側から“配る”というより、クライアント（ユーザー/端末/サーバー）が登録（Enrollment）要求を行い、発行された証明書がクライアントの証明書ストアに保存されます。
ドメイン参加端末の典型パターン
- 自動登録（Autoenrollment）：GPO の自動登録設定＋証明書テンプレートにより、ユーザー/コンピューターが自動で要求・更新する。
- 手動登録：MMC（証明書スナップイン）や Web Enrollment（古い方式）などで手動申請する。
- サーバー証明書：IIS などから CSR を作ってテンプレート発行、または CA へ要求。
配布（信頼）側の話も重要
証明書そのものは登録で入りますが、証明書チェーンの信頼（ルート CA 証明書や中間 CA 証明書の信頼）は別問題です。ドメイン参加端末であれば、ルート CA 証明書や下位 CA 証明書は Active Directory に公開し、クライアントが自動的に取得・信頼する設計にできます（必要に応じて GPO で「信頼されたルート証明機関」へ配布することもあります）。
質問の論点を、設計パターンごとに“最短で答える”
まずは、いただいた疑問を「クラスタ（同一 CA として冗長化）」と「並列（別 CA を2台）」でどう変わるかを、結論ベースで整理します。
| 疑問 | クラスタ（Active/Passive） | 並列（別 CA を2台） |
|---|---|---|
| クライアント証明書はどう配布／発行される？ | クライアントは「クラスタ名（仮想名）」の CA に登録要求し、アクティブノードが発行する。 | クライアントは AD 上の「利用可能な CA」の候補から選び、応答した CA が発行する（制御しないと予測が難しい）。 |
| クライアントはどちらの CA を選ぶ？ | 原則 1 つに見える（クラスタ名）。裏側でアクティブが処理。 | テンプレートを発行可能な CA が複数あると、クライアント実装・タイミングで選ばれる（運用での制御が鍵）。 |
| CA1 の証明書を CA1 障害時に別 CA が更新できる？ | 可能（同じ CA として継続。DB/秘密鍵を引き継ぐ）。 | 「同じ発行者としての更新」は不可。CA2 が“新規に”発行することは可能だが発行者が変わる。 |
| 2台の CA の CA 名（共通名）は同一？別？ | 同一（同一 CA の冗長化）。 | 別が原則。同一名は運用・管理上の衝突や混乱を招き、現実的ではない。 |
| フェイルオーバー構成が可能？ | 可能。Windows フェイルオーバークラスタで Active/Passive が王道。 | “CA を切り替える”意味のフェイルオーバーは別物。発行を分散する構成で、制御設計が必要。 |
冗長化の考え方は大きく2つ：クラスタか、並列か
パターンA：発行 CA をフェイルオーバークラスタ化する（Active/Passive）
「片系が落ちても同じ CA として継続運用したい」「既存運用を極力変えずに可用性を上げたい」場合は、発行 CA をクラスタ化（Active/Passive）するのが最も分かりやすい選択肢です。
構成イメージ
| 要素 | 内容 | ポイント |
|---|---|---|
| ノード | CA ノード2台（例：ISSUECA01/ISSUECA02） | 同じ役割を持つが、同時稼働は基本しない（Active/Passive）。 |
| アクセス名 | クラスタ名（例：ISSUECA-CL） | クライアントからはこの名前が “CA” に見える。 |
| CA の秘密鍵 | 同一の CA 鍵を両ノードで利用可能にする | これが “同じ CA” を維持するコア。HSM/キーの移行・保護設計が重要。 |
| CA データベース | 共有ストレージ（または設計に応じた共有手段） | 発行履歴・失効情報・保留要求など、状態を引き継ぐために必要。 |
| CRL/AIA 配布点 | IIS/ファイル共有/AD 公開など | CA 冗長化とは別に、参照先の冗長化が必須になりやすい。 |
なぜクラスタが“フェイルオーバーの王道”なのか
- 同一の CA として振る舞える：発行者（Issuer）が変わらないため、アプリ側の想定が崩れにくい。
- 更新・失効・保留要求の状態を引き継げる：CA データベースが共有されるため、CA1 が処理していた“途中状態”を CA2 が引き継げる余地がある。
- クライアント側の「どっちの CA を選ぶ？」問題が消える：見える CA は 1 つ（クラスタ名）だから運用が単純。
クライアントはどちらの CA を選ぶのか（クラスタの場合）
クラスタ構成では、クライアントが意識するのは基本的にクラスタの仮想名（CA のアクセス名）です。アクティブ側のノードで AD CS サービスが稼働していれば、通常通り登録要求が処理されます。障害時にフェイルオーバーすると、同じ仮想名が待機系ノードに移り、クライアントから見た “CA の見え方” は変わりません。
CA1 障害時に更新できるか（クラスタの場合）
更新は「古い証明書を編集する」行為ではなく、新しい証明書を発行する行為です。ただし、ここで重要なのは同じ CA（同じ秘密鍵・同じ CA 証明書）で発行し続けられるかどうかです。クラスタなら “同じ CA” の状態を継続できるため、CA1 障害時でも待機系が同じ CA として更新（= 新しい証明書の発行）を行えます。
クラスタ構成での CA 名（共通名）の考え方
クラスタは「2台で1つの CA」を実現します。そのため、CA 名は同一です。ここでいう “同一” は見た目の共通名だけでなく、CA 証明書（サブジェクト、拇印、鍵）が同一であることを意味します。アプリケーションが発行者情報やチェーン検証で期待しているのは、この“同一性”です。
クラスタ設計で見落としがちなポイント
発行 CA をクラスタ化しても、次の設計が弱いと「CA は生きているのに認証が落ちる」事故が起きます。
- CRL 配布点（CDP）が単一：CA が落ちていなくても、CRL の参照先が落ちると失効確認で失敗することがある。
- OCSP（Online Responder）を導入しているのに冗長化していない：OCSP を必須にしている環境では、OCSP の可用性がボトルネックになる。
- テンプレートの権限設計が雑：自動登録は権限が全て。意図しないユーザー/端末が証明書を取得できるとセキュリティ事故につながる。
- バックアップ設計が“クラスタだから不要”になっている：可用性と復旧性は別。クラスタでも CA のバックアップは必須。
クラスタ導入時の実務チェックリスト
環境差が大きい領域なので、手順を丸暗記するより「抜けやすい観点」をチェックリスト化して進める方が失敗しにくいです。
| 観点 | 確認内容 | ありがちな落とし穴 |
|---|---|---|
| 名前解決 | クラスタ名の DNS 登録、SPN、到達性 | クライアントが別名で CA に到達し、後で切替時に混乱する |
| 秘密鍵 | 鍵の保護・エクスポート可否・HSM 利用方針 | 待機系に鍵を展開できず、フェイルオーバーしても署名できない |
| CA DB | DB/ログの配置、共有方式、I/O、バックアップ | 共有の前提が崩れると “同一 CA” を維持できない |
| CRL/AIA | CDP/AIA URL の可用性、公開先の冗長化 | CA は復旧したのに CRL が取れず認証失敗が続く |
| 運用 | パッチ適用、切替訓練、監査ログ、証明書更新計画 | 一度も切替試験しておらず、障害時に手順が崩壊する |
動作確認に使えるコマンド例（代表）
環境により出力は異なりますが、定期点検の“型”として持っておくと便利です。
certutil -ping
certutil -config - -ping
certutil -getreg CA\CRLPublicationURLs
certutil -getreg CA\CACertPublicationURLsまた、クライアント側では「どの CA が候補として見えているか」「自動登録が期待通りか」を確認します。
certutil -pulse
gpupdate /forceパターンB：発行 CA を2台並列に置く（別 CA を2つ運用する）
もう一つの考え方は、発行 CA を「別 CA」として2台運用する方法です。これは厳密には “同一 CA のフェイルオーバー” ではなく、発行先を複数用意して分散する設計です。うまくハマれば柔軟性は高いですが、意図せず証明書が分散し、後から運用が難しくなることも多いです。
並列配置のイメージ
- CA1 と CA2 はそれぞれ別の CA 証明書（別の秘密鍵）を持つ
- テンプレート運用によって、どの CA が何を発行するかを決める
- 同じテンプレートを両方の CA で有効にすると、クライアントは“どちらでも良い”状態になり、結果が読みにくくなる
クライアントはどちらの CA を選ぶのか（並列の場合）
ドメイン環境の証明書登録では、クライアントは Active Directory 上の「発行可能な CA（Enrollment Services）」を参照し、そのテンプレートを発行できる CAを候補として扱います。候補が複数ある場合、選択は“常に同じ”とは限りません。
- ネットワーク遅延や一時的な負荷で、先に応答した CA が発行するように見えることがある
- クライアントや実行タイミングにより、発行 CA が偏ったり分散したりする
- 「OU ごとに CA を分けたい」「用途ごとに CA を分けたい」のに、分け方が曖昧だと運用が破綻しやすい
そのため、並列配置をやるなら、“クライアントに見せる候補” と “テンプレートの発行権限” を設計で縛るのが前提になります。
どの CA に発行させるかを制御する実務的な方法
「Enrollment Policy Service（登録ポリシー サービス）」という言葉が出てくるのは、まさにこの制御のためです。ただし、現場ではそれ以前に、テンプレート運用で整理できることが多いです。よく使う手段を優先度順に並べます。
| 制御手段 | 狙い | 具体例 | メリット | 注意点 |
|---|---|---|---|---|
| テンプレートを CA ごとに分ける | 発行先を固定 | 「UserAuth-CA1」「UserAuth-CA2」などテンプレートを分離 | 挙動が読みやすい | テンプレートが増える。更新ポリシーも二重管理になりがち |
| テンプレートの発行を片方の CA にだけ許可 | 候補を1つにする | 同一テンプレートでも CA2 では発行しない（発行 CA 側の設定） | 最小変更で制御できる | “冗長化”というより“片系運用”になる。切替は運用手順が必要 |
| テンプレートのセキュリティ（Enroll/Autoenroll 権限）をグループで分離 | 対象端末/ユーザーを分ける | CA1 用グループ、CA2 用グループを作り OU と連動 | AD 運用と相性が良い | 権限付与ミスが事故につながるのでレビュー必須 |
| 登録ポリシー（CEP/CES）で提示 CA/テンプレートを制御 | “見える候補”を制御 | 特定の端末に「この CA/テンプレートだけ」を提示 | 柔軟。境界ネットワークや非ドメイン向けにも応用可 | 構成が複雑化しやすい。運用が強くないと破綻しやすい |
ポイントは、「同じテンプレートが両方で発行可能」な状態を、意図がないのに作らないことです。並列配置は、設計の曖昧さがそのまま運用事故になります。
CA1 が発行した証明書を、CA1 障害時に CA2 が更新できるか（並列の場合）
ここは誤解が多いので、言い切ります。
- “同じ発行者（Issuer）として更新する”ことはできません。CA2 は CA1 の秘密鍵を持っていないため、CA1 と同じ発行者として署名できません。
- ただし、更新に見える形でCA2 が新しい証明書を発行することは可能です（テンプレートや自動登録が CA2 を許可していれば）。この場合、証明書の発行者は CA2 になります。
この違いがアプリに与える影響は大きいです。例えば、次のような構成だと切替時に問題が出ます。
- 発行者を固定でチェックしている（「この CA の証明書だけ許可」など）
- 証明書拇印（Thumbprint）をピン留めしている（サーバー証明書切替時に起きがち）
- スマートカード/ユーザー証明書のマッピングで発行 CA を前提にしている
つまり、並列配置は「CA 障害時に自動で同等運用を継続」というより、“別 CA に移行しても問題ない設計” を前提にするか、または移行手順（どのアプリを、どう切り替えるか）まで含めて運用設計する必要があります。
2台の CA 名（共通名）を同一にすべきか別にすべきか
結論として、並列配置（別 CA）では別名が原則です。理由は次の通りです。
- CA は“名前”よりも“鍵と証明書”がアイデンティティであり、見た目の共通名を揃えても同一 CA にはならない。
- Active Directory 上の登録情報や管理運用（失効、監査、発行履歴）で混乱が起きやすい。
- トラブル時に「どっちの CA が発行した証明書か」を追跡しにくくなる（監査・インシデント対応が重くなる）。
“同じ CA として冗長化したい”のであれば、並列配置で名前を寄せるのではなく、クラスタ（または DR の復元方式）を検討する方が安全です。
フェイルオーバーを本当に実現したいなら「同一 CA を維持できるか」が境界線
冗長化という言葉の中には、少なくとも次の2種類が混ざっています。
- 高可用性（HA）：障害時も “同じもの” として継続（同一 CA を維持）。
- 負荷分散/分業：複数の CA を並べて運用し、用途や負荷を分散。
発行 CA に求めるのが “HA” なのか “分散” なのかで、設計の正解は変わります。判断を早くするための目安を表にします。
| 要件 | おすすめ | 理由 |
|---|---|---|
| CA 障害時も発行者を変えずに更新・発行を継続したい | クラスタ（Active/Passive） | 同一 CA（鍵・DB）を維持できるのはこの系統 |
| 用途別に CA を分けて監査・権限・ポリシーを分離したい | 並列（別 CA） | スマートカード用、TLS 用などで責務分離がしやすい |
| 証明書発行負荷が高く、スループットを上げたい | 並列（別 CA）または用途分割 | クラスタは基本 Active/Passive のため性能面の伸びは限定的 |
| 運用体制が小さく、仕組みを単純にしたい | クラスタ（または単一 CA＋運用で復旧） | 並列はテンプレート/権限の設計負荷が上がる |
“2台にしたのに落ちる”を防ぐ：CRL/OCSP と公開先の冗長化が最重要
発行 CA をクラスタ化しても、並列にしても、現場で一番多い障害は「CA そのもの」より「失効情報の参照先」です。特に以下の条件が重なると、認証障害が顕在化しやすいです。
- ドメインログオン、VPN、Wi-Fi 802.1X、スマートカードなど、失効確認が厳格な認証方式を使っている
- アプリやミドルウェアが CRL/OCSP を必須にしている（“取得できないなら拒否”）
- CDP/AIA URL が単一サーバーの IIS やファイル共有に依存している
最低限やっておきたい対策
- CDP/AIA の公開先を冗長化：IIS を冗長化する、ロードバランサ配下に置く、または可用性の高い共有基盤に置く。
- CRL の有効期間とオーバーラップ：短すぎる CRL は更新ミスが障害に直結する。運用体制に合わせた期間設計が必要。
- OCSP を使うなら OCSP も冗長化：Online Responder を単一で置くと、CA より先に OCSP が単一障害点になる。
“CA を2台にする”ことより、“検証に必要なエンドポイントを止めない”ことの方が、ユーザー体感の可用性に直結します。
現実的な落としどころ：完全自動フェイルオーバー以外の選択肢
「クラスタはコストや構成難易度が高い」「でも単一 CA のままは怖い」という場合、次のような落としどころもあります。
コールドスタンバイ（DR）として2台目に復元できるようにする
2台目に AD CS を常時稼働させず、障害時に CA のバックアップ（CA 証明書・秘密鍵・データベース）から復元して切り替える方法です。これは“自動”ではありませんが、同一 CA を復元して継続できる可能性があります。
- メリット：クラスタほど複雑になりにくい／コストが抑えやすい
- デメリット：切替は手動／RTO が運用手順とスキルに依存
「絶対に止められない」ほどではないが、「止まってから復旧手順を考えるのは避けたい」環境では有効です。
用途分割で“止まる範囲”を小さくする
並列配置を “冗長化” ではなく “分割” と割り切り、例えば次のように分けると、障害の影響を局所化できます。
- CA（ユーザー証明書／スマートカード用）
- CA（サーバー TLS 用）
- CA（デバイス管理／SCEP/NDES 用）
この場合は、用途ごとにテンプレートと権限を分けやすく、監査上も整理しやすい一方、設計の粒度が上がるので「どこまで分けるか」を最初に決めるのがコツです。
よくある設計例
例1：オフライン ルート CA＋発行 CA をクラスタ化（内部向けの王道）
- ルート CA：スタンドアロン（オフライン）
- 発行 CA：エンタープライズ下位 CA を Active/Passive クラスタ
- CDP/AIA：IIS を冗長化、または高可用な共有基盤へ公開
- OCSP：必要なら Online Responder を複数台（冗長）
発行者を変えずに継続したい場合に最も筋が良い構成です。アプリ側の変更点も最小になりやすいです。
例2：発行 CA を2台（別 CA）で用途分割し、テンプレートで制御
- 発行 CA1：ユーザー認証系（スマートカード、VPN、Wi-Fi 802.1X など）
- 発行 CA2：サーバー証明書系（IIS、内部 API、プロキシ、デバイス証明書 など）
- テンプレート：用途ごとに分離し、Enroll/Autoenroll 権限をグループで管理
“片方が落ちても同じ証明書を継続”というより、“片方が落ちても全社が同時に止まらない”方向の設計です。組織の規模が大きく、証明書用途が多いほど効いてきます。
運用のコツ：冗長化は「切替試験」と「更新計画」が本番
AD CS の冗長化は、構築した瞬間がゴールではありません。むしろ本番で差が出るのは、次の2点です。
- 切替試験（フェイルオーバー訓練）：年に1回でも良いので、意図的に切替し、発行・更新・失効確認・主要アプリの影響を確認する。
- 更新計画（証明書の有効期間と更新タイミング）：更新が集中する時期を避ける、有効期間・自動更新のしきい値を設計し、監視する。
特に「更新ができない」事象は、発生した瞬間には見えにくく、数週間〜数か月後に “大量期限切れ” として爆発します。冗長化と同じくらい、更新が正常に回っていることを監視する運用が重要です。
まとめ：2台にする目的を言語化すれば、設計は自然に決まる
- 同じ CA として止めたくないなら、発行 CA のクラスタ（Active/Passive）が最も素直。
- 2台を並べる方式は “フェイルオーバー” というより分散・分業。テンプレートと権限で制御しないと挙動が読めなくなる。
- 「CA を2台」にしても、CRL/OCSP の参照先が単一だと認証障害は防げない。公開点の冗長化はセットで設計する。
- 最終的な成否は、構築よりも切替試験と更新監視で決まる。
コメント