AD CSのサブCA追加・廃止ガイド：既存秘密鍵流用のリスクと正しいCA移行・置き換え手順

オフラインのルートCA配下で複数のサブCA（中間CA）を運用していると、Sub1を廃止して新しいサブCAへ切り替える場面が来ます。そこで悩むのが「Sub1の秘密鍵を流用して新サブCAを作れるか」。本記事では、鍵流用が招く問題と、移行・置き換えの正攻法、CRL/CDP/AIAを含む廃止計画を具体的に解説します。

結論：既存秘密鍵の流用は「新サブCA追加」ではなく「同一CAの移行」として扱う

最初に結論をはっきりさせます。

• 「新しいサブCA」をSub1の既存秘密鍵だけで作り直す発想は適切ではありません。秘密鍵を流用して別のCAとして再構成しようとすると、証明書チェーンの解決が不安定になり、監査・インシデント対応・運用手順も破綻しやすくなります。
• 既存鍵（Sub1の鍵）を維持したいなら、それは「新CA追加」ではなく「Sub1という同一CAの移行」です。つまり、CA証明書・秘密鍵・CAデータベース（発行/失効の管理情報）・構成情報を含めて、別サーバーへ“引っ越し”するのが筋です。
• Sub1を廃止して新しいサブCAに置き換えるなら、新サブCAは原則「新規キー」で構築します。以後の発行は新CAに切り替え、Sub1発行分は「有効期限まで生かす」前提で、検証に必要な情報（CA証明書、CRL、CDP/AIA）を継続提供します。

まず押さえる：証明書検証に必要なのは「CAサーバー」ではなく「CA証明書と失効情報」

「Sub1を止めたら、Sub1が発行した証明書は全部無効になるのでは？」という不安はよくあります。しかし、PKIの検証はサーバーの稼働そのものよりも、次の情報に依存します。

検証で必要になるもの	役割	提供が止まると起きやすいこと
Sub1のCA証明書（中間CA証明書）	「この証明書は誰が発行したか」を辿るための材料（チェーン構築）	チェーンが組めず、信頼の判定が失敗しやすい
CRL（失効リスト）/デルタCRL	失効確認（revocation checking）	ポリシーによっては失効確認ができず失敗（Hard-fail）
CDP（CRL Distribution Point）	CRLの参照先URL/パス	端末がCRLを取りに行けず、結果として検証失敗しやすい
AIA（Authority Information Access）	中間CA証明書の取得先（CA Issuers）	中間CA証明書が取得できず、チェーン構築失敗しやすい

重要なのは、「検証」は基本的に公開情報（CA証明書・CRL）で行われ、秘密鍵は検証そのものには不要という点です。秘密鍵は「発行（署名）」「CRLの署名」「（構成によっては）OCSP応答の署名」などに必要です。

CAの“同一性”は何で決まるのか：秘密鍵だけではCAにならない

「Sub1の秘密鍵があれば、Sub1を名乗れるのでは？」と考えがちですが、運用の現実ではそう単純ではありません。CAは次の要素が噛み合って初めて“同じCA”として成立します。

要素	具体例	これがズレると何が困るか
CA証明書	Sub1のCA証明書（発行者=ルートCA、拡張=CA=true、Path Lengthなど）	クライアントが参照する“発行者”が変わり、チェーン解決が不安定になる
秘密鍵	Sub1のCA秘密鍵（保護・HSM・KSP/CSPなど）	漏えい時の影響が甚大。鍵の使い回しは監査面でも説明が難しい
CAデータベース	発行済み証明書の台帳、失効情報、要求履歴など	失効運用が成立しない（「失効した/してない」を整合して管理できない）
CAの構成	CDP/AIA、CRL発行間隔、テンプレート、拡張、監査設定など	同じCAを名乗っても実体の動作が変わり、検証側の想定が崩れる
公開情報の配布経路	HTTP配布、ADへの公開、GPO配布、オフライン媒体など	参照不能＝検証失敗。「CAを止めた」よりここが致命傷になりやすい

つまり、秘密鍵だけを流用して「新しいサブCA」を立てるのは、CAの同一性を分断する行為になりがちです。これは結果として「検証の安定性」と「失効の整合性」を同時に失いやすくなります。

質問のポイントを分解して回答する

