こんにちは、インフラエンジニアのryuです。
2026年10月19日に、Secure Bootで使われてきたMicrosoftの証明書のうち、最後の1枚が有効期限を迎えます。
6月にも同じ話題がありましたが、そのときに期限が来たのは別の証明書でした。10月に期限が来るのは、Windowsのブートマネージャーの署名に使われてきた Windows Production PCA 2011 です。
「6月に何も起きなかったから大丈夫」と思っている方もいるかもしれません。たしかに、期限が来たその日にサーバーが起動しなくなるわけではありません。
ただ、Windows Serverについては、PCと違って新しい証明書が自動では入らないとMicrosoftが案内しています。この記事では、何が期限切れになるのか、サーバーで何を確認すればいいのかを、WindowsとLinuxに分けて整理します。
Secure Bootの証明書とは？¶
最初に、Secure Bootの仕組みを簡単に確認しておきます。
Secure Bootは、PCやサーバーの電源を入れてからOSが起動するまでの間に、署名の確認されていないプログラムが動かないようにするUEFIの機能です。ブートローダーやドライバーなどが、信頼された証明書で署名されているかをファームウェアが確かめてから実行します。
この確認に使う証明書は、ファームウェアの中の決まった場所（UEFI変数）に保存されています。
| 名前 | 役割 |
|---|---|
| PK（Platform Key） | いちばん上の鍵。通常はPCやサーバーのメーカーが持つ |
| KEK（Key Exchange Key） | db・dbxを更新するときの署名の確認に使う |
| db | 起動してよいプログラムの署名の証明書を入れておく場所 |
| dbx | 失効させた署名や証明書を入れておく場所 |
Windowsの機器には、2011年に発行されたMicrosoftの証明書がKEKとdbに入っています。HTTPSのサーバー証明書と同じで、これらの証明書にも有効期限があります。
サーバー証明書の仕組みそのものは『サーバー証明書とは？』で解説しています。Secure Bootの証明書も、署名を確かめるための証明書という点では同じ考え方です。
期限が来る3つの証明書と、10月19日の意味¶
2011年の証明書は3つあり、それぞれ期限が違います。MicrosoftとRed Hatの案内をもとに、期限と後継の証明書を表にまとめました。
| 2011年の証明書 | 保存場所 | 期限 | 後継の2023年の証明書 |
|---|---|---|---|
| Microsoft Corporation KEK CA 2011 | KEK | 2026年6月24日 | Microsoft Corporation KEK 2K CA 2023 |
| Microsoft UEFI CA 2011 | db | 2026年6月27日 | Microsoft UEFI CA 2023 ／ Microsoft Option ROM UEFI CA 2023 |
| Microsoft Windows Production PCA 2011 | db | 2026年10月19日 | Windows UEFI CA 2023 |
Microsoft UEFI CA 2011 は、Linuxのshimや、拡張カードのオプションROMなど、Microsoft以外のプログラムの署名に使われてきた証明書です。10月19日に期限が来る Windows Production PCA 2011 は、Windowsのブートマネージャーの署名に使われています。
期限が来ると、すぐに起動しなくなるのか¶
すぐに起動しなくなるわけではありません。
Microsoftは、2023年の証明書が入っていない機器も通常どおり起動し、Windows Updateも引き続き入ると説明しています。ファームウェアは起動のたびに証明書の期限を確かめているわけではないからです。
困るのは、起動の仕組みに関わる今後のセキュリティ更新を受け取れなくなることです。 ブートマネージャーの更新、dbxへの失効情報の追加、起動処理の脆弱性の修正などは、2023年の証明書が入っていることが前提になっていきます。
新しいメディアで起動したときに差が出る¶
もう1つ気をつけたいのは、新しく署名されたプログラムで起動するときです。
2011年の証明書で新しく署名することは、もうできません。今後リリースされるブートマネージャーやshimは、2023年の証明書だけで署名されたものに変わっていきます。そうなると、dbに2023年の証明書が入っていない古い機器では、新しいインストールメディアや更新後のブートローダーが起動できない、ということが起こりえます。
今すぐ止まるわけではないものの、放っておくと何年か後に、復旧や再インストールのときに困るタイプの問題です。
Windows Serverは自動で更新されない¶
ここが今回いちばん大事なところです。
WindowsのPCには、Windows Updateを通じて2023年の証明書が段階的に配られてきました。一方でMicrosoftのWindows Serverブログは、Windows Serverにはこの段階的な配布（Controlled Feature Rollout）が行われないため、Secure Bootが有効なサーバーでは管理者が更新を始める必要があると案内しています。
また、Windowsセキュリティアプリで証明書の状態を表示する機能も、Windows Serverや企業で管理されている端末では既定で無効です。サーバーの画面に通知が出るのを待っていても、何も表示されません。
状態をレジストリで確認する¶
まずは、2023年の証明書がすでに入っているかを確認します。Microsoftの案内では、次のレジストリの値で更新の状態を見ることになっています。
# 更新の状態（Updated / InProgress / NotStarted など）
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" |
Select-Object UEFICA2023Status, UEFICA2023Error
# db に Windows UEFI CA 2023 が入っているか（True なら入っている）
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
# KEK に 2023年の証明書が入っているか
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).bytes) -match 'Microsoft Corporation KEK 2K CA 2023'
コマンドは管理者権限のPowerShellで実行します。Get-SecureBootUEFI を使う確認方法は、ASUSやDellのサポートページでも紹介されています。
Microsoftは、WindowsUEFICA2023Capable という別の値は参考情報であり、状態の確認には UEFICA2023Status を使うよう書いています。古い手順書を見て作業する場合は、この点に注意してください。
更新を始める前にやっておくこと¶
状態が NotStarted のサーバーは、更新を始める前にいくつか確認しておきます。
| 確認すること | 理由 |
|---|---|
| 最新の累積更新プログラムを入れているか | 証明書を更新する仕組みは累積更新に含まれている |
| メーカーのファームウェア（BIOS/UEFI）の更新が出ていないか | 機種によっては、ファームウェア側の対応が先に必要 |
| BitLockerなど、TPMを使う暗号化の回復キーを控えているか | dbの更新でTPMの値（PCR7）が変わることがある |
| 同じ機種で先に試したか | ファームウェアの変数を書き換える作業なので、機種ごとの差が出やすい |
更新は、HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot の AvailableUpdates に 0x5944 を設定し、スケジュールタスク \Microsoft\Windows\PI\Secure-Boot-Update が動くことで進みます。数回の再起動が必要になることもあるので、メンテナンスの時間を取って作業しましょう。
手順の細かいところは機種やOSのバージョンで変わることがあります。実際の作業は、Microsoftのサポート記事とサーバーメーカーの案内を見ながら進めてください。
会社で管理しているPCも念のため確認する¶
サーバーほどではありませんが、社内のPCも一度は確認しておきたいところです。
Microsoftは、ほとんどのWindowsの機器には2023年の証明書が自動で届くと説明しています。一方で、先ほどの状態表示の機能は、企業で管理しているWindows 10・11でも既定で無効になっています。
そのため、自動で入ったかどうかを利用者の画面で確かめることはできません。資産管理ツールやスクリプトで UEFICA2023Status を集めておくと、更新が止まっている機種を見つけやすくなります。
古い機種では、メーカーのファームウェア更新が出ていないと証明書を追加できないこともあります。機種ごとの対応状況は、Dell・HP・Lenovoなどのメーカーがサポートページで公開しています。
Linuxサーバーではどうなる？¶
Linuxは、Microsoftの証明書と関係ないと思われがちです。
ただ、多くのディストリビューションは、Secure Bootが有効な機器で起動できるように、最初に動く shim というプログラムに Microsoft UEFI CA 2011 で署名をもらっていました。そのため、6月の期限はLinuxにも関係があります。
Red Hatは、2011年の証明書がすでにdbに入っている機器は6月27日以降も起動を続けられ、期限切れが影響するのは新しいプログラムへの署名だと説明しています。あわせて、2011年と2023年の両方の鍵で署名したshimを、サポート中のRHEL 8・9・10（x86_64）向けに出しています。
Linuxで確認するコマンド¶
LinuxでSecure Bootの状態とdbの中身を見るには、mokutil を使います。
# Secure Bootが有効か
mokutil --sb-state
# db に入っている証明書の名前を確認する
mokutil --db | grep -E "Subject:|CN="
# KEK も同じように確認できる
mokutil --kek | grep -E "Subject:|CN="
Microsoft UEFI CA 2023 が出てこない場合は、今の環境が起動できていても、将来2023年の鍵だけで署名されたshimに更新したときに起動できなくなるおそれがあります。ファームウェアの更新でdbに追加できるかを、サーバーメーカーの情報で確認しておきましょう。
また、Red Hatは、dbを更新するとTPMのPCR7の値が変わることにも触れています。TPMにディスク暗号化の鍵を結び付けている環境では、dbの更新後に自動でロックが解除されなくなる場合があるので、作業の前に回復の手段を確認しておきます。
仮想マシンは、テンプレートを見落としやすい¶
物理サーバーだけ見て終わりにしないように注意が必要です。
UEFIで起動する仮想マシンにも、仮想マシンごとのKEKとdbがあります。Hyper-VやVMwareでは、仮想マシンを作ったときのテンプレートや仮想ハードウェアの設定から、この中身が決まります。
コミュニティやベンダーの情報では、古いテンプレートから作った仮想マシンは2011年の証明書しか持っておらず、自動では更新されないという報告が多く出ています。
確認するときは、次の順番で見ていくと整理しやすいです。
| 順番 | 確認すること |
|---|---|
| 1 | ハイパーバイザー（Hyper-VのホストやESXi）が、2023年の証明書に対応したバージョンになっているか |
| 2 | 既存の仮想マシンの中で、前の章のコマンドを実行して証明書を確認する |
| 3 | 仮想マシンを作るときのテンプレートやゴールデンイメージを作り直す必要がないか |
| 4 | 仮想TPMを使っている仮想マシンで、更新の方法に制限がないか |
テンプレートが古いままだと、更新済みのサーバーの横で、新しく作ったサーバーだけ2011年の証明書のまま、ということが起きます。構築の手順書にも確認の手順を入れておくと安心です。
いつまでに何をすればいい？¶
期限が来ても止まらないので、後回しにされやすい作業です。
それでも、10月19日を過ぎたあとに出るブートマネージャーの更新や失効情報は、2023年の証明書がある機器にしか入りません。作業の優先順位は、次のように考えるとよいと思います。
優先して確認するもの：インターネットに公開しているサーバー、BitLockerやTPMで暗号化しているサーバー、ゴールデンイメージやテンプレート。物理の機種ごとに1台ずつ試してから、まとめて展開する。
Windows Server 2016のように、サポート終了が近いOSを使っている場合は、OSの移行とあわせて考える必要もあります。2016の移行については『Windows Server 2016のサポート終了まで、あと3か月半』にまとめています。
証明書の期限で運用が変わるという点では、HTTPSのサーバー証明書の有効期間が短くなっている話とも似ています。こちらは『有効期間200日ルールと自動化への移行』で紹介しました。
まとめ¶
最後に、この記事のポイントを振り返ります。
- Secure Bootの2011年の証明書は、6月24日・6月27日・10月19日の順に期限を迎え、10月19日の
Windows Production PCA 2011が最後の1枚 - 期限が来ても起動はするが、起動処理に関わる今後のセキュリティ更新を受け取れなくなる
- Windows Serverには自動で配られないので、
UEFICA2023Statusで状態を確認し、管理者が更新を始める - Linuxでは
mokutil --dbでMicrosoft UEFI CA 2023が入っているかを確認する - 仮想マシンは、テンプレートやゴールデンイメージまで確認する
Secure BootやUEFIの話は、ふだんの運用ではあまり触れない分野です。Linuxの起動の流れから整理しておきたい方は、InfraAcademyの『Linuxロードマップ』で順番に学べます。
一度確認の手順を作ってしまえば、次に同じような証明書の更新が来たときにも使い回せます。まずは手元のサーバーで、コマンドを1つ実行してみてください。
参考¶
- Windows Secure Boot certificate expiration and CA updates（Microsoft サポート）
- Prepare your servers for Secure Boot certificate updates（Windows Server Blog）
- IT admin guide: Secure Boot certificate update status in the Windows Security app（Microsoft サポート）
- KB5068202 Secure Bootのレジストリキーの説明（Microsoft サポート）
- 2026年のSecure Boot署名証明書の期限切れについて（Red Hat Blog）
- How To Check Secure Boot Certificates（Dell）
- CVE-2026-21265（Ubuntu）
