Windows Server 2012 上の AD CS（社内PKI）を Windows Server 2019 へ移行するとき、「SHA-1 は移行だけで SHA-256 に自動切り替えされるのか？」という疑問と、復元作業で遭遇しやすい “The system cannot find the file specified（システムがファイルを見つけられない）” エラーが大きな壁になります。この記事では、移行の現場で詰まりやすいポイントを、原因→判断基準→具体的な手順の順で整理します。
結論：AD CS の移行だけでは SHA-1 → SHA-256 に自動で切り替わらない
OSアップグレード／サーバー移行（バックアップ＆リストア）だけで、既存の CA 証明書が SHA-1 から SHA-256 に自動更新されることはありません。移行時に既存 CA 証明書（SHA-1）と秘密鍵をそのまま引き継げば、移行後も「CA証明書自体」は SHA-1 のままです。
ここで混乱しがちなのが、「どの“SHA”の話か」です。PKI では “SHA-1 が残る場所” が複数あります。まずは用語を分解して把握すると、移行設計が一気にラクになります。
| 対象 | 何が SHA-1 / SHA-256 なのか | 移行（OSアップグレード/復元）で自動変更される？ | 主な変更方法 | 影響範囲 |
|---|---|---|---|---|
| CA証明書（ルート/中間） | CA証明書そのものの署名アルゴリズム | されない | CA証明書の更新（更新発行） | チェーン、信頼配布、AIA/CDP、監査・証跡 |
| 発行される証明書（サーバー/ユーザー等） | CAが発行時に付ける署名アルゴリズム | されない（設定しない限り現状踏襲） | CA側のハッシュ設定変更＋必要に応じて再発行 | 新規発行分（既発行は原則そのまま） |
| CRL（失効リスト） | CRLへの署名アルゴリズム | されない | CA側のハッシュ設定変更＋CRL再発行 | 失効確認、監視、PKI健全性 |
ポイントはシンプルで、「移行＝ハッシュ自動更新」ではなく、「CA証明書を更新する＝SHA-256化」です。SHA-256 にしたいなら、どこを SHA-256 化したいのか（CA証明書か、発行証明書か、CRLか）を明確にしたうえで、設計・手順に落とし込みます。
なぜ“移行だけ”で SHA-256 にならないのか
AD CS の移行（サーバー移行やバックアップ復元）は、基本的に 既存 CA の設定・鍵・データベースを「そのまま持っていく」作業です。つまり、移行後に動く CA は「別OS上で動く“同じCA”」になり、CA証明書の署名アルゴリズムも引き継がれます。
OSが新しくなったからといって、CA証明書を勝手に作り直す（＝信頼の根っこを勝手に変える）ことは、運用事故に直結します。だからこそ、SHA-256 化は 管理者が意図して実行する更新手順として分離されています。
移行前に決めるべき設計：同一鍵で更新するか、新鍵にするか
SHA-256 化の議論は、実務では「CA証明書を更新発行する」という話に集約されます。更新発行には大きく2パターンあります。
| 選択肢 | 概要 | メリット | デメリット/注意点 | 向いているケース |
|---|---|---|---|---|
| 同一鍵で更新（鍵は再利用） | 既存の秘密鍵を使い、CA証明書だけ更新 | 移行が比較的シンプル／互換性が高い／影響範囲が読める | 秘密鍵が古いまま（鍵長や運用年数の観点） | まずSHA-1を卒業したい、影響を最小化したい |
| 新鍵で更新（鍵ロールオーバー） | 新しい鍵ペアを生成してCA証明書を更新 | セキュリティ強化（鍵の刷新）／長期運用の土台が整う | 配布・互換性・チェーン設計が複雑化しやすい | 鍵が短い/古い、監査・要件で鍵更新が必須 |
「SHA-1 → SHA-256」だけが目的なら、まずは 同一鍵で更新してSHA-256化する構成がトラブルを減らしやすいです。一方で、鍵長が 1024bit だったり、HSM導入や監査要件で鍵更新が求められるなら、移行タイミングで鍵も更新する価値があります。
SHA-256 化を“確実に”進めるための現状確認（移行前の棚卸し）
移行計画の最初に、現行 CA が「どの暗号プロバイダー／どのハッシュ設定」なのかを確認します。ここを飛ばすと、SHA-256 のつもりが設定が反映されず、移行後も SHA-1 が残っていた…という事故が起きます。
最低限チェックしたい項目
- CAの種類：Enterprise CA か Standalone CA か
- 階層：Root CA か Subordinate CA（中間/発行CA）か
- CA証明書の署名アルゴリズム（SHA-1 / SHA-256）
- CAが使う暗号プロバイダー：CSP か KSP（CNG）か
- CRL/AIA/CDP の公開先（旧サーバー名が埋まっていないか）
- 証明書テンプレート（Enterprise CAの場合は再設定が必要）
確認に使える代表コマンド例
環境差はありますが、実務では次のような確認がよく使われます。
certutil -store my "＜CAの共通名＞"
certutil -getreg ca\csp\Provider
certutil -getreg ca\csp\CNGHashAlgorithmまた、Microsoft Learn の手順でも、CA証明書の情報（Cert Hash や Key Container）を出力して控える流れが紹介されています。
移行と同時に SHA-256 化する“現実的な進め方”
現場で安全に進めやすいのは、次のどれかです。
| 進め方 | 概要 | おすすめ度 | コメント |
|---|---|---|---|
| 移行前にCA証明書を更新してSHA-256化 → その状態をバックアップして移行 | 移行後のCA証明書が最初からSHA-256 | 高 | “新環境でいきなり切り替え”を避けられ、切り戻しも考えやすい |
| 先に2019へ移行 → 2019上で更新してSHA-256化 | 移行と暗号変更を分離 | 中 | 段階的に進められる一方、移行直後はSHA-1が残る |
| 移行だけしてSHA-1のまま運用継続 | とりあえず動かす | 低 | 後で必ず“技術的負債”になる。監査・互換性で詰まりやすい |
本記事のテーマである「SHA-1 が自動で変わるか？」という疑問に対しては、変わらないので、どこかのタイミングで“意図して更新”が必要、という結論になります。
SHA-256 化の実務：やることは「設定変更」＋「CA証明書の更新」
一般的な流れは次の2段階です（環境によっては CSP→KSP 移行が絡む場合があります）。
CA側のハッシュ設定をSHA-256へ（例）
Microsoft Learn では、SHA-1 を SHA-2 に変更する方法として certutil -setreg ca\csp\CNGHashAlgorithm を使う手順が紹介されています。
certutil -setreg ca\csp\CNGHashAlgorithm SHA256
net stop certsvc
net start certsvcここで重要なのは、設定を変えただけで「CA証明書そのもの」が必ずSHA-256に変わるわけではないという点です。CA証明書を SHA-256 にするには、次の「更新発行」がセットになります（特に階層構成や親CAの影響を受ける場合）。
CA証明書を更新（更新発行）
Microsoft Learn では、ルートCA証明書の更新手順として、CA コンソールから「Renew CA Certificate…」を実行する流れが整理されています。
- 「同一鍵」か「新鍵」かを選ぶ
- 更新後、CA証明書の詳細で署名アルゴリズムを確認する
- 必要に応じて配布（ドメイン/非ドメイン端末、機器、アプライアンス）を計画する
更新後に起きる“チェーンの変化”と配布の現実
CA証明書を更新すると、証明書チェーンやクライアント側の信頼（Trusted Root / Intermediate）が絡みます。特にルートCA更新では、配布が完了していない期間のためにクロス証明書が生成され、旧ルートと新ルートのチェーンを成立させる仕組みが説明されています。
実務的には、次の3点を事前に決めておくと事故が減ります。
- どの端末が、どのストアで信頼するか（ドメイン参加・非参加、サーバー/端末/機器）
- 旧CA証明書を“いつまで残すか”（古い署名検証に必要になることがあるため、安易に削除しない）
- CRL/AIA/CDP の到達性（更新・移行後も失効確認が通るか）
Windows Server 2012 → 2019 の AD CS 移行で見落としがちなポイント
テンプレートは“自動でバックアップされない”
Enterprise CA の「Certificate Templates」は Active Directory 側に保存され、バックアップ操作では自動的に復元されないため、新サーバー側でテンプレートの割り当てを再現する必要があります。
CRL/AIA/CDP に旧サーバー名が埋まっていると、移行後に検証が崩れる
Microsoft Learn では、既定の CRL Distribution Point が「CAコンピューターのホスト名を含む」ため、移行前に発行した証明書が旧ホスト名のパスを参照し、移行後に失効確認でエラーになる可能性がある点が明記されています。
対策としては次のような選択肢があります。
- 移行後も旧パスと新パスの両方に CRL を発行する（一定期間併存させる）
- DNS エイリアス（CNAME）や追加の名前解決を設計に入れ、旧ホスト名で到達できるようにする
- どうしても旧パスを消すなら、その影響（失効確認不可のリスク）を把握したうえで計画的に段階移行する
復元で “The system cannot find the file specified” が出る：原因は1つではない
“The system cannot find the file specified（0x80070002）” は、AD CS の世界では原因が複数パターンあります。復元の文脈でよく起きるのは、次のどれかです。
| よくある発生タイミング | 見えている症状 | 典型原因 | 初手の確認 |
|---|---|---|---|
| CAコンソール（certsrv.msc）を開いた瞬間 | コンソールが開けず 0x80070002 | AD CS をインストールしただけで「構成（Configure）」が未実施 | Server Manager の通知から「Configure AD CS」を実行したか |
| Restore CA ウィザード実行時 | バックアップを指定しても復元できない | バックアップ構造が想定と違う／必要ファイル不足／指定フォルダの選び方ミス | フォルダ構造と必要ファイルが揃っているか |
| CertSvc（証明書サービス）起動時 | サービスが起動しない、CAが不整合 | レジストリ未復元、ポリシーモジュール不整合、暗号プロバイダー不一致等 | イベントログ、CA設定の復元状況 |
パターンA：AD CS の「構成ウィザード未実施」で 0x80070002
Windows Server 2019 では、AD CS ロールをインストールしただけでは CA は使えず、Server Manager の「Configure Active Directory Certificate Services」を実行して初めて構成が完了します。構成が未完了だと、CA コンソールで “The system cannot find the file specified” が出るケースがあります。
復元以前の話として、まず「ロール追加」→「構成」まで完了しているかを確認してください。
パターンB：バックアップの“フォルダ構造”が違い、復元が進まない
Microsoft Learn の CA 移行手順では、バックアップ先フォルダの構造が正しくない場合にエラーになることと、正しいフォルダ構造例が示されています。
典型的な構造イメージ（例）
C:\CA-Backup\
├─ CA_NAME.p12
└─ Database\
├─ certbkxp.dat
├─ CA_NAME.edb
└─ edb*.log（複数）さらに、復元ウィザードでどのフォルダを選ぶかも落とし穴です。復元処理が “DataBase” サブフォルダを前提にしているため、親フォルダ（DataBase を含む側）を選択する必要がある、という注意点も実務ではよく効きます。
パターンC：DB/ログの配置先パスが存在しない（または旧サーバー前提）
CA のデータベースやログの保存先はレジストリ設定に依存します。旧サーバーでは D:\CertLog に置いていたのに、移行先では D: が無い／フォルダが作られていない、という状態だと「ファイルが見つからない」系で止まります。
対処としては次のいずれかです。
- 移行先に同じドライブ文字・同じフォルダを用意する（最短で復元しやすい）
- レジストリのエクスポートを移行先のパスに合わせて修正してからインポートする（Microsoft Learn の移行手順でも、旧パスと新パスが違う場合の調整に触れています）
パターンD：レジストリ設定が戻っておらず、ポリシーモジュール等の参照が壊れている
CA の構成はレジストリに多く含まれます。Microsoft Learn の移行手順でも、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration のエクスポート／インポートが手順に組み込まれています。
特に “The system cannot find the file specified” は、ポリシーモジュールが見つからない／正しく登録されていない等の文脈でも発生することがあり、レジストリ復元漏れや、暗号プロバイダー差分が引き金になります。
復元を成功させるための推奨手順（オンプレ2012 → Azure上2019 を想定）
スレッドや現場で“揃っていそうで揃っていない”のが、バックアップ要素と復元順序です。ここでは、移行先での手順を「失敗しにくい順」にまとめます。
移行前：バックアップで必ず揃えるもの
| 要素 | 目的 | 不足すると起きやすいこと | 補足 |
|---|---|---|---|
| CA証明書＋秘密鍵（.p12/.pfx） | 同一CAとして継続運用する根幹 | 証明書が選べない／起動できない／別CA扱い | パスワード管理が重要 |
| CAデータベース（.edb）＋ログ（.log） | 発行済み証明書・失効情報の継承 | 過去の発行履歴が消える／失効確認が破綻 | できればフルバックアップ |
| レジストリ（CertSvc\Configuration） | CRL/AIA/CDP、各種設定、権限等の継承 | CAの設定が戻らない／参照先不整合 | 移行先パスに合わせて調整が必要な場合あり |
| テンプレート割り当てメモ | Enterprise CA の再現 | 必要なテンプレートが発行できない | ADにあるため“手作業で再設定”になりやすい |
バックアップ方法として、PowerShell の Backup-CARoleService や certutil -backup、GUI の「Back up CA」等が環境により使われます。レジストリのバックアップ（export）は別で実施する前提で説明されている資料もあるため、取りこぼしが無いか要注意です。
移行先（Windows Server 2019）側：復元の順序
- バックアップ一式をローカルディスクへコピー（例：
C:\CA-Backup）
ネットワーク共有や権限が絡むと “見つからない扱い” になることがあるため、まずローカルで試します。 - AD CS ロールを追加（まだ復元しない）
- Server Manager から AD CS の構成（Configure AD CS）を完了
未構成だと CA コンソール自体が開けず 0x80070002 になることがあります。 - 既存の CA 証明書（秘密鍵付き）を使う構成でセットアップ
復元シナリオでは “新しい鍵を作らない” のが重要です。鍵が無いと、DBを戻しても同一CAになりません。 - CAサービスを止める（またはメンテナンスモード相当で発行を止める）
DB/設定が戻る前に証明書発行が走ると、想定外の証明書が出ます。 - レジストリ設定を復元（必要ならパス修正）
旧サーバーの DB/ログパスを使っていた場合、移行先で同じパスを用意するか、レジストリ側を移行先に合わせます。 - DB/ログ格納先フォルダを作成（存在しないと失敗しやすい）
- Restore CA で DB/ログを復元
フォルダ指定ミスが多いので、「DataBase フォルダを含む親」を選ぶ点を再確認します。 - CAサービス起動 → 機能確認（発行・失効・CRL発行）
- テンプレート割り当てを再現（Enterprise CA）
“The system cannot find the file” を早く潰すためのチェックリスト
復元エラーは、闇雲にやると時間が溶けます。次のチェックを上から潰すと、原因特定が速くなります。
| チェック項目 | 確認ポイント | OK/NGの判断 | NGならやること |
|---|---|---|---|
| バックアップはローカルにあるか | C:\ などローカルディスク上で復元している | 共有パスを使っていない | まずローカルにコピーしてやり直す |
| フォルダ構造が正しいか | .p12 と Database 配下の .edb/.log が揃う | CA_NAME.edb が存在 | バックアップを取り直す／構造を修正 |
| 指定フォルダが正しいか | Restore で “親フォルダ” を選んでいる | DataBase サブフォルダ前提を満たす | 親フォルダを選択し直す |
| AD CS の構成が完了しているか | Server Manager の「構成」通知が消えている | certsrv.msc が開く | Configure AD CS を実施 |
| DB/ログパスが存在するか | 移行先に旧パス相当のフォルダがある | 空フォルダでも存在すればOK | フォルダ作成／レジストリのパス修正 |
| レジストリが復元されているか | CertSvc\Configuration が旧設定に近い | CRL/AIA/CDP などが戻っている | reg export の取り直し／インポート |
移行後に必ずやるべき動作確認（ここを抜くと“静かに壊れる”）
AD CS は「サービスが起動した＝成功」ではありません。発行・失効・失効確認（CRL到達）まで通して初めて移行完了です。おすすめの確認観点をまとめます。
| 確認観点 | 具体的な確認内容 | 失敗すると何が起きる？ |
|---|---|---|
| CA証明書 | 署名アルゴリズム、期限、チェーン | 信頼の崩壊、TLS/認証失敗 |
| 新規発行 | 代表テンプレートで発行できるか | 自動登録が止まる、端末・サーバー証明書が枯渇 |
| CRL発行・公開 | HTTP/LDAP の CDP にアクセスできるか | 失効確認できず、認証が不安定化 |
| 旧証明書の検証 | 移行前に発行した証明書が失効確認まで通るか | “移行前に発行したものだけ壊れる”事故 |
| テンプレート割り当て | 以前と同じテンプレートが発行CAに紐づくか | 必要な用途の証明書だけ発行できない |
CRL/AIA/CDP の健全性確認は、Microsoft の資料でも触れられている pkiview（PKI View）等を活用すると、到達性の抜け漏れに気づきやすいです。
まとめ：SHA-256 化は“移行作業”ではなく“更新作業”として計画する
- Windows Server 2012 → 2019 へ AD CS を移行しても、SHA-1 → SHA-256 が自動で切り替わることはない（CA証明書は引き継がれる）
- SHA-256 化したいなら、CA側のハッシュ設定とCA証明書の更新（更新発行）をセットで計画する
- 復元時の “The system cannot find the file specified” は、未構成・バックアップ構造・パス不整合・レジストリ不足など複数原因があるため、タイミング別に切り分ける
- 移行後は、発行・CRL発行・失効確認まで通して初めて完了。特に CRL/AIA/CDP の旧ホスト名問題は要注意
PKI は「一度作ると長く残る」分、移行時の小さな見落としが数年後の大障害に化けます。SHA-256 化と移行を同時にやる場合ほど、段階的に切り分け（事前更新→移行、または移行→更新）、確認項目を表のチェックリストで管理して進めるのがおすすめです。
コメント