Secure Bootの証明書期限が過ぎたあとの点検 ── Windows UEFI CA 2023への移行を確かめる

2026年10月19日、Windowsのブートマネージャーに署名してきた証明書「Microsoft Windows Production PCA 2011」が期限を迎えました。6月に期限を迎えた2つの証明書に続く、2011年版の最後の1つです。

期限を過ぎても、PCはこれまでどおり起動します。困るのは何も壊れないので更新の漏れに気づきにくいことです。2023年版の証明書をファームウェアに持たないPCには、ブートマネージャーの新しいセキュリティ修正が届きません。将来2011年版の証明書が無効化リストに入れば、そのPCは古い署名のブートマネージャーで起動できなくなります。

この記事では、業務で使うWindows PCとサーバーが2023年版の証明書に移行済みかを確かめる方法と、移行していないPCを更新する手順を説明します。対象はWindows 11、ESUを適用したWindows 10、Windows Server 2019以降です。仮想マシンとApp Control for Businessの注意も扱います。

コマンド、レジストリ値、イベントIDは、2026年10月30日に確認したMicrosoftの公開文書に基づきます。筆者の環境で実行した結果ではないので、実際の出力は手元のPCで確かめてください。

期限を迎えた3つの証明書

Secure Bootは、ファームウェアが起動の途中で読み込むプログラムの署名を確かめる仕組みです。署名を確かめる基準はファームウェアの中の次の3つの領域に入っています。

• KEK: dbとDBXを書き換える更新に署名する鍵です。
• db: 起動を許す署名者の一覧です。
• DBX: 起動を禁じる署名者やプログラムの一覧です。

期限と後継の一覧によると、2011年版の3つの証明書の期限と入っている領域、後継は次のとおりです。

Microsoft UEFI CA 2011の後継は、オプションROMを信頼する必要があるPCでも他社製のブートローダーまで信頼を広げずに済むよう、2つに分かれました。

flowchart TB
        accTitle: Secure Bootの3つの領域と2023年版の証明書
        accDescr: KEKがdbとDBXの更新に署名し、dbの証明書がブートマネージャーと他社製の起動プログラムの署名を確かめる関係を示す。
        KEK["KEK（KEK 2K CA 2023）"] -->|"更新に署名"| DB["db（起動を許す一覧）"]
        KEK -->|"更新に署名"| DBX["DBX（起動を禁じる一覧）"]
        DB --> WIN["Windows UEFI CA 2023"]
        DB --> UEFI["Microsoft UEFI CA 2023"]
        DB --> OROM["Option ROM UEFI CA 2023"]
        WIN -->|"署名を確かめる"| BM["Windowsブートマネージャー"]
        UEFI -->|"署名を確かめる"| TP["他社製のブートローダー"]
        OROM -->|"署名を確かめる"| OR["オプションROM"]

図1: KEKはdbとDBXの更新に署名し、dbに入った証明書が起動するプログラムの署名を確かめる。

Windows Production PCA 2011はブートローダーだけでなく、Windowsのバイナリとセキュリティカタログの署名にも使われていました。KB5132953によると、Microsoftは2026年10月19日以降、この証明書でバイナリにもセキュリティカタログにも署名していません。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全27件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

期限後も起動する理由と届かなくなる修正

Microsoftは今回の期限切れでPCの電源が入らなくなったり、Windowsが起動しなくなったりはしないと説明しています。2011年版の証明書で署名済みのプログラムは、dbに2011年版の証明書が残っているPCでは信頼されたままです。

変わるのはこれから出る修正です。2011年版の証明書で署名した最後のWindowsブートマネージャーはそのままの形で固定され、今後は修正もセキュリティパッチも出ません。以後のブートローダーの修正はWindows UEFI CA 2023の系列だけで署名されます。

期限切れの影響の説明には、2023年版の証明書がないPCに起きることが次のように書かれています。

• 新しいSecure Bootとブートマネージャーの保護を適用できない。
• BitLockerの回避への対策やSecure Bootの無効化リストの更新など、起動の初期段階の脆弱性の修正が届かない。

