WindowsセキュアブートCA証明書の期限切れ(2026年6月)とEC2への影響について調査してみた(続編)

WindowsセキュアブートCA証明書の期限切れ(2026年6月)とEC2への影響について調査してみた(続編)

2026.05.14

こんにちは!クラウド事業本部のおつまみです。

以前、WindowsセキュアブートCA証明書の期限切れとEC2への影響について記事を書きました。

https://dev.classmethod.jp/articles/windows_secure_boot_ec2_impact/

この記事では「BootModeuefi のWindowsインスタンスは要対応確認」とご紹介していました。
ですが、実際にお客様環境で14台のインスタンスを調査してみたところ、BootModeuefi でも、Windows OS側ではセキュアブートが無効化されているケースが多いことがわかりました。
今回は前回ブログの続編として、OSレベルでセキュアブートの有効/無効を確認する方法と、実際の調査結果をまとめます。

3行まとめ

  1. EC2の BootMode = uefi だけでは「セキュアブートが有効」とは判定できない
  2. 真の判定はWindows OS内の Confirm-SecureBootUEFI で行う必要がある
  3. 実例: ある環境で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

実行例
CleanShot 2026-05-14 at 17.26.08@2x

セキュアブート有効の場合(参考)

逆にセキュアブートが有効な環境では、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 だけで判定すると過剰に「要対応」とリストアップしてしまい、不必要な調査・対応工数が発生する可能性があります。

まとめ

今回の追加調査でわかったことをまとめると、以下のとおりです。

  1. EC2の BootMode = uefiブート方式の話であり、セキュアブートの有効/無効とは別概念
  2. 証明書期限切れの真の影響範囲は、Windows OS内の Confirm-SecureBootUEFI で確認する必要がある
  3. SSM Run Command の AWS-RunPowerShellScript を使えば、複数台を一括で確認できる
  4. AMIや構築時の設定によっては、BootMode = uefi でもOS側ではセキュアブート無効、というパターンが意外と多い

前回ブログの方法でリストアップした後、最終判定は必ずOSレベルで実施することをおすすめします。
そうすることで、不要な対応工数を削減でき、本当に対応が必要なインスタンスにリソースを集中できます。

最後までお読みいただきありがとうございました。どなたかのお役に立てれば幸いです。

以上、おつまみ(@AWS11077)でした!

参考

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事