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 証明書 で署名されています。
近い将来、RHEL 8、9、10 用のすべての shim バイナリーは Microsoft 2011 および 2023 証明書 の両方で署名される予定です。

Comments