この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
そんな不安を抱えたまま情報を探している管理者は少なくないはずです。Microsoftが発行してきたSecure Bootの主要証明書（2011年版）が、2026年6月から段階的に有効期限を迎えます。WindowsだけでなくLinuxのブートにも関わる話のため、サーバー運用の現場でも無視できません。
この記事では、20年以上Linuxサーバーを運用してきた管理者目線で、どの証明書がいつ失効するのか、Linuxのブートに何が起きるのか、そしてshimやMOK、dbx更新をどう確認・対応すればよいのかを、Microsoftとレッドハットの一次情報をもとに整理します。
この記事のポイント
・失効するのはMicrosoft Corporation KEK CA 2011（2026年6月24日）とMicrosoft UEFI CA 2011（2026年6月27日）
・失効後も既存システムは起動できる。止まるのは「新しい署名済みバイナリやdbx更新の信頼」
・Linuxのshimに署名しているのはMicrosoft UEFI CA 2011。後継はMicrosoft UEFI CA 2023
・登録済み証明書の確認は mokutil --db で発行者と有効期限を見るのが基本
・db/KEK更新はfwupdmgr（LVFS）経由が原則。一部機種はフルファームウェア更新が必要
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
Secure Boot証明書2026年失効の概要｜何が、いつ切れるのか
Secure Bootは、UEFIファームウェアが「信頼された署名付きのブートローダーだけを起動する」仕組みです。その信頼の根っこにあるのが、Microsoftが2011年に発行した一連の証明書です。これらが、ついに有効期限を迎えます。Microsoftの公式ドキュメント「Windows Secure Boot certificate expiration and CA updates」は、失効する証明書とその日付を明記しています。混同されやすいので、まず正確な日付を押さえておきます。
1. 6月に失効する2つの証明書
2026年6月に失効するのは、次の2つです。・Microsoft Corporation KEK CA 2011：2026年6月24日に失効。db（許可リスト）とdbx（失効リスト）の更新に署名する鍵（KEK）です
・Microsoft UEFI CA 2011：2026年6月27日に失効。サードパーティのブートローダーやEFIアプリケーション、option ROMへの署名に使われています。Linuxのshimもこれに署名されています
この2つが、今回「2026年6月のSecure Boot証明書失効」と呼ばれている本体です。
2. 10月に失効する証明書とは別物
もう1つ、Microsoft Windows Production PCA 2011という証明書もありますが、こちらの失効は2026年10月19日です。Windowsのブートローダー（Windows Boot Manager）の署名に使われるもので、6月の話とは時期も対象も異なります。「6月の話」と「10月の話」を一緒くたにすると対応計画が崩れるので、ここは分けて考えてください。失効すると何が起きるのか｜「起動不能」ではない
ここが最大の誤解ポイントです。「証明書が失効する＝Linuxが起動しなくなる」と早合点して慌てる必要はありません。1. 既存システムの起動は止まらない
すでにファームウェアのdb（許可データベース）に登録されている2011証明書は、失効日を過ぎても、現に動いているシステムの起動については引き続き有効です。レッドハットの解説でも、既存の登録済み証明書は失効後も現行システムの起動に使えるとされています。失効が止めるのは、あくまで「新しいバイナリへの署名」と「新しい信頼の追加」です。2. 本当の問題は「更新が信頼されなくなる」こと
Microsoftの説明によれば、更新しない端末は、早期ブートプロセスに対する新しいセキュリティ保護を受け取れなくなります。具体的には、Windows Boot Managerの更新、Secure Bootデータベースの更新、失効リスト（dbx）の更新、そして新しく見つかったブートレベルの脆弱性への緩和策が、信頼されなくなっていきます。Linuxの現場に引き寄せると、こういうことです。将来、新しいMicrosoft UEFI CA 2023で署名されたshimやブートローダーが配布されたとき、ファームウェアに2023証明書が登録されていなければ、その新しいバイナリをSecure Bootが信頼できません。つまり「今は動くが、将来のセキュリティ更新を取り込めない箱」になっていく、というリスクです。
Linuxブートへの影響｜shim・MOK・dbxの関係を整理する
Secure Boot環境でLinuxがどう起動しているかを思い出すと、今回の話がどこに効くのかが見えてきます。1. shimが信頼の橋渡しをしている
Secure Bootが有効なUEFI環境では、ファームウェアはまずshimという小さなブートローダーを起動します。このshimが、Microsoft UEFI CA 2011で署名されているからこそ、Microsoftの証明書しか持たない一般的なPCのファームウェアでも、Linuxを起動できるわけです。shimはその後、GRUBやカーネルの署名を検証してチェーンをつないでいきます。今回失効するMicrosoft UEFI CA 2011は、まさにこのshimの署名元です。後継はMicrosoft UEFI CA 2023で、こちらの有効期限は2035年6月13日と、当面の余裕があります。
2. MOKは自分で登録した鍵の置き場
shimにはMOK（Machine Owner Key）という仕組みがあり、自分でビルドしたカーネルモジュールや独自の鍵を登録できます。今回の証明書失効はMicrosoft側の話なので、自分で登録したMOK自体が無効になるわけではありません。ただし、ファームウェアのdbやKEKが古いままだと、ベンダーが配布する新しいdbx（失効リスト）を取り込めず、既知の脆弱なブートローダーをブロックできないままになります。PR
UEFIからGRUB、カーネル起動までの一連の流れを腰を据えて理解したい方へ。Secure Bootの議論は結局ブートチェーンの理解が前提になるため、土台固めに向いた一冊です。
登録済み証明書の確認手順｜まず自分の状態を知る
慌てて何かを更新する前に、自分のサーバーが今どの証明書を信頼しているのかを確認します。対応の出発点はここです。1. mokutilで登録済み証明書を見る
ファームウェアのdbに登録されている証明書は、mokutilコマンドで確認できます。レッドハットの解説でも案内されている方法です。# dbに登録された証明書の一覧（発行者・有効期限が見える） mokutil --db | grep -A13 "\[key" # Secure Bootが有効かどうかの確認 mokutil --sb-state
2. ファームウェア更新の手段を確認する
db・KEKの更新は、多くのLinux環境ではfwupd経由で配布されます。LVFS（Linux Vendor Firmware Service）に対応した機種なら、次のコマンドで更新を確認できます。# 利用可能なファームウェア更新を取得 fwupdmgr refresh # 適用可能な更新を確認 fwupdmgr get-updates
ディストリビューション別の対応｜RHEL・Ubuntu・Debian
各ディストリビューションは、新しい証明書でも起動できるよう対応を進めています。基本姿勢は「ディストリのshim更新を取り込み、ファームウェアのdb/KEKをベンダー経由で更新する」という二段構えです。1. RHEL系（RHEL・Rocky・AlmaLinux）
レッドハットは、複数の署名証明書で署名した新しいshimをRHEL 8/9/10のx86_64向けに提供する方針を示しています。これにより、2011証明書と2023証明書のどちらが登録された端末でも起動できるようにする狙いです。管理者としては、通常のyum/dnf更新でshimとSecure Boot関連パッケージを最新にしておくことが第一歩になります。仮想マシンを使っている場合は、ハイパーバイザ側のedk2-ovmf（OVMF）も更新し、VMが正しい証明書を継承できるようにします。2. UbuntuとDebian
UbuntuとDebianも、Microsoftの証明書ローテーションに合わせてshim・ブートローダーの更新を順次配布する流れです。具体的な配布タイミングや対象バージョンは公式のアナウンスとパッケージ更新で確認するのが確実なので、ここでは特定の版数を断定しません。基本動作はRHEL系と同じで、まずはapt updateでshim関連を最新化し、その上でファームウェアのdb/KEK更新をベンダー経由で適用していきます。3. 共通して踏むべき確認
ディストリを問わず、対応の型は共通です。Secure Bootの状態を確認し、登録済みの証明書を棚卸しし、shimを最新化し、ファームウェアの証明書更新の可否を機種ごとに確認する。この順番で1台ずつ潰していけば、慌てずに済みます。台数が多い環境では、mokutilの出力を構成管理ツールで収集し、2023証明書が入っていない端末を一覧化しておくと、移行の優先順位づけが楽になります。PR
コマンド操作からシェルの考え方までを体系的に押さえ直したい方へ。mokutilやfwupdのような運用コマンドを落ち着いて扱う土台づくりに、定番として手元に置いておきたい一冊です。
Linux管理者にとっての教訓｜証明書も「期限の管理」対象
今回のSecure Boot証明書失効は、TLS証明書やOSのEOLと同じく、「期限を管理して、切れる前に手を打つ」という運用の基本そのものです。証明書というと、つい外部公開サーバーのTLS証明書ばかりに目が行きがちですが、ブートの信頼の根っこにもこうした期限があるのだと、今回の件は思い出させてくれます。幸い、今回はいきなりブート不能になる種類の話ではありません。だからこそ、期限に追われて雑な更新をするのではなく、Secure Bootの状態確認、登録済み証明書の棚卸し、shimの最新化、ファームウェア更新の可否確認という手順を、落ち着いて1台ずつ進められます。
こうした「仕組みを理解した上で、慌てず手順を踏む」力こそ、コマンドの暗記以上にLinuxサーバー運用で効いてくる基礎体力です。Secure BootやUEFIのブートチェーンを一度きちんと理解しておくと、こうした証明書ローテーションの話が来ても、ニュースに振り回されずに自分の環境を診断できるようになります。
本記事のまとめ｜やること早見表とトラブル時の確認
今回のSecure Boot証明書失効への対応を、作業の早見表として整理しておきます。トラブルが起きたときも、まずはこの順番で状態を確認するのが基本です。| やりたいこと | コマンド・対応 |
|---|---|
| Secure Bootが有効か確認する | mokutil --sb-state |
| 登録済み証明書（発行者・期限）を確認する | mokutil --db | grep -A13 "\[key" |
| ファームウェア更新を取得・確認する | fwupdmgr refresh && fwupdmgr get-updates |
| shimを最新化する（RHEL系/Debian系） | dnf update shim* または apt update && apt upgrade |
あなたのLinuxサーバー、Secure Bootの証明書まで把握できていますか？
mokutilでの状態確認、shimの最新化、ファームウェアのdb/KEK更新。こうした作業を落ち着いて進められるかどうかは、結局のところLinuxサーバーの基礎体力にかかっています。
ネットの断片的な情報をつなぎ合わせるのではなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます