Translated message

A translation of this page exists in English.

2026 年のセキュアブート証明書の変更: RHEL 環境向けガイダンス

更新 -

概要

このアーティクル記事では、2026 年 6 月 27 日に予定されている Microsoft の 2011 セキュアブート署名証明書の有効期限と、それが Red Hat Enterprise Linux (RHEL) システムに及ぼす影響を説明します。また、本記事では、現在の shim と登録済みの証明書を使用している既存のシステムは、有効期限後も引き続き起動可能であることを説明しています。

Red Hat は署名スケジュールに関して Microsoft と連携しており、Microsoft による署名が開始され次第、2023 証明書で署名された新しい shim をリリースする予定です。署名開始は現時点では 2025 年 10 月を予定しています。

UEFI セキュアブートの概要と仕組み

セキュアブートとは、UEFI Consortium によって開発された UEFI ファームウェアセキュリティー機能であり、ブート時に不変かつ署名されたソフトウェアのみがロードされるようにするものです。セキュアブートはデジタル署名を活用して、ロードされたコードの信頼性、ソース、整合性を検証します。これらの検証手順は、悪意のあるコードがロードされないようにし、特定タイプのルートキットのインストールなどの、攻撃を防ぐために行われます。

Microsoft は認証局として機能し、shim と呼ばれる第 1 段階のブートローダーに秘密鍵を使用して署名し、関連する公開証明書はハードウェアベンダーによってファームウェアに登録されます。2026 年 6 月以降は 2011 年の鍵による署名ができなくなるため、新しい鍵で署名された shim 更新版を起動できるようにするには、公開証明書を更新する必要があります。

2026 年の証明書期限切れに伴う RHEL への影響

  • 2011 Microsoft UEFI CA 証明書がすでに登録されているシステムは、2026 年 6 月 27 日以降も引き続き起動します。
  • 有効期限は、既存のバイナリーからの起動ではなく、新しいバイナリーに署名する機能にのみ影響します。
  • Red Hat は、新しい証明書による署名が開始され、徹底的なテストを実施した後に、RHEL 9.7 以降のサポートされているリリースに対して新しい shim をリリースする予定です。
  • セキュアブート db の更新を受信できない長期使用システム () では、有効期限後にブートローダーまたは shim の更新が必要になったときに問題が発生する可能性があります。
  • セキュアブートを無効にして安定した設定を実行しているシステムは影響を受けません。

Red Hat 環境における推奨アクション

RHEL デプロイメントを管理する組織は、次の点を考慮する必要があります。

  1. セキュアブート設定を評価する

    • すべてのシステムのセキュアブート設定を確認します。
    • 登録された鍵を確認し、インストールされている shim のバージョンを確認します。
    • 設定がセキュリティーポリシーに準拠していることを確認します。

  2. UEFI DB 更新に慎重に対応する

    • ハードウェアベンダーから明確な指示が出るまで、2023 UEFI DB 更新を手動で適用しないでください。

  3. セキュリティーアドバイザリーの最新情報を入手する

    • Red Hat エラータとセキュリティーアドバイザリーを定期的に監視し、shim、セキュアブート、UEFI に関連する更新を把握してください。
    • 計画外のダウンタイムを回避するために、アドバイザリーに基づいて更新と緩和策を計画します。

システムでセキュアブートが有効か確認する方法

  • mokutil コマンドを使用してセキュアブートのステータスを確認できます。

    # mokutil --sb-state

  • 出力には、セキュアブートが enabled か disabled かが示されます。

    If Secure Boot is enabled:
SecureBoot enabled

If Secure Boot is disabled:
SecureBoot disabled

登録済みのセキュアブート証明書の確認方法

登録済みの鍵を識別します。

# mokutil --db

Example output:
62b51ed2e6 ASUSTeK Notebook SW Key Certificate
46def63b5c Microsoft Corporation UEFI CA 2011
580a6f4cc4 Microsoft Windows Production PCA 2011
b5eeb4a670 Microsoft UEFI CA 2023
45a0fa3260 Windows UEFI CA 2023

LVFS を使用したファームウェアの更新方法

LVFS (Linux Vendor Firmware Service) を有効にして使用し、ベンダー提供の最新のファームウェアがインストールされていることを確認します。

# fwupdmgr update

注記: ファームウェアは Red Hat ではなくハードウェアベンダーによって提供されます。

ファームウェア更新を伴わない UEFI セキュアブート db の直接更新の可否