flowchart TB
        accTitle: dbに2023年版の証明書があるかで変わる起動と修正
        accDescr: dbにWindows UEFI CA 2023があれば新しいブートマネージャーと修正を受け取れ、なければ固定された2011年版のブートマネージャーで起動を続けることを示す。
        Q{"dbにWindows UEFI CA 2023があるか"}
        Q -->|"ある"| A["2023年版のブートマネージャーで起動"]
        A --> A2["起動部分の修正を受け取れる"]
        Q -->|"ない"| B["固定された2011年版で起動"]
        B --> B2["起動部分の修正が届かない"]
        B --> B3["今後のメディアの起動に失敗する"]

図2: dbにWindows UEFI CA 2023がないPCは起動を続けるが、起動部分の修正を受け取れない。

今後の大型リリースのWindowsは、インストールメディアから起動してセットアップを終えるのに、dbにWindows UEFI CA 2023があることを必要とします。Microsoftが配るインストールメディアも、今後は2023年版で署名したブートマネージャーで起動するように変わります。dbに2023年版の証明書がないPCでこのメディアを起動すると、Secure Bootの違反で失敗します。そうしたPCのために、メディアを2011年版のブートマネージャーで起動させるスクリプトを提供するとMicrosoftは予告しています。

もう一つの予定は2011年版の証明書の無効化です。KB5025885によると、Windows Production PCA 2011は将来、対応するPCでDBXに追加されて無効化され、利用者はこれを止められません。この段階の日付はまだ発表されておらず、Microsoftは始まる少なくとも6か月前に告知するとしています。DBXに追加されたあとは、2011年版の署名しかないブートマネージャーではそのPCを起動できません。

flowchart TB
        accTitle: 2011年版の証明書の期限と今後の予定
        accDescr: 2026年6月24日と6月27日と10月19日に3つの証明書が期限を迎え、その後に日付未発表のDBXによる無効化が続くことを示す。
        D1["2026年6月24日 KEK CA 2011の期限"] --> D2["2026年6月27日 UEFI CA 2011の期限"]
        D2 --> D3["2026年10月19日 PCA 2011の期限"]
        D3 --> D4["日付未発表 PCA 2011をDBXに追加"]
        D4 --> D5["2011年版の署名では起動できない"]

図3: 3つの証明書は2026年に期限を迎え、DBXによる無効化は日付が発表されていない。

期限が過ぎたあとでも、更新は間に合います。MicrosoftのFAQは、新しい証明書を含む累積更新は既存の証明書が期限切れでも適用できると説明しています。Windowsが起動して更新を入れられるPCなら、公開された手順で証明書をファームウェアに書き込めます。

自社のPCが移行済みか確かめる

確かめる順序は次のとおりです。PowerShellは管理者として実行します。

flowchart TB
        accTitle: Secure Bootの証明書の移行を確かめる順序
        accDescr: Secure Bootの有効化、dbのWindows UEFI CA 2023、UEFICA2023Statusの値の順に確かめ、途中で止まったらイベントログを見ることを示す。
        S1{"Confirm-SecureBootUEFIはTrueか"} -->|"False"| N1["無効のままでは証明書が届かない"]
        S1 -->|"True"| S2{"dbにWindows UEFI CA 2023はあるか"}
        S2 -->|"ない"| N2["更新が始まっていないか止まっている"]
        S2 -->|"ある"| S3{"UEFICA2023StatusはUpdatedか"}
        S3 -->|"Updated"| OK["移行済み"]
        S3 -->|"NotStarted か InProgress"| N3["イベントログで止まった段階を見る"]
        N2 --> N3

図4: Secure Bootの有効化、db、更新の状態の順に確かめ、止まっていればイベントログを見る。

Secure Bootが有効か

まず、Secure Bootが有効になっているかを確かめます。Trueが返れば有効です。

Confirm-SecureBootUEFI

Secure Bootが無効のPCには新しい証明書がファームウェアに書き込まれません。FAQは、そのようなPCは起動時に動くマルウェアに対して無防備なままになると説明しています。無効のPCを見つけたら、BitLockerの回復キーの保管先を確かめたうえで、有効にするかどうかを判断してください。Secure Bootの設定を変えるとBitLockerが回復モードに入ることがある理由は、TPMの記事で説明しています。

dbにWindows UEFI CA 2023があるか

次に、dbにWindows UEFI CA 2023が入っているかを確かめます。KB5025885が示しているコマンドで、Trueが返れば入っています。

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'

2026年4月14日以降の月例の累積更新を入れたPCでは、Get-SecureBootUEFI に -Decoded パラメーターを付けられます。Decodedパラメーターの説明によると、証明書の名前と有効期限が読める形で表示されます。