新しいサブCAをSub1の既存秘密鍵でセットアップしたらどうなるのか

現実には、想定している“セットアップ”の中身で結果が変わります。大きく3パターンに分かれます。

やりたいこと	実際に起きること	評価
Sub1の秘密鍵とCA証明書、CAデータベース、構成を丸ごと移して別サーバで稼働	同一CA（Sub1）の移行として成立しやすい。発行・失効運用を継続できる	推奨（計画的に実施）
Sub1の秘密鍵だけを持ち込み、ルートCAから“新しいCA証明書”を発行して別CAとして開始	「同じ鍵を持つ別CA」が生まれ、チェーン構築の曖昧さや監査説明の困難が増える	非推奨
Sub1の秘密鍵だけを持ち込み、CAデータベースなしでSub1のCRLや失効を運用しようとする	失効の整合性が担保できず、“いつ・何を・なぜ失効したか”の管理が破綻しやすい	非推奨

運用として成立するのは、基本的に「同一CAとして移行」だけです。「新しいサブCA追加」をしたいなら鍵を新規にします。

Sub1が発行した証明書を新しいサブCAが検証（有効化）できるのか

ここは誤解が多いポイントです。

• 検証（有効性チェック）は新サブCAの秘密鍵では行いません。検証はSub1のCA証明書（公開鍵）と、その上位（ルートCA）の信頼、そして失効情報で行われます。
• “新サブCAが有効化する”ことはできません。既に発行された証明書の発行者（Issuer）はSub1のままです。後から別のCAに“発行者を差し替える”ことはできません。
• もし新サブCAで同じ鍵を使っても、既存証明書が参照するのはSub1という発行者です。新サブCAは“別物”なので、検証の主体にはなりません。

ただし、「Sub1の秘密鍵を維持し、同一CAとして移行する」場合は話が別です。この場合はSub1のCA証明書も同じであり、発行者がSub1である事実も変わりません。つまり“新CAが検証する”のではなく、Sub1を別サーバで動かし続けるイメージです。

Sub1を削除したあともSub1発行の証明書は有効のままか

原則として、有効期限内で失効されていなければ有効です。ただし、実運用では「有効なはずなのに接続できない」事故が起こりがちです。原因は多くの場合、次のどれかです。

• CDP（CRL配布ポイント）が参照できず、失効確認に失敗する
• AIA（中間CA証明書配布）が参照できず、チェーン構築に失敗する
• 検証側ポリシー（アプリ/OS）が失効確認の失敗を許容しない（Hard-fail）

特に、社内の端末は問題なくても、境界環境・VPN越し・DMZ・モバイル・MDM配下など、CRL取得経路が分断される場所で急に障害化することがあります。「CA本体を止めた瞬間に無効」ではなく、検証が必要とする参照先が生きているかが成否を左右します。

新規キー／既存キーのどちらを選ぶべきか

判断基準を一言でまとめると次の通りです。

• サブCAを追加して置き換える（Sub1を役割終了にする）→ 新規キーで新サブCA
• Sub1というCAをそのまま存続させたい（ハード更改、OS更改、DC/ネットワーク変更への追随）→ 既存キーを含めてSub1を移行

「新しいサブCAを作りたいが、既存証明書も新CAで面倒を見たい」という中間案は、ほぼ確実に設計が難航します。代わりに、置き換えと移行を明確に分けて考えるのが安全です。

方式の選び方：置き換えか、移行か

選択肢を“人に説明できる形”で整理すると迷いが減ります。

方式	鍵	Sub1発行証明書への影響	失効運用（CRL/OCSP）	向いているケース	注意点
置き換え（新サブCA追加）	新規	既存はSub1のまま。有効期限まで継続	Sub1のCRL配布を維持する必要あり	セキュリティ更新、アルゴリズム刷新、分離強化、運用整理	CDP/AIA停止で障害化。移行期間の設計が重要
移行（同一CAの引っ越し）	既存を保持	影響最小。発行者は変わらない	失効/発行を従来通り継続しやすい	ハード更改、OS更改、証明書の互換性を変えたくない	CAデータベースと構成まで含めて移す必要がある
秘密鍵だけ流用して別CA化	既存を使い回し	チェーン構築が曖昧になりやすい	整合性が崩れやすい	（基本的に推奨しない）	監査・運用・トラブル対応が非常に難しい

置き換えの正攻法：新サブCAを新規キーで作り、発行を切り替える

「Sub1を廃止して新しいサブCAに置き換える」なら、このパターンが王道です。ポイントは、Sub1発行分の検証に必要な情報を残したまま、新しい発行を新CAへ移すことです。

設計段階で決めるべきこと

後戻りしにくい項目から先に固めます。

• 新サブCAの役割（サーバー証明書専用、ユーザー証明書も扱う、コード署名は分ける、など）
• 鍵・アルゴリズム（RSA/ECDSA、鍵長、ハッシュ、鍵保護方式、HSMの有無）
• 有効期間（CA証明書の有効期間、発行する証明書の最大期間、更新サイクル）
• 公開情報の配布（CDP/AIAのURL設計、AD公開、HTTP配布サーバー、外部端末の到達性）
• 失効確認の方針（CRLのみ、OCSP併用、デルタCRL運用の継続可否）

特にCDP/AIAは、切り替え時の障害に直結します。新CA用に新しいCDP/AIAを作るだけでなく、Sub1のCDP/AIAを“いつまで”生かすかを同じレベルで設計に入れてください。

発行切り替えの進め方（実務で事故が少ない流れ）

1. 現状棚卸し：Sub1で発行している証明書の用途、テンプレート、最大有効期間、利用システム（IIS、NPS、VPN、RDP、Wi-Fi、S/MIME、デバイス証明書など）を一覧化します。
2. 新サブCAの構築：オフラインルートCAで新サブCA証明書を発行し、新CAのCDP/AIAを正しく公開します。
3. 信頼配布の整備：ドメイン環境ならGPO/ADで新サブCA証明書を配布し、非ドメイン端末・機器にも配布計画を作ります。
4. テンプレート/発行元の切り替え：新CAで発行可能なテンプレートを公開し、必要に応じて自動登録（Autoenrollment）も新CAへ寄せます。
5. 段階的な再発行：有効期限が近いもの、影響の大きいものから新CAで再発行・入替を進めます。
6. Sub1は“停止”ではなく“縮退”：新規発行を止めても、CRL配布やAIA/CDPの提供は継続します（ここを切ると事故が起きます）。

「Sub1を廃止」する前に必ず決める：Sub1発行分のCRLをどう生かすか

Sub1の役割を終えるとき、最も重要なのはCRLの継続提供です。運用上の現実解としては次のような方針が取りやすいです。

方針	メリット	デメリット/注意点	向いているケース
Sub1を稼働させたまま、発行だけ停止してCRL発行を続ける	最も確実。失効運用が維持できる	サーバ維持コスト。セキュリティパッチや監視が必要	Sub1発行証明書の残存期間が長い
Sub1は停止し、最終CRLを長期間有効にして配布だけ残す	サーバを撤去できる	最終CRLの有効期限設計を誤ると検証失敗。ポリシー次第でリスク	失効がほぼ発生しない用途/残存期間が短い
CDP/AIAをWeb配布に寄せ、CA本体は隔離して必要時のみCRL更新	攻撃面を小さくしつつ、CRL更新の余地を残せる	手順が複雑。運用手順書と引継ぎが必須	セキュリティ要件が厳しいが、失効運用は捨てられない

「最終CRLを長期間有効にして配る」方式は魅力的に見えますが、失効という安全装置を弱める側面があります。証明書の用途（VPN、スマートカード、端末認証、コード署名など）によっては、失効運用を軽視できません。監査要件やセキュリティポリシーも踏まえて選んでください。

移行の正攻法：Sub1を“同一CA”として別サーバへ引っ越す

「鍵を変えたくない」「Sub1発行分の失効を今後も正しく運用したい」「クライアント影響を最小化したい」なら、Sub1の移行（マイグレーション）を選びます。ここで重要なのは、秘密鍵だけではなく、CAデータベースと構成も含めて移すことです。

移行で“同一CA”を保つために守るべき前提

• Sub1のCA証明書と秘密鍵は同一のものを継続利用（新しく作らない）
• CAデータベースを引き継ぐ（発行・失効の台帳を維持）
• CDP/AIAの参照先が変わるなら、リダイレクト/継続公開を設計に入れる
• 監査ログや運用記録の引継ぎ方針も決める（インシデント時の追跡に効く）

