WindowsセキュアブートCA証明書の期限切れ(2026年6月)とEC2への影響について調査してみた(続編)
こんにちは!クラウド事業本部のおつまみです。
以前、WindowsセキュアブートCA証明書の期限切れとEC2への影響について記事を書きました。
この記事では「BootMode が uefi のWindowsインスタンスは要対応確認」とご紹介していました。
ですが、実際にお客様環境で14台のインスタンスを調査してみたところ、BootMode が uefi でも、Windows OS側ではセキュアブートが無効化されているケースが多いことがわかりました。
今回は前回ブログの続編として、OSレベルでセキュアブートの有効/無効を確認する方法と、実際の調査結果をまとめます。
3行まとめ
- EC2の
BootMode = uefiだけでは「セキュアブートが有効」とは判定できない - 真の判定はWindows OS内の
Confirm-SecureBootUEFIで行う必要がある - 実例: ある環境で14台調査したところ、全14台がOS側でセキュアブート無効 → 証明書期限切れの影響対象は0台だった
前回のおさらい
前回ブログでは、影響対象インスタンスの確認方法として AWS CLI による BootMode の一括確認をご紹介しました。
aws ec2 describe-instances \
--filters "Name=platform,Values=windows" \
--query 'Reservations[].Instances[].[InstanceId, BootMode, State.Name]' \
--output table \
--region ap-northeast-1
この方法で BootMode = uefi のインスタンスをリストアップし、「これらが要対応確認のインスタンスです」と判定していました。
しかし、後述するとおり、この判定だけでは過剰見積もりになる可能性があることがわかりました。
BootMode と SecureBoot は別概念
今回一番お伝えしたい重要なポイントです。
EC2の BootMode と Windows OSの「セキュアブートの有効/無効」は別概念となります。
| 項目 | 意味 | 影響範囲との関係 |
|---|---|---|
EC2 BootMode = uefi |
ブートローダーの起動方式(Legacy BIOS vs UEFI) | これだけでは判定不可 |
Windows Confirm-SecureBootUEFI |
UEFI上で署名検証を強制するか否か | 今回の証明書期限切れの影響範囲はこちら |
つまり、BootMode = uefi でEC2が起動していても、Windows OS内部でセキュアブートが無効化されていれば、証明書の検証は行われないため、期限切れの影響を受けません。
BootMode = uefi はあくまで「UEFI形式で起動できる準備が整っている」状態であり、セキュアブートを有効化する/しないは別の設定で制御されています。
公式ドキュメントでもこの区別は明確に記述されています。
UEFI セキュアブートは、UEFI ファームウェアの機能であり、ブートプロセス中にロードされた最上位レベルのブートローダーやドライバーが信頼されたパブリッシャーによって署名されていることを保証します。
— UEFI Secure Boot - Amazon EC2 User Guide
OSレベルでセキュアブートを確認する方法
OS内部での有効/無効を確認するには、Windowsの組み込みPowerShellコマンドを使います。
PowerShell(直接ログインでの確認)
RDPでログインしてPowerShellを管理者権限で起動し、以下を実行します。
# セキュアブートの有効状態を確認
Confirm-SecureBootUEFI
# UEFI証明書(KEK / DB)の中身を取得
Get-SecureBootUEFI -Name KEK
Get-SecureBootUEFI -Name db
Confirm-SecureBootUEFI の戻り値が True なら有効、False なら無効です。
SSM Run Command で複数台を一括確認
台数が多い場合は、SSM Run Command の AWS-RunPowerShellScript を使うと、各インスタンスにログインせずに一括で確認できます。
確認用PowerShellスクリプトの全文がこちらです。
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
$ErrorActionPreference = 'Continue'
Write-Host '===== OS BUILD ====='
Get-ComputerInfo | Select-Object OsName, OsVersion, OsBuildNumber, WindowsProductName | Format-List
Write-Host '===== HOTFIX (KB5025885 / KB5012170) ====='
Get-HotFix -Id KB5025885, KB5012170 -ErrorAction SilentlyContinue | Select-Object HotFixID, InstalledOn | Format-Table -AutoSize
Write-Host '===== SECURE BOOT STATUS ====='
try { $sb = Confirm-SecureBootUEFI; Write-Host "SecureBoot Enabled: $sb" } catch { Write-Host "SecureBoot check failed: $_" }
Write-Host '===== KEK certificates ====='
try {
$kek = Get-SecureBootUEFI -Name KEK
$kekText = [System.Text.Encoding]::ASCII.GetString($kek.Bytes)
($kekText -split [char]0) | Where-Object { $_ -match 'Microsoft|2011|2023|Corporation' } | Select-Object -Unique
} catch { Write-Host "KEK read failed: $_" }
Write-Host '===== DB certificates ====='
try {
$db = Get-SecureBootUEFI -Name db
$dbText = [System.Text.Encoding]::ASCII.GetString($db.Bytes)
($dbText -split [char]0) | Where-Object { $_ -match 'Microsoft|2011|2023|Corporation' } | Select-Object -Unique
} catch { Write-Host "DB read failed: $_" }
AWS CLIから一括実行する場合は以下のとおりです。
aws ssm send-command \
--region ap-northeast-1 \
--document-name "AWS-RunPowerShellScript" \
--comment "SecureBoot check" \
--instance-ids i-xxxxxxxxxxxxxxxxx i-yyyyyyyyyyyyyyyyy \
--parameters file://params.json \
--query 'Command.CommandId' \
--output text
params.json には先ほどのPowerShellスクリプトを commands 配列として格納します。
実行後、get-command-invocation で各インスタンスの結果を取得できます。
aws ssm get-command-invocation \
--region ap-northeast-1 \
--command-id <CommandId> \
--instance-id i-xxxxxxxxxxxxxxxxx \
--query 'StandardOutputContent' \
--output text
出力サンプルと読み解き方
セキュアブート無効の場合(実例)
実際にWindows Server 2019で実行した際の出力例です。
===== OS BUILD =====
OsName : Microsoft Windows Server 2019 Datacenter
OsVersion : 10.0.17763
OsBuildNumber : 17763
WindowsProductName : Windows Server 2019 Datacenter
===== HOTFIX (KB5025885 / KB5012170) =====
(出力なし → 該当KB未適用)
===== SECURE BOOT STATUS =====
SecureBoot Enabled: False
===== KEK certificates =====
KEK read failed: Variable is currently undefined: 0xC0000100
===== DB certificates =====
DB read failed: Variable is currently undefined: 0xC0000100
Windows Server 2025での例も同様の結果でした。
===== OS BUILD =====
OsName : Microsoft Windows Server 2025 Datacenter
OsVersion : 10.0.26100
OsBuildNumber : 26100
WindowsProductName : Windows Server 2025 Datacenter
===== SECURE BOOT STATUS =====
SecureBoot Enabled: False
===== KEK certificates =====
KEK read failed: 変数は現在定義されていません: 0xC0000100
===== DB certificates =====
DB read failed: 変数は現在定義されていません: 0xC0000100
実行例