必ずしも可能とは限りません。HP および Fujitsu を含む一部のプラットフォームでは、過去にシステム障害が発生した経緯から、スタンドアロンでの db 更新がブロックされています。これらのベンダーでは、セキュアブート db の更新は承認済みのファームウェア更新を通じて提供される必要があります。
db 更新を強制的にインストールしないでください。常にベンダーのガイダンスに従ってください。

2023 UEFI db 更新インストールの推奨時期

ハードウェアベンダーからガイダンスが提供されるまで、手動でのインストールは見合わせてください。特に HP または Fujitsu 製のシステムを使用している場合は注意が必要です。

OVMF を使用する仮想マシンへの適用方法

仮想環境は、新しい仮想マシンの作成時に使用される UEFI ファームウェアと NVRAM テンプレートを提供するために edk2-ovmf パッケージに依存します。これは、すべての新規仮想マシンのデプロイメントにおいて、edk2-ovmf に組み込まれている証明書セットがセキュアブートのベースラインとなることを意味します。
新しい仮想マシンが更新された Microsoft 2023 セキュアブート証明書で起動するようにするには、ハイパーバイザーまたはホストシステム上の edk2-ovmf パッケージを更新します。

これが重要な理由:

edk2-ovmf が古い場合、新しく作成された仮想マシンは古い証明書バンドルを継承します。これらの仮想マシンでは、後で新しい shim がリリースされたときに、セキュアブートの検証の問題が発生する可能性があります。

新しい証明書を含むパッケージ

  • RHEL 10: edk2-ovmf-20241117-2.el10.noarch and later
  • RHEL 9: edk2-ovmf-20231122-6.el9.noarch 以降
  • RHEL 8:該当なし

新しい edk2-ovmf ビルドには、2011 と 2023 の両方の Microsoft セキュアブート証明書が含まれています。これにより、いずれかの鍵で署名された shims との互換性が確保され、お客様はこれらのバージョンにすぐに安全に更新できます。

更新後、OVMF ファームウェアで作成された新しい仮想マシンは、正しい証明書セットで起動します。

Shim の署名に使用された証明書の確認方法

RHEL 9.7 での以下の例に示すように、RHEL の pesign パッケージに含まれる pesign コマンドを使用して、shim の署名を確認できます。

# dnf -y install pesign
[...]

# pesign -S -i /boot/efi/EFI/redhat/shimx64.efi
certificate address is 0x7fbe099b27b8
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Microsoft Windows UEFI Driver Publisher
No signer email address.
No signing time included.
There were certs or crls included.

上記は、Microsoft Windows UEFI Driver Publisher の Microsoft 2011 証明書 です。

または、以下の RHEL 9.7 の例に示すように、sbsigntools EPEL パッケージ に含まれる sbverify コマンド (Red Hat ではサポートされていません) を使用して、shim の署名を確認することもできます。

# dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
[...]

# dnf -y install sbsigntools
[...]

# sbverify --list /boot/efi/EFI/redhat/shimx64.efi 
warning: data remaining[906736 vs 1035680]: gaps between PE/COFF sections?
signature 1
image signature issuers:
 - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher
   issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
   issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root

2026 年 3 月 25 日現在、すべての shim バイナリーは Microsoft 2011 証明書で署名されていますが、RHEL 9.7 aarch64 は Microsoft 2023 証明書 で署名されています。
2026 年 6 月末までに、Microsoft 2011 & 2023 の両方の証明書で署名された新しい shim バイナリーが、すべてのアクティブな RHEL 8、9、および 10 リリースで利用可能になります。

ハードウェアベンダーからガイダンスが提供されるまで、手動でのインストールは見合わせてください。特に HP または Fujitsu 製のシステムを使用している場合は注意が必要です。

実行中の仮想マシンにおける NVRAM の更新方法

注記: --reset-nvram オプションは、libvirt 8.1.0 以降でのみ利用可能です。
注記: --reset-nvram を使用すると、NVRAM に保存されているすべての情報が失われます。そのため、fwupd を介した更新が推奨されます。 失われる情報には UEFI の起動順序も含まれます。ただし、NVRAM のリセット後、最初の起動時に fallback.efi が起動順序を復元するようになっています。

  • 1) ホスト上の edk2-ovmf パッケージを最新バージョンに更新します。このバージョンには、新しい証明書が含まれている必要があります。

    # dnf install edk2-ovmf-YYYYMMDD-.noarch

  • 2) 仮想マシンを停止します。

    # virsh shutdown <vm>

  • 3) NVRAM をリセットします。

    # virsh start <vm> --reset-nvram

Comments