Windows Server 2019 Server CoreのAD CSサブCAが起動しない原因と対処法（0x2/0x80070002・ポリシーモジュール未登録）

Windows Server 2019 Server Core で AD CS のサブ CA を構築したのに、CertSvc が「The system cannot find the file specified (0x2/0x80070002)」「ポリシーモジュールが無い・未登録」で起動しない…。このタイプの失敗は、実体の欠落より“サービスが必要な鍵やファイルを読めない”権限問題が原因になりがちです。

症状と前提を整理する

本記事で扱うのは、Windows Server 2019（Server Core）にAD CS（Active Directory Certificate Services）の「サブ CA（Subordinate CA）」を構築し、オフラインのルート CA で署名したサブ CA 証明書を受領・インストール済みであるにもかかわらず、Certification Authority（certsrv.msc）から CA サービス（CertSvc）を起動できないケースです。

代表的な表示・ログは次のようなものです。

画面/ログに出る文言	よく見えるエラーコード	実際に困っていること
The system cannot find the file specified.	0x2 / 0x80070002	CertSvc が起動できず、発行/CRL/申請処理が止まる
CA のポリシーモジュールが見つからない、または正しく登録されていない	（表示上はモジュール名）	「標準ポリシーのはずなのに…」と行き詰まる
The handle is invalid	0x6 / 0x80070006 など	鍵やDBを開けず内部初期化に失敗している可能性

さらに厄介なのが、証明書ストアや CertSrv 配下に CA 証明書が存在し、certutil -urlfetch -verify でも検証が成功するなど、「証明書が無いわけではない」状況でも起きる点です。特にHSMを使っている環境では、管理者の手元で「鍵にアクセスできる」ことと、サービス（CertSvc）が非対話で鍵を使えることが別物になりやすく、ここが盲点になります。

「ファイルが見つからない」＝ファイルが無い、とは限らない

0x2（ERROR_FILE_NOT_FOUND）や 0x80070002 は、文言だけ見ると「何かのファイルが欠落している」ように見えます。しかし AD CS の起動時は、証明書・秘密鍵・データベース・ログ・レジストリ設定・モジュールの読み込みなど複数の要素を連鎖的に初期化します。

このとき、実体は存在しても次のような状態だと「見つからない／無い」として扱われることがあります。

• サービス実行アカウントに権限がなく、ファイルやキーコンテナを開けない
• HSM のキー利用が「対話ログオン前提」になっており、サービスがPIN/ログイン状態を引き継げない
• DB/ログの保存先パスが存在しない（移設後にフォルダ未作成、ドライブレター変更、アクセス不可なUNCなど）
• 必要なプロバイダー（KSP/CSP）が読み込めない（未インストール、サービスから見える場所にない、依存サービス未起動）

つまり、エラーメッセージに引っ張られて「ファイルを探す」より、CertSvc が“読める状態”になっているかを確認するほうが復旧が早い、というのが本件のコツです。

最短で原因に近づく切り分け手順

Server Core では GUI での深掘りが難しいため、コマンドで事実を積み上げるのが安全です。以下は、現場での切り分けで効果が高い順に並べた流れです。

優先度	確認対象	狙い	代表コマンド例（Server Core向け）
高	CertSvc の実行アカウント	「誰の権限で失敗しているか」を確定する	sc qc certsvc
高	秘密鍵へのアクセス可否（サービス視点）	HSM/鍵権限の問題かを一撃で判定	schtasks で SYSTEM 実行→certutil -store -v
中	DB/ログのパスとACL	0x2/0x80070002 の“本命”を潰す	certutil -getreg CA\DBDirectory / CA\LogDirectory
中	ポリシーモジュール/出口モジュール設定	「未登録」表示が設定起因かを確認	certutil -getreg CA\PolicyModules\Active
低	表示言語/言語パック	環境依存の不具合要素を潰す	dism /online /get-intl

CertSvc の実行アカウントを確認する

まずは「CertSvc が誰として動くか」を固定します。これが分からないまま権限付与を始めると、的外れになりがちです。

sc qc certsvc

出力の SERVICE_START_NAME がポイントです。多くの環境では LocalSystem（NT AUTHORITY\SYSTEM）で動いていますが、運用設計やHSM要件でドメインアカウントに変更していることもあります。

エラーコードを人間が読める形にする

0x80070002 のような HRESULT は、原因の見当を付けるのに有効です。サーバー上で次を実行すると、意味が分かりやすくなります。

certutil -error 0x80070002
net helpmsg 2

「File not found」と出ても、上で触れた通り権限不足や“見えない”状態が混ざるため、次のセクションの確認に進みます。

原因の本命：CertSvc が秘密鍵を使えない（HSMで特に多い）

結論から言うと、本件のような「ファイルが無い／モジュールが無い」系の起動失敗は、秘密鍵へのアクセス権限（または非対話利用の成立）が原因であるケースが非常に多いです。特に HSM を使っていると、次の構図が起きやすくなります。

