Windows Server 2016/2019 で CVE-2013-3900（WinVerifyTrust の Authenticode 署名検証）対策として EnableCertPaddingCheck を設定しようとすると、Wintrust\Config キーが存在せず戸惑うことがあります。キー作成の可否、REG_SZ/REG_DWORD の違い、(既定)値、副作用、2016/2019/2022 への必要性、GPO/PowerShell 展開まで実務目線で整理します。
CVE-2013-3900 と EnableCertPaddingCheck を最短で理解する
CVE-2013-3900 は、Windows の署名検証機構（WinVerifyTrust）における Authenticode 署名の検証処理に関する問題として知られています。実務上よく挙がるのは「署名付きであるはずのバイナリの扱い（信頼の判定）が、意図より緩くなる可能性がある」という点です。
この問題に対して Microsoft が案内している緩和策のひとつが、レジストリ値 EnableCertPaddingCheck によって、署名検証をより厳格にする挙動を “オプトイン（任意で有効化）” する方法です。つまり「OS に実装はあるが、既定では厳格化が常時オンではない」ため、対処方針として採る場合はレジストリで明示的に有効化します（Microsoft Japan Windows Technology Support Blog の解説が分かりやすいです）。
Windows Server 2016/2019 で Wintrust\Config キーが見当たらない理由
結論から言うと、Wintrust\Config キーが最初から存在しないことは珍しくありません。これは「設定を入れていない限り、OS がそのキーを作らずに運用できる」設計であるためです。よって、レジストリ上に該当キーが無い＝不具合ではなく、単に未構成の状態であることが多いです。
このため、CVE-2013-3900 の緩和策として EnableCertPaddingCheck を入れる目的であれば、キーが無い場合は作成して問題ありません。
作成してよいレジストリパス（64bit OS の基本形）
Windows Server 2016/2019/2022 の多くは 64bit OS です。64bit OS では 32bit アプリケーション向けのレジストリビューが分離されるため、実務では次の 2 か所 をセットで入れるのが一般的です（スキャナーの判定もこのパターンが多いです）。
| 対象 | パス | 値名 | 推奨データ | 狙い |
|---|---|---|---|---|
| 64bit ビュー | HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Wintrust\Config | EnableCertPaddingCheck | 1 | 64bit プロセス側の挙動を厳格化 |
| 32bit ビュー（Wow6432Node） | HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config | EnableCertPaddingCheck | 1 | 32bit プロセス側の挙動を厳格化 |
ポイントは「Wintrust」や「Config」が無ければ 自分で作る こと、そして 64bit OS の場合は Wow6432Node 側も忘れない ことです。
REG_SZ か REG_DWORD か：結局どっちが正しい？
ここは現場で一番混乱しがちなところです。結論を実務向けにまとめると以下のとおりです。
- 案内や記事によって REG_SZ（文字列） と REG_DWORD の記載が揺れた時期がある。
- ただし挙動としては、この値を「1 かどうか」で判定している実装のため、型そのものが致命的にならないケースがある（CIRCL の脆弱性情報でも整理されています）。
- とはいえ運用上は REG_DWORD（1） が分かりやすく、監査・管理・誤設定防止の面で推奨。
- すでに REG_SZ の “1” で展開済みの場合、環境によってはそれで判定が通ることもあるため、「絶対に全部やり直し」ではなく、スキャナー判定と実挙動で最終判断するのが現実的。
| 観点 | REG_DWORD（推奨） | REG_SZ（”1″） |
|---|---|---|
| 管理のしやすさ | 数値として統一でき、誤設定が起きにくい | 文字列混在で棚卸しが難しくなることがある |
| 現場の説明コスト | 「DWORD の 1」で完結 | 「文字列でも動く場合がある」が説明に追加で必要 |
| スキャナー判定 | 通りやすい（実装が DWORD を期待することが多い） | 実装次第で誤検知/未検出になる場合がある |
迷ったら「REG_DWORD（1）」で統一するのが、監査・運用・引き継ぎの観点で強いです。
(既定) 値 {Default}（Reg_SZ）が作られたが問題ない？
レジストリキーを新規作成すると、Regedit 上で (既定) が表示されます。表示やツールによっては “{Default}” のように見えることがありますが、これは「キーのデフォルト値枠」があるだけで、通常は EnableCertPaddingCheck の判定そのものには関与しません。
- 対策として参照されるのは基本的に EnableCertPaddingCheck の値です。
- (既定) は未設定でも一般的に問題になりません。
- 不要なら触らない（変更しない）のが無難です。
反映には再起動が必要？
はい。EnableCertPaddingCheck の設定は、実務では OS 再起動後に反映すると案内されることが多いです（Microsoft Japan Windows Technology Support Blog でも再起動が言及されています）。
「設定を入れたのにスキャナーが直らない」「検証ツールの結果が変わらない」といったケースは、再起動を挟んでいないことが原因になりやすいので、展開計画には必ず再起動枠を含めてください。
副作用（影響）として何が起き得るか
EnableCertPaddingCheck を有効化すると、署名検証が厳格化されます。これはセキュリティ上のメリットですが、裏返すと、過去の署名ツールや特殊な署名方式で生成された “仕様に完全準拠していない署名” を含むバイナリが、次のように扱われる可能性があります。
- 署名付きのはずなのに「未署名のように見える」
- 署名の信頼判定が落ち、実行時に「発行元を確認できません」などの警告が出る
- インストーラーや更新プログラムが署名検証を前提にしている場合、インストール/更新が止まる
特に影響が出やすいのは、次のような資産です。
- 古い業務アプリのインストーラー（MSI/EXE）
- 長期運用で更新されていないエージェント製品
- 社内の独自署名・独自パッケージ（ビルドチェーンが古い）
- 過去に署名を付けたまま、再署名せず流用している配布物
本番へ一括適用する前に、必ず業務アプリの起動・更新・インストール手順を検証してください。Microsoft Japan Windows Technology Support Blog でも「影響の可能性」に触れています。
Windows Server 2016/2019/2022 は実施が必要？（MS13-098 に載っていない問題）
「MS13-098 の影響を受ける製品一覧に 2016/2019/2022 が見当たらないので、サーバーは対象外では？」という疑問は自然です。ここは次のように整理すると現場判断がしやすくなります。
- MS13-098 は 2013 年当時のセキュリティ情報であり、当時存在しない（または対象として書かれていない）後年の OS が一覧に載らないことがあります。
- 一方で、CVE-2013-3900 の緩和策としての EnableCertPaddingCheck は、現在サポートされている OS にも実装されており、必要ならオプトインで有効化するという整理が公開情報として説明されています。
つまり「2016/2019/2022 だから絶対不要」とは断言しにくく、組織のセキュリティ方針として 署名検証の厳格化を求めるなら、サーバーでも設定が必要という位置づけになります。加えて、脆弱性スキャナー（例：Nessus など）は、OS バージョンよりも「指定レジストリに EnableCertPaddingCheck=1 が存在するか」で判定する実装が多く、監査対応の観点でも設定が求められるケースがあります（Tenable のプラグイン解説が参考になります）。
手動での設定手順（Regedit）
手動設定は検証用途（数台だけ先行）では有効ですが、本番大規模展開は GPO または PowerShell を推奨します。手動の場合は以下の流れです。
- レジストリエディター（regedit）を管理者で起動
- 次のキーを作成（存在しなければ）
64bit ビュー
HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Wintrust\Config
32bit ビュー（64bit OS の場合）
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config
- それぞれの Config キー配下に値を追加
| 項目 | 値 |
|---|---|
| 値の名前 | EnableCertPaddingCheck |
| 種類 | DWORD（32 ビット） |
| データ | 1（10 進でも 16 進でも 1） |
- OS を再起動
- 再起動後に値が残っているか、動作やスキャナー判定を確認
PowerShell での設定テンプレ（推奨）
複数台展開や再現性重視なら PowerShell が安全です。以下は「キー作成 → DWORD=1 を設定 → 確認 → 再起動案内」までを含むテンプレです（必要に応じてリモート実行や SCCM/Intune/構成管理に組み込めます）。
# EnableCertPaddingCheck を 64bit / 32bit ビュー両方に設定するテンプレ
# 管理者権限で実行してください
$paths = @(
"HKLM:\Software\Microsoft\Cryptography\Wintrust\Config",
"HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config"
)
foreach ($p in $paths) {
if (-not (Test-Path $p)) {
New-Item -Path $p -Force | Out-Null
}
# DWORD で 1 を設定（既存があれば上書き）
New-ItemProperty -Path $p `
-Name "EnableCertPaddingCheck" `
-Value 1 `
-PropertyType DWord `
-Force | Out-Null
}
# 設定確認
foreach ($p in $paths) {
Write-Host "=== $p ==="
Get-ItemProperty -Path $p -Name "EnableCertPaddingCheck" | Select-Object EnableCertPaddingCheck
}
Write-Host ""
Write-Host "設定は反映のため再起動が必要です。計画したメンテナンス枠で再起動してください。" 「すでに REG_SZ の ‘1’ を配ってしまった」場合に、型を揃える目的で上書きする運用でもこのテンプレが使えます。
設定が入ったかをコマンドで素早く確認する
GUI を開かずに確認したい場合は、次のような方法が便利です。
# PowerShell で確認
Get-ItemProperty "HKLM:\Software\Microsoft\Cryptography\Wintrust\Config" -Name EnableCertPaddingCheck -ErrorAction SilentlyContinue
Get-ItemProperty "HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" -Name EnableCertPaddingCheck -ErrorAction SilentlyContinue
# コマンドプロンプト（reg query）で確認
reg query "HKLM\Software\Microsoft\Cryptography\Wintrust\Config" /v EnableCertPaddingCheck
reg query "HKLM\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" /v EnableCertPaddingCheck監査で「全サーバーの設定有無」を短時間で集計したい場合は、PowerShell Remoting や構成管理でこの確認結果を回収すると効率的です。
GPO（グループポリシー）で配布する場合の設計ポイント
Active Directory ドメイン配下のサーバー群に一括展開するなら、グループポリシーの「グループ ポリシーの基本設定（GPP）」でレジストリ配布するのが一般的です。
おすすめは「コンピューターの構成」側に寄せて、HKLM に書くことです（サーバー用途ではユーザー別（HKCU）にしない方が運用しやすいことが多いです）。
| 項目 | 設定例 | 補足 |
|---|---|---|
| 対象 | コンピューターの構成 > 基本設定 > Windows の設定 > レジストリ | サーバー一括適用向け |
| アクション | 更新（Update） | 既存値があっても揃えられる |
| ハイブ（Hive） | HKEY_LOCAL_MACHINE | HKLM に統一 |
| キー パス（例1） | Software\Microsoft\Cryptography\Wintrust\Config | 64bit ビュー |
| キー パス（例2） | Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config | 32bit ビュー（64bit OS） |
| 値名 | EnableCertPaddingCheck | 固定 |
| 値の種類 | REG_DWORD | 推奨 |
| 値データ | 1 | 有効化 |
落とし穴として、GPP のレジストリ項目には「32 ビット レジストリ ビュー」関連の挙動が絡むことがあります。混乱を避けるには、上記のように 2 パスを明示して 2 つのアイテムとして配布するのが分かりやすいです。
脆弱性スキャナーの判定と、現場での“すれ違い”を防ぐ
スキャナーは「OS の更新履歴」よりも「レジストリ値が存在するか」を重視することがあります。特に CVE-2013-3900 の EnableCertPaddingCheck は、次のパターンが “検出条件” になりがちです。
- 指定パスに EnableCertPaddingCheck が存在する
- 値が 1 になっている（型は環境やスキャナー実装で期待が分かれることがある）
- 64bit OS で Wow6432Node 側が欠けていると未対策判定になることがある
- 再起動前にスキャンすると未反映扱いになることがある
現場で揉めやすいのは「REG_SZ の ‘1’ で運用していたが、スキャナーが DWORD を期待していて NG」というケースです。監査対応を含めて確実にするなら、REG_DWORD（1）で統一し、再起動後のスキャンで収束させるのが安全です。
導入前のテスト観点（最小で外さないチェックリスト）
「副作用が怖いので適用できない」という状況を避けるために、最初からテスト計画を小さく作っておくのがコツです。以下はサーバー運用でよく効く最小チェックです。
| 観点 | チェック内容 | 対象例 |
|---|---|---|
| 業務アプリ起動 | 起動・ログイン・主要画面まで | アプリ本体 EXE/DLL |
| 更新・パッチ | 更新モジュールが正常に適用できるか | エージェント更新、定期メンテ |
| インストーラー | 新規導入/再インストールが通るか | MSI/Setup.exe |
| 自社署名 | 社内コード署名の検証が落ちないか | 社内配布ツール |
| 運用手順 | 再起動後のサービス起動・監視復旧 | 本番運用フロー |
推奨は「検証環境 → パイロット（業務影響が小さいサーバー群）→ 全体展開」です。もし影響が出た場合でも、原因切り分けがしやすくなります。
ロールバック（元に戻す）手順
影響が出た場合に備えて、戻し方も明文化しておくと安心です。ロールバックは基本的に「値を削除」または「0 に戻す」です（運用規程に合わせて選択してください）。
# 値を削除する（64bit / 32bit ビュー）
Remove-ItemProperty "HKLM:\Software\Microsoft\Cryptography\Wintrust\Config" -Name EnableCertPaddingCheck -ErrorAction SilentlyContinue
Remove-ItemProperty "HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" -Name EnableCertPaddingCheck -ErrorAction SilentlyContinue
Write-Host "ロールバック後も再起動が必要です。"削除と 0 のどちらにするかは、監査要件（「存在してはいけない」か「0 で無効化して良い」か）により変わります。迷う場合は、監査側の判定基準（どの値を見ているか）を先に押さえると手戻りが減ります。
よくある質問（FAQ）
Wintrust や Config キーを自分で作っても大丈夫？
大丈夫です。 この対策は「既定で存在しないキーに、必要な値を追加して挙動を切り替える」タイプのため、キーが無い場合は作成して適用します。
REG_SZ で “1” を入れてしまった。即時に全部やり直すべき？
運用リスクとしては「スキャナーが DWORD を期待して未対策判定になる」「運用者が後から混乱する」の2点が大きいです。スキャナー判定・監査要件・本番影響の優先度を踏まえ、可能なら DWORD（1）へ統一するのがおすすめです。
(既定) 値が作られた／{Default} が見えるが削除していい？
通常は触らないのが無難です。EnableCertPaddingCheck が目的なので、(既定) の表示があること自体は多くのケースで問題になりません。
Wow6432Node 側は本当に必要？
64bit OS でも 32bit プロセスは存在します。署名検証が 32bit 側のレジストリビューを参照する可能性や、スキャナーが両方を確認する実装があるため、実務では 両方入れる運用が安全です。
再起動できないサーバーはどうする？
再起動が必須になり得るため、緊急で「とにかく今日中に監査を通す」用途には向きません。メンテナンス枠に組み込み、段階展開してください。再起動前後でスキャナー結果が変わることもあるので、スキャンタイミングも計画に入れます。
コメント