移行作業そのものは環境や要件で差がありますが、方向性としては「バックアップ→新サーバ構築→復元→発行/CRL公開の動作確認」という流れです。Windows系のCA（AD CS）の場合、CAのバックアップ/復元機能や証明機関の移行手順に沿って進めるのが王道です。

移行時に持っていくべきもの（抜けやすい要素）

項目	目的	抜けると困ること
CA秘密鍵	新規発行やCRL署名の継続	CRL更新不可、発行不可
CA証明書	同一CAとしての継続	別CA扱いになり、既存証明書運用が崩れる
CAデータベース	発行・失効の整合性維持	失効管理が成立しない
CA構成（CDP/AIA、CRL間隔、テンプレート設定、拡張、監査）	動作の再現性	同一CAを名乗っても挙動が変わり、トラブルが増える
公開配布の仕組み（HTTP配布サーバ、AD公開、GPOなど）	クライアントの参照継続	検証失敗の多発

運用担当者がハマりやすい「移行の罠」

• CAサーバのホスト名/FQDNを変えてしまい、CDP/AIAが死ぬ：証明書に埋め込まれた参照先は変えられません。ホスト名変更をするなら、DNS/HTTPリダイレクトや同一パス提供など、参照先の“見た目”を維持する設計が必要です。
• CRLの公開場所だけ先に整理してしまい、端末が古いCDPへ取りに行く：過去に発行した証明書ほど古いCDP/AIAを参照します。切り替え順序を間違えると、古い証明書ほど壊れます。
• デルタCRLを使っているのに、ベースCRL/デルタCRLの関係を崩す：デルタCRL運用は便利ですが、停止・移行時は整合性が崩れやすい領域です。運用を継続するか、ベースCRLのみへ寄せるかを計画的に決めます。

「秘密鍵を使い回して別CAを作る」が危険な理由をもう少し具体的に

ここまでで「非推奨」と言い切りましたが、現場の説得材料になるよう、何が起きるのかを具体化します。

同じ鍵＝同じCA？にならない（チェーン構築は“鍵だけ”で決まらない）

証明書検証は、証明書のIssuer（発行者名）やAuthority Key Identifier（AKI）、クライアントが持つ中間CA証明書のSubjectやSubject Key Identifier（SKI）など、複数要素の組み合わせで「どのCA証明書が発行者か」を解決します。

• 新CAを作ると、CA証明書の有効期間、シリアル番号、拡張などが変わります。
• 同じ公開鍵（＝同じ秘密鍵）を使ったとしても、クライアント側のチェーン構築が“どちらのCA証明書を選ぶか”で揺れる状況を生みます。
• この揺れは、OSやミドルウェア、証明書ストアの状態、キャッシュ、AIA取得可否で結果が変わりやすく、再現性の低い障害になりがちです。

失効運用は“発行者単位”で完結する：別CAはSub1発行分を責任持てない

失効は「発行者（Issuer）が、そのIssuerとして失効を宣言する」仕組みです。別CAがSub1発行の証明書を失効させることはできません。

• Sub1発行分の失効情報は、Sub1のCRL（またはSub1に紐づくOCSP）で提供されます。
• 新サブCAを作っても、そのCRLは“新CAが発行した証明書”にしか責任を持てません。
• 結果として「Sub1発行分は失効できない（あるいは失効の整合性が取れない）」という状態に陥りやすくなります。

監査・セキュリティ面の説明が破綻しやすい

秘密鍵は最重要資産です。鍵を流用して“別CA”を作ると、次の問いに明確に答えにくくなります。

• その鍵はいつ生成され、どのCAで使われ、どの期間に何を署名したのか
• 鍵が漏えいした場合、影響範囲はどこまでか（Sub1だけか、新CAもか）
• 鍵のライフサイクル管理（更新・廃棄・ローテーション）の設計はどうなっているか

セキュリティの観点では、「置き換え＝新規キー」を原則にする方が説明可能性が高いことが多いです。

Sub1廃止計画で最重要：CDP/AIAを“止めない設計”にする

Sub1のサーバーを撤去した瞬間にトラブルが起きるケースの多くは、CDP/AIAの参照先が消えることが引き金です。廃止は「CAサービスを止める作業」ではなく、公開情報の提供をどう継続するかを中心に設計してください。