• 管理者でログオンしている間は、HSM セッションが開いていて鍵が使える
• しかし CertSvc は別のセッション/別のアカウントで起動するため、HSM 側で「未ログイン扱い」になり鍵が使えない
• 結果として、CertSvc は CA 証明書に紐づく秘密鍵を開けず、起動処理が途中で落ちる

この状態だと、画面上は「ポリシーモジュールが…」など別のエラーが出ることがあります。最初に失敗した処理が鍵のオープンでも、管理ツール側の表示は最後に見えたエラーへ寄ってしまうためです。

チェック：サービス視点（SYSTEM等）で秘密鍵を開けるか

ポイントは「自分（管理者）で開けるか」ではなく、CertSvc の実行アカウントで開けるかです。Server Core では次のような方法が現実的です。

方法A：SYSTEMでコマンドを実行して出力を確認する（標準機能だけで可能）

一時フォルダを作り、SYSTEMで certutil を走らせて結果をファイルに出します。

mkdir C:\Temp

schtasks /Create /TN "ADCS-KeyCheck" /SC ONCE /ST 00:00 ^
/RU "SYSTEM" /RL HIGHEST ^
/TR "cmd /c certutil -store -v my > C:\Temp\adcs_keycheck.txt" /F

schtasks /Run /TN "ADCS-KeyCheck"
type C:\Temp\adcs_keycheck.txt

出力の中で、CA 証明書に対して「Private key is NOT present」や、プロバイダー関連の失敗が見える場合は、サービス視点で鍵を開けていません。逆に、SYSTEMでも問題なく秘密鍵情報が表示されるなら、鍵以外（DBパス等）の可能性が上がります。

方法B：ツールが許される環境なら SYSTEM でシェルを開く

Sysinternals の PsExec が利用できるなら、次のように SYSTEM シェルで確認できます（社内ポリシーに従ってください）。

psexec -s -i cmd
certutil -store -v my

対処：サービスアカウントに「鍵の使用権限」を付与する

やるべきことはシンプルで、CertSvc の実行アカウントに対して「CA 秘密鍵の使用（署名/復号）」を許可します。ただし、鍵の格納方式で作業が変わります。

鍵の種類	よくある保管場所/実装	典型的な付与方法	ハマりどころ
ソフトウェア鍵（CSP/CNG）	OSのキーストア（MachineKeys / Crypto\Keys）	鍵ファイルのACL付与、または証明書の「秘密鍵の管理」相当	どのファイルが該当鍵か特定が難しいことがある
HSM鍵（CSP/KSP）	HSM内。OSには参照情報のみ	HSMベンダーの管理ツールで鍵ACL/ユーザー割当、サービスアカウントのマッピング	「管理者で動く」＝「サービスで動く」にならない（非対話ログオン問題）

HSM利用時の実務ポイント

• サービスアカウントを決め打ちする（SYSTEMのままか、専用ドメインアカウントにするか）。後から変えると再設定が増えます。
• HSM 側で、鍵に対して「署名/復号が許可されたプリンシパル」を作り、CertSvc のアカウントへ割り当てます。
• HSM によっては「ログイン状態を永続化」や「サービス用ログイン（非対話）」の設定が必要です。再起動直後に起動できない場合はここが濃厚です。
• 鍵が作られた時点の利用者（例：管理者アカウント）に権限が閉じていると、SYSTEM/サービスから見えません。鍵のACLを見直すのが最短です。

現場メモ：「証明書の検証（certutil -urlfetch -verify）が成功する」だけでは、CAサービスが秘密鍵を使える証明にはなりません。検証は公開鍵で成立する処理が多く、秘密鍵のオープンは別経路で失敗します。

原因として多い：DB/ログ/CertSrv 配下のパス不整合またはACL不足

0x2/0x80070002 が出るとき、もう一つの本命がCAデータベース（ESE）とログの保存先です。インストール時に既定から変更していたり、システムドライブ縮小のために別ドライブへ移していたりすると、フォルダ未作成や権限不足で“ファイルが無い”扱いになります。

チェック：DBDirectory / LogDirectory を確認する

AD CS の保存先はレジストリに格納されており、certutil -getreg で確認できます。

certutil -getreg CA\DBDirectory
certutil -getreg CA\LogDirectory

出てきたパスについて、存在するかと書き込みできるかを確認します。

dir "（表示されたパス）"
icacls "（表示されたパス）"

対処：フォルダ作成と権限付与をやり直す

フォルダが無い場合は作成し、CertSvc の実行アカウントにフルコントロール相当を付与します。例として、CertSvc が SYSTEM なら次のようになります（環境に合わせて置き換えてください）。

mkdir D:\ADCS\DB
mkdir D:\ADCS\Log

icacls D:\ADCS\DB  /grant "SYSTEM:(OI)(CI)F" /T
icacls D:\ADCS\Log /grant "SYSTEM:(OI)(CI)F" /T