Get-SecureBootUEFI -Name db -Decoded

出力の Subject に CN=Windows UEFI CA 2023 があれば、dbに2023年版の証明書が入っています。CN=Microsoft Windows Production PCA 2011 の ValidTo は 2026-10-19 11:51:42Z です。2011年版の証明書がdbに残っていること自体は、異常ではありません。

更新が最後まで済んだか

dbに証明書が入っても、KEKの更新とブートマネージャーの入れ替えが残っていることがあります。全体が済んだかは、レジストリの UEFICA2023Status で確かめます。

(Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing").UEFICA2023Status

レジストリの説明によると、値は次のように変わります。

• NotStarted: 更新がまだ動いていない。
• InProgress: 更新が進んでいる。
• Updated: 新しい鍵とブートマネージャーがすべて入った。

エラーが起きると UEFICA2023Error に0以外のコードが入り、状態はInProgressのまま残ります。同じキーにある WindowsUEFICA2023Capable は参考の値で、Microsoftは状態の確認に使わず UEFICA2023Status を使うよう明記しています。

flowchart TB
        accTitle: UEFICA2023Statusの値の変わり方
        accDescr: UEFICA2023StatusがNotStartedからInProgressを経てUpdatedに変わり、エラーのときはInProgressのままUEFICA2023Errorにコードが入ることを示す。
        NS["NotStarted（まだ動いていない）"] --> IP["InProgress（進んでいる）"]
        IP --> UP["Updated（すべて入った）"]
        IP -->|"エラーが起きた"| ER["UEFICA2023Errorにコードが入る"]

図5: UEFICA2023StatusはNotStarted、InProgress、Updatedの順に変わり、エラーのときはInProgressで止まる。

イベントログで止まった段階を見る

更新の進み具合はSystemログにソース「TPM-WMI」のイベントとして記録されます。イベントの一覧のうち、点検でよく見るものは次のとおりです。

次のコマンドはこれらのイベントを新しい順に表示します。

Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 1795, 1799, 1800, 1801, 1803, 1808 } -MaxEvents 20 |
    Where-Object ProviderName -like '*TPM-WMI*' |
    Select-Object TimeCreated, Id, Message

1808が出ていれば、そのPCは更新を終えています。1801、1795、1803が出ているときの対処は、後の「更新が進まないとき」で説明します。

Windowsセキュリティの表示

Windowsセキュリティの「デバイス セキュリティ」にも、Secure Bootの証明書の状態が出ます。ただしMicrosoftは緑のチェックだけでは証明書が更新済みとは言えないとしています。「Secure Boot is on and all required certificate updates have been applied.」の文言が出ているかも確かめてください。

組織が管理するWindows 10、Windows 11、Windows Serverでは、Secure Bootの証明書についての通知とバッジが既定で出ません。管理者は HideSecureBootStates を0にすると表示できます。台数が多い場合は、各PCの画面を見て回るより、UEFICA2023Status とイベントを集めるほうが確かです。

移行していないPCを更新する

更新の作業はBitLockerの回復キーを確かめるところから始めます。

先にBitLockerの回復キーを確かめる

KB5132953はブートの経路、ファームウェア、Secure Bootに関わる更新を入れる前に、BitLockerの回復キーを安全な場所に控えておくよう求めています。月例の品質更新もこれに含まれます。KB5025885は次のコマンドを管理者として実行し、表示される48桁の回復パスワードを控えるよう案内しています。

manage-bde -protectors -get $env:SystemDrive

manage-bdeの説明によると、-get はドライブで有効な保護方法を一覧し、その種類とIDを表示します。表示されるのはそのPCの中の情報なので、PCの外に控えがあるかはこのコマンドでは分かりません。組織で保管している控えがあれば、そのIDが表示されたIDと一致し、取り出せることを確かめてください。控えがなければ、表示された回復パスワードを安全な場所に保管してから更新してください。

トラブルシューティングガイドは、Secure Bootの更新のあとにBitLockerが回復モードに入る場合を2つ挙げています。