セキュアブート有効の場合(参考)
逆にセキュアブートが有効な環境では、KEK / DB 読み取り部分で以下のような文字列が返ってきます。
===== KEK certificates =====
Microsoft Corporation KEK CA 2011
Microsoft Corporation KEK CA 2023
===== DB certificates =====
Microsoft Windows Production PCA 2011
Microsoft UEFI CA 2011
Microsoft UEFI CA 2023
2023 という文字列が含まれていれば新証明書が適用済み、2011 のみなら更新が必要、という判定が可能です。
出力の読み解き方
| 出力箇所 | 結果 | 意味 |
|---|---|---|
SecureBoot Enabled: False |
無効 | OS上でセキュアブートが無効化されている。証明書期限切れの影響を受けない |
KEK / DB read failed: 0xC0000100 |
UEFI変数未定義 | セキュアブート無効環境では変数が存在しないため正常な反応。SecureBoot=False の証跡となる |
KB5025885 / KB5012170 出力なし |
KB未適用 | セキュアブート無効環境では適用不要 |
実例: 14台調査の結果
実際にお客様環境(Windows Server 2019が11台、Windows Server 2025が3台、合計14台)で確認した結果がこちらです。
| 項目 | 結果 |
|---|---|
BootMode = uefi のインスタンス |
14台 |
Confirm-SecureBootUEFI = True のインスタンス |
0台 |
Confirm-SecureBootUEFI = False のインスタンス |
14台 |
| KB5025885 / KB5012170 適用済みのインスタンス | 0台 |
| 証明書期限切れの影響を受けるインスタンス | 0台 |
前回ブログの判定方法(BootMode = uefi を要対応として扱う)では複数台のインスタンスが要対応候補となっていましたが、OSレベルでの確認の結果、実際は1台も対応不要でした。
このように、BootMode だけで判定すると過剰に「要対応」とリストアップしてしまい、不必要な調査・対応工数が発生する可能性があります。
まとめ
今回の追加調査でわかったことをまとめると、以下のとおりです。
- EC2の
BootMode = uefiはブート方式の話であり、セキュアブートの有効/無効とは別概念 - 証明書期限切れの真の影響範囲は、Windows OS内の
Confirm-SecureBootUEFIで確認する必要がある - SSM Run Command の
AWS-RunPowerShellScriptを使えば、複数台を一括で確認できる - AMIや構築時の設定によっては、
BootMode = uefiでもOS側ではセキュアブート無効、というパターンが意外と多い
前回ブログの方法でリストアップした後、最終判定は必ずOSレベルで実施することをおすすめします。
そうすることで、不要な対応工数を削減でき、本当に対応が必要なインスタンスにリソースを集中できます。
最後までお読みいただきありがとうございました。どなたかのお役に立てれば幸いです。
以上、おつまみ(@AWS11077)でした!