CDP/AIA維持の実務ポイント

• 過去に発行した証明書のCDP/AIAは書き換えできない：証明書に埋め込まれたURL/パスは固定です。提供側（Webサーバやファイル共有、LDAP/AD公開）を生かす発想が必要です。
• HTTP配布は“長期運用の置き場所”として強い：CA本体を残さずにCDP/AIAだけ残す場合、HTTPで配る設計は比較的維持しやすいです（ただしアクセス制御や改ざん対策は必須）。
• 外部端末/閉域端末の到達性：VPN前提の端末や、製造現場の閉域ネットワーク端末など、CRL取得経路が一様ではない環境ほど「どこから取るか」を先に検証します。

廃止前チェックリスト（この表を埋めると失敗が激減する）

チェック項目	確認ポイント	OKの目安	NGだと起きること
Sub1発行証明書の残存期間	最も長く残る証明書の有効期限	いつまでSub1のCRL/CDP/AIAが必要か確定	早期撤去で障害が長期化
CDP/AIAの参照先	HTTP/LDAP/ファイル共有などの実体	廃止後も到達可能な場所に置く	チェーン/失効確認が失敗
CRLの有効期間と更新方法	次回更新（NextUpdate）	廃止期間をカバーできる設計	期限切れでHard-fail
デルタCRL運用	デルタCRLを使っているか	継続 or 停止の方針が決まっている	失効確認の整合性が崩れる
OCSPの有無	オンラインレスポンダの利用状況	CRL配布と整合する設計	OCSPだけ残しても元が死ぬ
信頼配布（端末・機器）	ドメイン外端末、NW機器、SaaS連携	Sub1/新CAの証明書配布計画がある	一部だけ繋がらない事故が多発

“新サブCAがSub1発行分を面倒見る”という発想を、運用に落とすならこう考える

現場では「Sub1を廃止するけど、Sub1発行の証明書は有効でいてほしい」という要件が普通に出ます。この要件は、次のように読み替えると設計が進みます。

よくある要件の言い方	PKI的に正しい翻訳	実現のために必要なこと
Sub1を消しても証明書は有効にしたい	Sub1発行証明書の検証に必要な情報を消さない	Sub1 CA証明書とCRL（CDP/AIA）を継続提供
新CAに切り替えたい	新規発行の発行者を変えたい	新CAを新規キーで構築し、テンプレート/自動登録を切替
Sub1発行分も失効できる状態を維持したい	Sub1の失効運用を継続したい	Sub1を同一CAとして移行するか、Sub1を縮退運用で残す

この翻訳ができると、「秘密鍵を流用して新CAにする」という危険な近道に頼らず、置き換え・移行・縮退という正しい選択肢に落とし込めます。

判断を早くするための実践的な決め方

最後に、迷ったときの決め方を“現場の質問”に寄せてまとめます。

• 「Sub1発行の証明書を、今後も失効できる必要がある」 → Sub1を同一CAとして移行するか、Sub1を縮退運用で残す（CRL発行を継続）。
• 「セキュリティ上、鍵を刷新したい／アルゴリズムを変えたい」 → 新サブCAを新規キーで構築し、発行を切り替える（Sub1は公開情報だけ維持）。
• 「Sub1のサーバを撤去したいが、CDP/AIAを維持できるインフラがない」 → まず配布基盤（HTTP配布、DNS、証明書配布）を整備。基盤なしの廃止は高確率で障害化します。
• 「今ある仕組みを変えたくない。停止時間を最小にしたい」 → 同一CAとしての移行が向く（ただし計画的なリハーサルとバックアップが必須）。

まとめ：既存鍵を使うなら移行、置き換えるなら新規鍵が基本

• Sub1の秘密鍵を流用して“新しいサブCA”を追加する考え方は、運用・監査・検証の観点で危険です。
• 既存鍵を維持したいなら「新CA追加」ではなく「Sub1の移行」として、CAデータベースと構成まで含めて引き継ぎます。
• Sub1を置き換えるなら、新しいサブCAは新規キーで構築し、新規発行を切り替えます。
• Sub1発行の証明書を有効に保つ鍵は、Sub1のCA証明書とCRL（CDP/AIA）の継続提供です。CA本体の停止よりも、参照先の継続が成否を分けます。