1. 更新後の最初の起動だけ回復モードに入る。ファームウェアが新しい値をまだ報告せず、BitLockerが鍵を封印し直せないことが原因で、次の起動からは通常どおり起動する。
2. 起動のたびに回復モードに入る。ネットワークブート(PXE)を先に試す設定のPCで起きる。PXEの経路はMicrosoft UEFI CA 2011で署名されているためで、PXEが要らなければ無効にし、必要なら2023年版で署名したWindowsのブートローダーをPXEの基盤で使う。

flowchart TB
        accTitle: Secure Bootの更新後にBitLockerが回復モードに入る2つの場合
        accDescr: 更新後の最初の起動だけ回復モードに入る場合と、PXEを先に試す設定で毎回回復モードに入る場合の、原因と対処を示す。
        R{"回復モードに入るのは"}
        R -->|"更新後の最初の起動だけ"| R1["ファームウェアが新しい値を未報告"]
        R1 --> R1A["回復キーで解除すれば次から通常起動"]
        R -->|"起動のたびに"| R2["PXEがUEFI CA 2011の経路を通る"]
        R2 --> R2A["PXEが不要なら無効にする"]
        R2 --> R2B["PXEで2023年版のローダーを使う"]

図6: 最初の起動だけの回復は一度で済み、毎回の回復はPXEの設定を見直す。

回復キーの探し方と管理の方法は、BitLocker実務ガイドで説明しています。

Windows Updateに任せる場合

多くのPCには、証明書の更新が月例の累積更新で自動的に届きます。Microsoftはこれまでに集まった診断データから「high confidence」と判断したPCのグループを、月例の更新の対象に自動で含めることがあります。この経路は既定で有効で、診断データを送る設定がなくても働きます。10月の累積更新もこの対象の判定を新しくしながら配布を続けています。

実際に証明書を書き込むのはスケジュールタスク \Microsoft\Windows\PI\Secure-Boot-Update です。このタスクはSYSTEMとして、起動時と12時間ごとに動きます。タスクを無効にしたり消したりしたPCには、証明書の更新を適用できません。

更新を始めること自体ではPCは再起動しません。再起動が必要な段階では、利用者がふだんの使い方で再起動するのを待ちます。ブートマネージャーの入れ替えは再起動が済むまで行われないことがあります。

Microsoftは、この自動の配布は手助けであって保証ではなく、すべてのPCの更新を確かめる責任は管理者にあると明記しています。自動に任せる場合も、前の節の確認で全台の状態を集めてください。

管理者が配布を指示する場合

自動の対象に入っていないPCには、管理者が更新を指示できます。1台で試すときは、レジストリの AvailableUpdates に0x5944を書き、タスクをすぐに動かします。

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

値はすぐに0x4100に変わります。そこでPCを再起動し、もう一度タスクを動かすと、ブートマネージャーが入れ替わって値が0x4000になります。0x4000は残る値で、更新がすべて終わったことを表します。

0x5944の各ビットはタスクが処理するたびに1つずつ消えます。トラブルシューティングガイドによると、順序と記録されるイベントは次のとおりです。

flowchart TB
        accTitle: AvailableUpdatesの値が0x5944から0x4000に変わる順序
        accDescr: dbへのWindows UEFI CA 2023の追加から始まり、Option ROMとUEFI CA 2023、KEK、ブートマネージャーの順に処理されて値が0x4000になることを示す。
        V0["0x5944（更新を指示）"] -->|"Windows UEFI CA 2023を追加（1036）"| V1["0x5904"]
        V1 -->|"Option ROM UEFI CA 2023（1044）"| V2["0x5104"]
        V2 -->|"Microsoft UEFI CA 2023（1045）"| V3["0x4104"]
        V3 -->|"KEKを更新（1043）"| V4["0x4100（ここで再起動）"]
        V4 -->|"ブートマネージャーを入れ替え（1799）"| V5["0x4000（すべて完了）"]

図7: AvailableUpdatesのビットは、db、KEK、ブートマネージャーの順に処理されて消える。括弧内は成功時のイベントID。

0x4000のビットはMicrosoft UEFI CA 2023とOption ROM UEFI CA 2023の追加に条件を付けます。この2つはdbにMicrosoft UEFI CA 2011がすでにあるPCにだけ追加されます。

台数が多い場合は、同じ指示をグループポリシーかIntuneで配ります。

