PCを起動するたびに、画面の裏で小さな問いかけが行われている。「このブートローダーは信頼できるか？」——Secure Bootはその問いを、暗号証明書の連鎖によって答え続けてきた。ところが今月末、その連鎖を支えてきた2011年発行の証明書が順次失効する。6月24日にはKey Exchange Key（KEK）CA 2011が、6月27日にはMicrosoft UEFI CA 2011が有効期限を迎える。
注意してほしいのは、これが「すぐにPCが起動しなくなる」事態ではないという点だ。現在動作している署名済みブートローダーはそのまま動き続ける。問題は将来にある。更新を怠ったシステムは、今後リリースされるUEFIレベルのセキュリティパッチや、新たな署名鍵で保護されたブートローダーを受け取れなくなる。Fedora Magazineが表現したように、「今後発見されるshimの脆弱性には新しい2023鍵でしかパッチを当てられない。古い鍵に依存しているシステムはそのパッチを受け取れない」のだ。
対象はWindowsとLinuxの双方にまたがる。Windows 10（バージョン1607〜22H2）、Windows 11（21H2〜24H2）、Windows Server 2012 ESU以降のすべてのエディションが影響を受ける。Linuxユーザーも無関係ではなく、ディストロの対応状況によっては手動での確認が必要になる。
Secure Bootの仕組み：PCはどうやってブートローダーを信頼するか
Secure Bootを理解するには、「信頼の連鎖」という概念から入るのが早い。
コンピュータの起動シーケンスは、UEFIファームウェアが最初に動き、そこからブートローダー（Windowsならbootmgr、LinuxならGRUB等）を読み込み、OSカーネルへと制御を移していく。各段階で「次に渡すプログラムは改ざんされていないか」を確認するのがSecure Bootの役割だ。
確認の仕組みは公開鍵暗号に基づく。ファームウェアはPlatform Key（PK）、Key Exchange Key（KEK）、データベース（db/dbx）という3層の鍵を持つ。PKはプラットフォーム全体の信頼の根、KEKはdbとdbxの更新権限を管理する鍵、dbは「起動を許可する署名」のリスト、dbxは「起動を拒否する署名（失効リスト）」のリストだ。
Microsoftが発行したKEK CA 2011とUEFI CA 2011は、ほぼ全世界のWindows搭載PCのファームウェアに書き込まれており、これらの鍵で署名されたソフトウェアだけが起動できる仕組みになっている。Linuxでは一段階複雑で、Microsoftが「shim」と呼ばれる小さなファーストステージブートローダーに署名し、shimが各ディストロのGRUBやカーネルに署名する連鎖構造を採る。
この証明書が失効すると何が変わるか。失効後も既存の署名済みブートローダーは動く。しかし「2023年発行の新しい証明書でのみ署名された」将来のブートローダーやパッチは、古いファームウェアでは認証を通過できなくなる。Microsoftはこの移行を「Windowsエコシステムにおける最大規模の協調セキュリティ保守作業の一つ」と位置づけている。
6月末の期限：失効する証明書と日付の整理
今回失効するのは4つの証明書だが、6月末に関わるのは主に3つだ。
6月24日失効: Microsoft Corporation KEK CA 2011。KEKはdbおよびdbxの更新権限を管理する鍵であり、これが失効すると古い鍵経由でのセキュリティデータベースの更新ができなくなる。
6月27日失効: Microsoft UEFI CA 2011およびMicrosoft Option ROM UEFI CA 2011。前者はUEFIアプリケーション・ドライバー全般の署名検証に使われ、Linuxのshimもこの鍵で署名されている。後者はグラフィックカード等のオプションROMを対象とする。
10月19日失効: Microsoft Windows Production PCA 2011。こちらはWindowsカーネルとドライバーの署名に使われる鍵で、6月の期限とは別に余裕がある。ただし放置すれば同様の問題が起きるため、見落とさないようにしたい。
情報ソースによって「6月27日」と統一して書かれているものもあるが、Microsoft公式ドキュメント（KB5062710）に従えばKEKとUEFI CAの日付は異なる。最も正確な参照先は https://aka.ms/GetSecureBoot のランディングページだ。
WindowsとLinuxそれぞれへの対応
Windows：自動更新の確認と企業向け手動展開
Windows 10・11の多くでは、2023年証明書への更新がすでに自動配信されている。確認方法は、「Windowsセキュリティ」→「デバイスセキュリティ」→「Secure Boot」で緑のチェックマークがついているかを見ることだ。
ただし注意点がある。古いOEMファームウェアが2023年証明書をサポートしていないケースが報告されており、その場合はOEMのファームウェアアップデートを別途適用した上で証明書更新を受け取る必要がある。自動更新されているように見えても、古い機種では確認の手間を惜しまないほうがいい。
企業環境で大量のマシンを管理する場合、Microsoft Intune（推奨）、グループポリシー、レジストリキー（UEFICA2023Status）、Windows Configuration System（WinCS）の4つの展開手段が用意されている。Windows ServerについてはTechCommunityに専用プレイブックが公開されており、サーバー管理者は https://techcommunity.microsoft.com/blog/windowsservernewsandbestpractices/windows-server-secure-boot-playbook-for-certificates-expiring-in-2026/4495789 を参照すること。
Linux：shimの署名が鍵を握る
Linuxの場合、対応の責任はMicrosoftではなく各ディストロ側にある。Microsoftがshimに新しい2023鍵で署名し、各ディストロがそのshimを配布するという流れだ。
RHEL 8・9・10: Red Hatは2025年10月から「デュアル署名」shimを提供開始した。2011鍵と2023鍵の両方で署名することで、ファームウェア側の証明書が古くても新しくても起動できる移行期の仕組みだ。RHEL 9.8以降・RHEL 10.2以降はすでに対応済みで、RHEL 8は2026年6月に対応予定。
Fedora: Fedora Rawhide（F45）はすでにデュアル署名shimを実装している。安定板の対応状況はFedora Magazineで確認できる。
RHEL 7.9: サポート終了が近い旧バージョンのため、デュアル署名shimを受け取れない。将来のshimが2023鍵のみで署名されるようになると、2023証明書がファームウェアに登録されていない機器では起動できなくなるリスクがある。このバージョンを使い続けているなら、移行の計画を立てるべきタイミングだ。
TPMを使っているLinuxユーザーへの注意: dbの更新によってTPMのPCR7（Platform Configuration Register 7）の値が変化する。Secure Boot測定値に依存した設定（FDEのUnlock設定等）を組んでいる場合は、更新後に再設定が必要になる可能性がある。Red Hatのブログで詳細が確認できる。
更新しないと何が起きるか：正確なリスクを理解する
「証明書が切れたらPCが起動しなくなる」という情報がネットに散見されるが、これは正確ではない。現時点で動作しているブートローダーは2011鍵で署名されており、証明書失効後もそのまま起動し続ける。
実際のリスクは「将来の保護を失う」という形で現れる。
具体的には2つの問題が生じる。第一に、将来リリースされる新しいShimやGRUBのアップデートが2023鍵でのみ署名されるようになった時点で、古いファームウェアではインストール・起動ができなくなる。第二に、Secure Boot失効リスト（dbx）の更新も受け取れなくなる。dbxは既知の脆弱なブートローダーのハッシュを登録して起動を拒否する仕組みで、これが更新されないことはUEFIブートキット対策に穴が開くことを意味する。
UEFIブートキットは現実の脅威だ。2018年にロシアのAPT28（Fancy Bear）が展開したLoJaxは、OSより先に起動するファームウェアレベルのマルウェアとして初めて実被害が確認された事例だ。その後もMosaicRegressor（2020年）、ESpecter、FinSpy、MoonBounceと被害事例が続いた。2023年にはBlackLotus（CVE-2023-24932）がSecure BootそのものをバイパスするブートキットとしてESETの調査で実証されている。
これらのマルウェアがOSインストール後も生き残れる理由は、OS再インストールでは消えないファームウェア領域に潜伏するためだ。Secure BootのDBX更新を受け取れない状態は、既知の脆弱なブートローダーを使った攻撃の入口を開けたままにしておくことに等しい。
今後の展望と業界への示唆
今回の証明書更新を加速させた要因の一つにLogoFAIL（2023年12月開示）がある。UEFIのロゴ表示用画像パーサーに潜んでいた脆弱性で、AMI・Insyde・Phoenix製のファームウェア、つまり世界中のほぼ全PCに影響した。Secure Bootをバイパスしてファームウェアに悪意あるコードを埋め込めるこの脆弱性は、Linuxに対する初のUEFIブートキット「Bookkitty」の展開にも悪用されたことが後に判明している。
ただしLogoFAILは「証明書更新の唯一の原因」ではない。Microsoft Corporation KEK CA 2011とMicrosoft UEFI CA 2011はもともと2026年に有効期限が切れる設計で発行されており、今回の移行は15年前から予定されていた定期刷新だ。LogoFAILはその必要性を業界に強く意識させた出来事として位置づけるのが正確だ。
業界規模で見ると、この移行が完全に普及するまでには時間がかかる。問題は特に古いOEMファームウェアを搭載した機器で顕在化する。新証明書をサポートしないファームウェアのアップデートをOEMが提供しなければ、その機器は事実上、将来のUEFIセキュリティパッチの対象外になる。法人・教育・医療機関のような長期運用を前提とした環境では、機器の世代交代とセキュリティ保護のタイムラインが噛み合わなくなるリスクがある。
Microsoftが今回この作業を「最大規模の協調セキュリティ保守作業」と呼んだのは、証明書の更新だけでなく、OEM・ディストロ・企業IT・エンドユーザーが同時に動かなければ完結しないエコシステム全体の調整を指している。個人ユーザーが今できることはまず自分のシステムの確認から始めることだ——Windowsなら「デバイスセキュリティ」、LinuxならディストロのShimバージョン確認、そして企業管理者ならKB5062710の展開状況の監査を、期限の6月24日前に済ませておきたい。
