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

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

2026.04.23

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

Microsoftより、Windowsセキュアブート証明書が2026年6月に期限切れになるというアナウンスが出ています。

https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e

こちら、EC2上のWindowsインスタンスにも影響する可能性があります。
今回は影響の有無の確認方法と対応手順をまとめます。

3行まとめ

  1. Microsoftの2011年発行セキュアブート証明書が2026年6月に期限切れになる
  2. EC2でUEFIモード(セキュアブート有効)を使っているWindowsインスタンスは再起動・起動時にブート失敗のリスクあり
  3. 稼働中のインスタンスが突然止まることはないが、Windows Updateで事前対応が必要

セキュアブート証明書更新とは

Microsoftが2011年に発行したWindowsセキュアブート証明書を2023年版に更新するものです。
この証明書は、PCやサーバーの起動時にブートソフトウェアの正当性を検証するために使われています。

旧証明書が期限切れになると、未更新のデバイスでは以下の保護が機能しなくなります。

  • Windowsブートマネージャーの署名検証
  • セキュアブートデータベース(DB/DBX)の整合性確認
  • 新規発見されたブートレベルの脆弱性に対する軽減策

EC2への影響

セキュアブートが有効なインスタンスだけが対象

EC2のWindowsインスタンスはデフォルトではセキュアブートが無効です。
影響を受けるのは、UEFIモードでセキュアブートを明示的に有効化しているインスタンスのみです。

条件 影響
BootMode = None(デフォルト) 影響なし
BootMode = legacy-bios 影響なし
BootMode = uefi(セキュアブート有効) 要対応確認

「突然止まる」ことはないが再起動時が危ない

よくある誤解として「証明書が切れたらインスタンスが止まる」と思われがちですが、稼働中のインスタンスが突然停止することはありません。
リスクが発生するのは「起動・再起動のタイミング」です。

状況 リスク
稼働中のまま(再起動なし) 影響なし
再起動を実施した場合 ブート失敗・起動不能になる可能性あり
stopped → 起動した場合 同上

特に注意が必要なのは以下のシナリオです。

  1. 定期メンテナンス・OSパッチ適用での再起動
  2. インスタンスタイプ変更・AZ移動に伴う再起動
  3. OSクラッシュ・自動再起動
  4. 停止中インスタンスの起動

影響対象インスタンスの確認方法

AWSコンソールで確認

EC2コンソール → インスタンス詳細 → 「ブートモード」列が uefi になっているインスタンスが対象です。

CleanShot 2026-04-23 at 11.13.35@2x

AWS CLIで一括確認

aws ec2 describe-instances \
  --filters "Name=platform,Values=windows" \
  --query 'Reservations[].Instances[].[InstanceId, Tags[?Key==`Name`].Value|[0], BootMode, State.Name]' \
  --output table \
  --region ap-northeast-1

BootModeuefi になっているインスタンスが対応確認の対象です。

パッチ適用状況の確認方法

STEP 1:確認すべきKB番号を把握する

今回のセキュアブート証明書更新に対応するKBは以下の2つです。

KB番号 内容 リリース
KB5012170 セキュアブートDB更新(UEFIデータベースへの新証明書追加) 2022年8月
KB5025885 セキュアブートDBX更新(失効リストの更新) 2023年7月

両方が適用済みであれば対応完了です。適用済みの場合は結果が返り、未適用の場合は何も返ってこない(空) ので一目でわかります。

STEP 2:パッチ適用状況を確認する

パターン A:SSM Run Commandで確認する(推奨・ログイン不要)

SSMが導入済みであれば、EC2にログインせずに複数インスタンスへ一括確認できます。

① AWSコンソールから実行する手順

  1. AWS Systems ManagerRun Command を開く
  2. コマンドドキュメントで AWS-RunPowerShellScript を選択
  3. 「コマンドパラメータ」に以下を入力する
Get-HotFix -Id KB5025885, KB5012170 | Select-Object HotFixID, InstalledOn
  1. ターゲットでUEFI対象インスタンスを指定して実行
  2. 出力欄で各インスタンスの適用状況を確認する

② AWS CLIから実行する手順

まずコマンドを送信します。

aws ssm send-command \
  --region ap-northeast-1 \
  --document-name "AWS-RunPowerShellScript" \
  --targets '[{"Key":"instanceids","Values":["i-xxxxxxxxxxxxxxxxx"]}]' \
  --parameters '{"commands":["Get-HotFix -Id KB5025885, KB5012170 | Select-Object HotFixID, InstalledOn | Format-Table -AutoSize"]}' \
  --output text \
  --query 'Command.CommandId'

返ってきた CommandId を使って結果を確認します。

aws ssm list-command-invocations \
  --region ap-northeast-1 \
  --command-id <CommandId> \
  --details \
  --query 'CommandInvocations[].[InstanceId,Status,CommandPlugins[0].Output]' \
  --output table

SSM利用の前提条件

  • 対象インスタンスに SSM Agent が導入・起動されていること
  • インスタンスのIAMロールに AmazonSSMManagedInstanceCore ポリシーが付与されていること
  • running状態のインスタンスのみ実行可能(stopped状態は不可)

パターン B:インスタンスに直接ログインして確認する

SSMが未導入の場合はRDPでログインし、PowerShellで以下を実行します。

Get-HotFix -Id KB5025885, KB5012170 | Select-Object HotFixID, InstalledOn

STEP 3:未適用インスタンスにパッチを適用する

SSMが導入済みの場合(running状態のインスタンス)

SSM Patch Managerを使って一括適用できます。

aws ssm send-command \
  --region ap-northeast-1 \
  --document-name "AWS-RunPatchBaseline" \
  --targets '[{"Key":"instanceids","Values":["i-xxxxxxxxxxxxxxxxx"]}]' \
  --parameters '{"Operation":["Install"]}' \
  --output text \
  --query 'Command.CommandId'

パッチ適用後の再起動は2026年6月の期限前に計画的に実施してください。

stopped状態のインスタンス

対応完了前に不用意に起動しないよう関係者に周知することが重要です。
次回起動前に必ずWindows Updateを適用してから本番利用するよう計画を立ててください。

SSMが未導入のインスタンス

RDPでログインしてWindows Updateを手動適用します。または先にSSM Agentを導入してから上記パターンAの手順で対応できます。

まとめ

今回の証明書更新対応をまとめると以下のとおりです。

  1. EC2の BootMode が uefi のWindowsインスタンスが対象
  2. 稼働中は影響なし・再起動・起動時にブート失敗リスクあり
  3. 2026年6月までに KB5025885 / KB5012170 を適用する
  4. SSM導入済みであればRun CommandやPatch Managerで効率よく対応できる

まずはAWS CLIでUEFIモードのインスタンスを洗い出すところから始めてみてください。台数が多い場合はSSM Patch Managerによる一括対応が効果的です。

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

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

参考

この記事をシェアする

関連記事