• グループポリシー: 「コンピューターの構成」の「管理用テンプレート」から「Windows コンポーネント」の「Secure Boot」を開き、「Enable Secure Boot Certificate Deployment」を設定します。管理用テンプレートはMicrosoftの配布サイトから最新のものを入れておく必要があります。
• Intune: 設定カタログの「Enable Secureboot Certificate Updates」で配ります。high confidenceの自動配布から外す「Configure High Confidence Opt-Out」も、同じ設定カタログにあります。

flowchart TB
        accTitle: 証明書の更新を指示する経路
        accDescr: 月例の累積更新、グループポリシー、Intune、レジストリの直接の書き込みのどれで指示しても、Secure-Boot-Updateタスクが証明書をファームウェアに書き込むことを示す。
        P1["月例の累積更新"] --> T["Secure-Boot-Updateタスク"]
        P2["グループポリシー"] --> T
        P3["Intuneの設定カタログ"] --> T
        P4["AvailableUpdatesに0x5944"] --> T
        T --> F["dbとKEKに証明書を書き込む"]
        T --> BM["ブートマネージャーを入れ替える"]

図8: どの経路で指示しても、証明書を書き込むのはSecure-Boot-Updateタスクである。

更新が進まないとき

イベントログに出たIDで、次にすることが変わります。

• 1800が出ているときは、再起動すると更新が続きます。
• 1801が出ているときは、証明書がまだファームウェアに適用されていません。イベントの文言どおり、公開された手順を確かめて適用を完了させます。
• 1795が出ているときは、ファームウェアがエラーを返しています。イベントに入っているエラーコードを控え、メーカーのファームウェア更新を確かめます。
• 1803が出ているときは、このPCにはPKで署名されたKEKがありません。イベントの文言どおり、鍵の用意をメーカーに問い合わせます。メーカーがもう鍵やファームウェアを出していない古いPCには、サポートされた手動の回復手段がありません。

KEKを更新できない場合でも、タスクはブートマネージャーの入れ替えを続けます。そのため、1803が出ていてもブートマネージャーは2023年版になっていることがあります。

flowchart TB
        accTitle: 更新が進まないときのイベントIDと次の対処
        accDescr: イベント1800なら再起動し、1801なら公開された手順で適用を完了させ、1795ならファームウェア更新を確かめ、1803ならメーカーに問い合わせることを示す。
        E{"出ているイベントID"}
        E -->|"1800"| A1["再起動する"]
        E -->|"1801"| A2["公開の手順で適用を完了"]
        E -->|"1795"| A3["ファームウェア更新を確かめる"]
        E -->|"1803"| A4["鍵をメーカーに問い合わせる"]

図9: 更新が進まないときは、出ているイベントIDで対処を選ぶ。

ファームウェアの不具合にも注意が要ります。トラブルシューティングガイドによると、一部のファームウェアは新しい証明書をdbに追加せず、dbを上書きしてしまいます。また、証明書を更新したあとにファームウェアの設定でSecure Bootの鍵を工場出荷時の値に戻すと、PCが起動できなくなることがあります。その場合は、2024年7月以降の更新を入れた別のPCの C:\Windows\Boot\EFI\ から SecureBootRecovery.efi を取り出して使います。手順はトラブルシューティングガイドにあります。

更新がうまくいかないからといって、Secure Bootを無効にしてはいけません。Microsoftは証明書の期限への対処としてSecure Bootを無効にしてはならないと明記しています。無効にすると起動時に動くマルウェアへの守りがなくなり、そのPCには新しい証明書も届きません。

業務環境で影響が出やすいところ

一般のPCより確かめることが多いのは、App Control for Businessを使う環境、仮想マシン、古いOS、PXEやLinuxを使う環境です。

App Control for Businessのポリシー

App Control for Business(旧WDAC)のポリシーに、Microsoftが署名したコードを特定の認証局や拇印で許可する規則があるときは注意が要ります。Windows Production PCA 2011を名指しした規則がその例です。KB5132953によると、更新後のWindowsのバイナリとセキュリティカタログは別の認証局で署名されているので、こうした規則に合わず、強制モードではブロックされることがあります。

起きうる症状として、累積更新が入らない、起動時にサービスが失敗する、実行ファイルやDLLがブロックされる、コード整合性のイベント3077が出る、が挙げられています。ポリシーのXMLでMicrosoftの認証局を指す署名者の規則を探し、変更はまず監査モードで配って結果を確かめてから強制にしてください。ポリシーの作り方はAppLockerとApp Control for Businessの記事で説明しています。