ドメインアカウントでサービスを動かしているなら、そのアカウント名で同様に付与します。共有フォルダ（UNC）をDB/ログにするのはトラブルが増えるため、基本はローカルディスクを推奨します。

CertSrv 配下（CertEnrollなど）の確認

CA 証明書や CRL の公開場所として C:\Windows\System32\CertSrv 配下を使う構成では、ここも権限不足で詰まることがあります。次を確認します。

• C:\Windows\System32\CertSrv およびサブフォルダの存在
• ディスク容量不足、読み取り専用属性
• 権限（SYSTEM/サービスアカウントが読み書き可能か）

「ポリシーモジュールが無い・未登録」と言われたときの確認ポイント

ポリシーモジュールは、要求の承認・発行ポリシー（テンプレートや制約）を担う重要部品です。ただし、本件のような起動失敗では、真犯人が鍵/DBでも“モジュールが無い”表示になることがあるため、次の順に確認します。

確認：Active PolicyModules / ExitModules の値

まずは設定値が壊れていないかを確認します。

certutil -getreg CA\PolicyModules\Active
certutil -getreg CA\ExitModules\Active

一般的な既定値は次の系統です。

• Policy：CertificateAuthority_MicrosoftDefault.Policy
• Exit：CertificateAuthority_MicrosoftDefault.Exit

もしここが明らかにおかしい（存在しない文字列、途中で切れている、別製品のモジュール名など）なら、値の復旧が必要です。既定に戻す例は次の通りです。

certutil -setreg CA\PolicyModules\Active "CertificateAuthority_MicrosoftDefault.Policy"
certutil -setreg CA\ExitModules\Active "CertificateAuthority_MicrosoftDefault.Exit"

設定変更後は、CA サービスの再起動で反映します。

net stop certsvc
net start certsvc

確認：OS側のコンポーネントが欠けていないか

「未登録」と言われる場合、AD CS の役割/機能が壊れているケースもゼロではありません。特に、コンポーネント削除や更新の途中失敗があった環境では、モジュールそのものが読み込めないことがあります。

• 直近で Windows Update / パッチ適用、ロール削除/追加をしていないか
• HSM の CSP/KSP を入れ替えた・バージョンアップした直後ではないか
• 暗号プロバイダーが「インタラクティブ前提」になっていないか

この場合でも、最初に疑うべきはやはり鍵のオープンとDBパスです。ポリシーモジュールは “最後に見える” エラーになりやすいため、先に本命を潰してから再評価すると迷子になりません。

追加の切り分け：表示言語/言語パックが影響する例

レアケースですが、Windows Server 2022 で表示言語を変更していたことが原因で AD CS が正常動作しなかったという報告もあります。Windows Server 2019 でも環境差（言語パック、ローカライズされたコンポーネント、サードパーティ製品の対応状況）で似た症状が出る可能性はあります。

「権限もDBパスも問題ないのにどうしても起動しない」「同じ手順でも英語環境では動く」などの場合は、次を確認します。

dism /online /get-intl

• 既定のシステムUI言語
• インストール済み言語

変更できる運用であれば、いったん標準（例：日本語/英語）へ戻して再起動し、挙動が変わるかを見ます。もちろん、これは最後の切り分け要素として扱うのがおすすめです。

復旧を早めるためのチェックリスト

最後に、実際に現場で「ここを押さえると復旧が早い」項目をチェックリスト化します。サブ CA の構築直後（まだ利用者影響が小さいうち）に一通り確認しておくと、後のトラブル対応が楽になります。

チェック項目	確認方法	OKの目安
CertSvc の実行アカウントが意図通り	sc qc certsvc	SYSTEMまたは設計したサービスアカウント
サービス視点でCA秘密鍵が開ける	SYSTEMタスク実行→certutil -store -v my	CA証明書で Private Key 情報が取得できる
HSM の非対話利用が成立	再起動直後に net start certsvc	手動ログオン前でも起動できる
DB/ログのパスが存在し書き込み可能	certutil -getreg CA\DBDirectory 等	フォルダ存在、ACLにサービスアカウントが含まれる
Policy/Exit モジュールの Active が既定	certutil -getreg CA\PolicyModules\Active	MicrosoftDefault.Policy / MicrosoftDefault.Exit

まとめ

Windows Server 2019 Core の AD CS（サブ CA）が 0x2/0x80070002 や「ポリシーモジュールが無い・未登録」で起動できない場合、まず疑うべきは“ファイルの欠落”ではなく“CertSvc が必要なものを読めない状態”です。

• 最優先は、CertSvc の実行アカウントが CA 秘密鍵（特にHSM）を非対話で使えるか
• 次に、DB/ログ/CertSrv 配下のパスとACLが妥当か
• 「ポリシーモジュール未登録」は、上記の失敗に引きずられた表示のこともある

鍵・パス・権限をサービス視点で整えると、見かけのエラーは一気に解消することが多いので、遠回りせずこの順番で潰していくのが最短ルートです。