flowchart TB
        accTitle: App Control for Businessの規則と更新後のバイナリ
        accDescr: 更新後のバイナリは別の認証局で署名されるため、PCA 2011を名指しした規則に合わず強制モードでブロックされることと、規則を探して監査モードで確かめる対処を示す。
        U["更新後のWindowsのバイナリ"] --> C["PCA 2011とは別の認証局で署名"]
        C --> R{"PCA 2011を名指しした規則があるか"}
        R -->|"ある"| B["強制モードでブロックされうる"]
        B --> F1["ポリシーのXMLで規則を探す"]
        F1 --> F2["監査モードで配って確かめる"]
        F2 --> F3["結果を見てから強制にする"]
        R -->|"ない"| OK["この規則による影響はない"]

図10: PCA 2011を名指しした規則は更新後のバイナリに合わないので、監査モードで確かめてから直す。

仮想マシン

KB5132953によると、第2世代のHyper-V仮想マシンには、通常の累積更新で新しい証明書が届きます。ただしトラブルシューティングガイドはHyper-Vの仮想マシンで証明書を更新するには、ホストとゲストの両方に2026年3月の更新が必要だとしています。ゲストに出たイベントで、どちらを更新すればよいかが分かります。

• ゲストに1795(「The media is write-protected」など)が出たときは、Hyper-Vのホストに3月の更新が入っていません。
• ゲストに1803が出たときは、ゲスト自身に3月の更新が入っていません。

flowchart TB
        accTitle: Hyper-Vの仮想マシンでKEKの更新に失敗したときの切り分け
        accDescr: ゲストにイベント1795が出たらHyper-Vホストを、1803が出たらゲストを2026年3月の更新まで上げることを示す。
        G{"ゲストに出たイベント"}
        G -->|"1795"| H["ホストに2026年3月の更新を入れる"]
        G -->|"1803"| V["ゲストに2026年3月の更新を入れる"]

図11: Hyper-Vのゲストに出たイベントIDで、更新するのがホストかゲストかが分かる。

VMware vSphereでは、ESXiのホストと仮想マシンのハードウェアバージョンを、ゲストのUEFIの雛形に2023年版の証明書を含む版に上げるようKB5132953は案内しています。Azure Trusted Launchの仮想マシンでは、イベント1795が出る既知の問題があり、Microsoftは利用者の対応は不要としています。

Windows 10とサポート外のOS

FAQによると、新しい証明書を受け取れるのはサポート中のWindowsだけです。KB5132953の対象にはWindows 10 ESUとWindows 10 LTSB 2016 ESUが含まれています。ESUを適用していないWindows 10のPCは、この経路では証明書を受け取れません。Windows 10を使い続けるかどうかの判断は、Windows 10のサポート終了後の記事で扱っています。

インストールメディアとPXE

前に説明したとおり、今後のインストールメディアは2023年版で署名したブートマネージャーで起動します。社内でキッティング用のUSBメディアやPXEの配布基盤を持っている場合は、配る先のPCのdbにWindows UEFI CA 2023が入っているかを先に確かめてください。BitLockerの節で見たとおり、PXEの経路にMicrosoft UEFI CA 2011で署名したローダーが残っていると、回復モードが繰り返される原因にもなります。

Linuxと他社製のブートローダー

Microsoftのハードウェア開発者向けの告知によると、Microsoft UEFI CA 2011の期限が来ても、すでに署名されたバイナリは無効になりません。dbに2011年版の証明書が残っているPCでは、それまでどおり信頼されます。一方で、2026年6月26日以降にMicrosoftが署名して返すバイナリは、2023年版のUEFI CAで署名されたものだけです。

AzureのLinux仮想マシンについては、Linux on Azureの案内によると、2023年版の証明書がない仮想マシンも起動を続けますが、shimの更新や今後の証明書と無効化リストは受け取れません。

flowchart TB
        accTitle: Microsoft UEFI CA 2011で署名済みのバイナリの扱い
        accDescr: 署名済みのバイナリはdbに2011年版の証明書があれば信頼されたままで、2026年6月26日以降にMicrosoftが返す署名は2023年版だけであることを示す。
        S["UEFI CA 2011で署名済みのバイナリ"] --> Q{"dbにUEFI CA 2011があるか"}
        Q -->|"ある"| T["それまでどおり信頼される"]
        N["2026年6月26日以降の署名"] --> N2["2023年版のUEFI CAだけで署名"]
        T --> L["shimなどの新しい修正は2023年版で届く"]
        N2 --> L

図12: 2011年版で署名済みのバイナリは信頼されたままだが、新しい署名は2023年版だけになる。

関連記事

• WindowsのTPMとは何か
• BitLocker実務ガイド
• Windows 10サポート終了後の現実解

参考資料

Microsoftのサポート文書を2026年10月30日に確認しました。証明書の更新の手順は改訂が続いているので、作業の前に最新の版を確かめてください。

• Microsoft Support, Windows Production CA 2011 expiration and bootloader updates (KB5132953)。10月19日の期限の影響、ブートマネージャーの固定、インストールメディア、App Controlと仮想マシンの注意。
• Microsoft Support, Windows Secure Boot certificate expiration and CA updates。3つの証明書の期限、入っている領域、後継の証明書。
• Microsoft Support, When Secure Boot certificates expire on Windows devices。期限後に届かなくなる保護と、Secure Bootを無効にしてはならないという注意。
• Microsoft Support, Frequently asked questions about the Secure Boot update process。期限後の適用、サポート中のOSだけに届くこと、自動配布が保証ではないこと。
• Microsoft Support, KB5025885: How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932。dbの確認コマンド、UEFICA2023Statusの確認、DBXによる無効化の予定。
• Microsoft Learn, manage-bde protectors。-get が保護方法の種類とIDを表示すること。
• Microsoft Support, Registry key updates for Secure Boot: Windows devices with IT-managed updates。AvailableUpdates、UEFICA2023Status、手動で試す手順、再起動の扱い。
• Microsoft Support, Secure Boot troubleshooting guide。AvailableUpdatesのビットの順序、BitLockerの回復、KEKとファームウェアの問題、Hyper-Vの切り分け。
• Microsoft Support, Secure Boot DB and DBX variable update events (KB5016061)。TPM-WMIのイベントIDの意味。
• Microsoft Support, Using the -Decoded parameter in Get-SecureBootUEFI。dbの証明書を読める形で表示するパラメーター。
• Microsoft Support, Secure Boot certificate update status in the Windows Security app。Windowsセキュリティの表示と、緑のチェックだけでは足りないという注意。
• Microsoft Support, Secure Boot certificate updates: Guidance for IT professionals and organizations。Secure Bootの有効化の確認と、high confidenceの自動配布。
• Microsoft Support, Group Policy Objects (GPO) method of Secure Boot for Windows devices with IT-managed updates。グループポリシーの設定の場所と名前。
• Microsoft Support, Microsoft Intune method of Secure Boot for Windows devices with IT-managed updates。Intuneの設定カタログの項目。
• Microsoft Tech Community, Signing with the new 2023 Microsoft UEFI certificates: What submitters need to know。署名済みのバイナリの扱いと、2026年6月26日以降の署名。
• Microsoft Support, Secure Boot certificate updates for Linux on Azure virtual machines。AzureのLinux仮想マシンでの影響。

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

Secure Bootの証明書が期限切れになると、PCは起動しなくなりますか？

起動します。Microsoftは期限切れでPCの電源が入らなくなったりWindowsが起動しなくなったりはしないと説明しています。ただし、2023年版の証明書がないPCには、起動部分の新しいセキュリティ修正が届きません。

期限が過ぎたあとでも、2023年版の証明書を入れられますか？

入れられます。新しい証明書を含む累積更新は既存の証明書が期限切れになっていても適用できるとMicrosoftは説明しています。Windowsが起動して更新を入れられるPCなら、公開された手順で証明書をファームウェアに書き込めます。

Windowsセキュリティに緑のチェックが出ていれば更新済みですか？

それだけでは確かめられません。Microsoftは緑のチェックだけでは証明書が更新済みとは言えず、「Secure Boot is on and all required certificate updates have been applied.」の文言も確かめるよう案内しています。管理するPCでは、レジストリのUEFICA2023StatusがUpdatedになっているかも確認してください。

証明書の更新がうまくいかないとき、Secure Bootを無効にすればよいですか？

無効にしないでください。Microsoftは証明書の期限への対処としてSecure Bootを無効にしてはならないと明記しています。Secure Bootが無効のPCには新しい証明書が届かず、起動時に動くマルウェアへの守りもなくなります。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。