Translated message

A translation of this page exists in English.

2026 年安全引导证书的变化：RHEL 环境的指导信息

已更新 -

概述

本文介绍了 Microsoft 的 2011 Secure Boot 签名证书即将到期（计划于 2026 年 6 月 27 日过期）的信息，以及对 Red Hat Enterprise Linux (RHEL) 系统的影响。它解释了使用当前 shim 和注册的证书的现有系统将在过期日期后保持可引导。

自 6 月 10 日起，红帽发布了一个使用多个签名证书签名的新版本的 shim，适用于 x86_64 架构的所有 RHEL-8、RHEL-9 和 RHEL-10 版本。由于新的 shim 使用 Microsoft 的 2011 和 2023 安全引导签名证书进行签名，因此它将可以在使用其中一个（或两个都使用）注册的所有机器上引导。

什么是 UEFI 安全引导（Secure Boot）？它如何工作？

安全引导 (Secure Boot) 是由 UEFI Consortium 开发的一个 UEFI 固件安全功能，可确保在引导时只加载不可变且经过签名的软件。安全引导（Secure Boot）使用数字签名来验证加载代码的真实性和来源，确保其完整性。采取这些验证步骤可以防止恶意代码被加载，以及防止安全攻击（如安装某种类型的 rootkits）。

Microsoft 充当一个证书颁发机构，并使用其私钥签署第一阶段引导装载程序（称为 shim），相关的公共证书被硬件供应商注册到固件中。在 2026 年 6 月后，不再能使用 2011 密钥进行签名，因此需要更新相关的公共证书用于 shim 更新（使用新密钥签名）引导。

2026 证书到期对 RHEL 意味着什么？

  • 在 2026 年 6 月 27 日后，已注册的使用 2011 Microsoft UEFI CA 证书的系统可以继续正常启动。
  • 过期只会影响对新二进制文件的签名，使用现有代码进行引导不受影响。
  • 红帽已发布适用于所有 RHEL-8、RHEL-9 和 RHEL-10 支持版本的新 shim 版本。
  • 在过期后需要更新 bootloader 或 shim 时，传统系统（例如旧的物理服务器、旧的笔记本电脑/台式机、没有供应商固件更新的系统、从未获得 BIOS/UEFI 更新的设备）因为无法接收对其安全引导 db 的更新可能会面临问题。
  • 更新 UEFI 数据库将会改变 Trusted Platform Module (TPM) Platform Configuration Register (PCR) 的值，特别是 PCR7。如果您所使用的基于 TPM 的自动解锁 LUKS 加密卷、带有本地或远程 attestation、Trusted Boot 等功能依赖于特定的 PCR，或需要根据 PCR 的值来封装其它一些 secret，请注意这个变化。在更新数据库后，不要重启。首先针对未更改的 PCR 值（如 PCR0）重新进行封装，再进行重启，然后在针对新的 PCR7 值重新封装。
  • 对于运行禁用了安全引导的稳定配置的系统，不会受到影响。

对红帽环境推荐的操作

管理 RHEL 部署的机构应考虑以下几点：

  1. 评估安全引导设置

    • 在所有系统上检查安全引导配置。
    • 检查注册的密钥并验证已安装的 shim 版本。
    • 确保其配置与您的安全策略一致。

  2. 处理 UEFI 数据库更新时需要非常小心

    • 在自动更新相同模型和固件版本的所有机器之前，请仔细测试使用 fwupd 更新 UEFI 数据库。
    • 如果 fwupd 没有提供您的硬件的更新，请联络您的 OEM 供应商。

  3. 请随时关注安全公告

    • 定期检查红帽勘误和安全公告，以了解与 shim、安全引导和 UEFI 相关的更新。
    • 根据公告计划更新和缓解措施，以避免计划外的停机。

如何检查是否在系统中启用了安全引导？

  • 您可以使用 mokutil 命令检查安全引导的状态：

    # mokutil --sb-state

  • 输出显示安全引导是 enabled 还是 disabled。

    If Secure Boot is enabled:
SecureBoot enabled

If Secure Boot is disabled:
SecureBoot disabled

如何检查注册了哪些安全引导证书？

确定注册的密钥：

# mokutil --db | grep -A13 "\[key"

VMWare 的输出示例：

[key 1]
Owner: a3d5e95b-0a8f-4753-8735-445afb708f62
SHA1 Fingerprint: 13:7e:57:1f:0b:81:8a:0f:5c:32:3d:a2:7f:4a:ec:cf:95:98:0c:96
Certificate:
    [...]
        Issuer: C=US, ST=California, L=Palo Alto, O=VMware, Inc.
        Validity
            Not Before: Oct 16 17:16:05 2008 GMT
            Not After : Dec 31 17:16:05 2019 GMT
        Subject: C=US, ST=California, L=Palo Alto, O=VMware, Inc.
--
[key 2]
Owner: a3d5e95b-0a8f-4753-8735-445afb708f62
SHA1 Fingerprint: 73:8a:96:2b:d9:c8:1b:72:77:17:af:17:ee:09:3f:e9:b4:ba:ee:c0
Certificate:
    [...]
        Issuer: C=US, ST=California, L=Palo Alto, O=VMware, Inc., CN=VMware Secure Boot Signing
        Validity
            Not Before: Oct 24 06:47:59 2017 GMT
            Not After : Oct 19 06:47:59 2037 GMT
        Subject: C=US, ST=California, L=Palo Alto, O=VMware, Inc., CN=VMware Secure Boot Signing
--
[key 3]
Owner: 77fa9abd-0359-4d32-bd60-28f4e78f784b
SHA1 Fingerprint: 46:de:f6:3b:5c:e6:1c:f8:ba:0d:e2:e6:63:9c:10:19:d0:ed:14:f3
Certificate:
    [...]
        Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
        Validity
            Not Before: Jun 27 21:22:45 2011 GMT
            Not After : Jun 27 21:32:45 2026 GMT
        Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011
--
[key 4]
Owner: 77fa9abd-0359-4d32-bd60-28f4e78f784b
SHA1 Fingerprint: 58:0a:6f:4c:c4:e4:b6:69:b9:eb:dc:1b:2b:3e:08:7b:80:d0:67:8d
Certificate:
    [...]
        Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010
        Validity
            Not Before: Oct 19 18:41:42 2011 GMT
            Not After : Oct 19 18:51:42 2026 GMT
        Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011
--
[key 5]
Owner: 77fa9abd-0359-4d32-bd60-28f4e78f784b
SHA1 Fingerprint: 45:a0:fa:32:60:47:73:c8:24:33:c3:b7:d5:9e:74:66:b3:ac:0c:67
Certificate:
    [...]
        Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010
        Validity
            Not Before: Jun 13 18:58:29 2023 GMT
            Not After : Jun 13 19:08:29 2035 GMT
        Subject: C=US, O=Microsoft Corporation, CN=Windows UEFI CA 2023
--
[key 6]
Owner: 77fa9abd-0359-4d32-bd60-28f4e78f784b
SHA1 Fingerprint: b5:ee:b4:a6:70:60:48:07:3f:0e:d2:96:e7:f5:80:a7:90:b5:9e:aa
Certificate:
    [...]
        Issuer: C=US, O=Microsoft Corporation, CN=Microsoft RSA Devices Root CA 2021
        Validity
            Not Before: Jun 13 19:21:47 2023 GMT
            Not After : Jun 13 19:31:47 2038 GMT
        Subject: C=US, O=Microsoft Corporation, CN=Microsoft UEFI CA 2023

如何使用 LVFS 更新固件？

启用并使用 LVFS (Linux Vendor Firmware Service) 来确保安装了最新的厂商提供的固件：

# fwupdmgr update

备注：固件由硬件厂商提供，而不是由红帽提供。

另请参阅如何使用 fwupd 注册 Microsoft UEFI CA 2023 证书。

我现在是否应安装 2023 UEFI 数据库更新？

是，如果更新可以通过 fwupd 获得。请在生产环境中进行部署更新前，测试更新。

我是否可以直接更新 UEFI 安全引导数据库，而不是通过完整的固件更新进行？

并非总是可以。因为已发现在更新后会出现引导失败的问题，独立（standalone）数据库更新在一些平台上（包括 HP 和 Fujitsu）会被阻止。在可以安全地部署数据库和 KEK 更新前，这些厂商的硬件需要更新固件。请联系您的硬件厂商，以了解固件版本是否足够新，以接受 KEK 和数据库更新。

不要强制安装数据库更新。您应始终遵循厂商的指导。

对使用 OVMF 的虚拟机有什么影响？

虚拟环境依赖 edk2-ovmf 软件包来提供 UEFI 固件，以及在创建一个新虚拟机时使用的 NVRAM 模板。这意味着，在 edk2-ovmf 内部设置的证书成为任何新虚拟机部署中的安全引导的基准。
要确保新虚拟机使用更新的 Microsoft 2023 安全引导证书，请更新 hypervisor 或主机系统中的 edk2-ovmf 软件包。

为什么这一点很重要：

如果 edk2-ovmf 已过时，新创建的虚拟机会继承旧的证书捆绑包。在新的 shims 发布后，这些虚拟机可能会遇到安全引导验证的问题。

包含新证书的软件包

  • RHEL 10 : edk2-ovmf-20241117-2.el10.noarch 和更新版本
  • RHEL 9 : edk2-ovmf-20231122-6.el9.noarch 和更新版本
  • RHEL 8 :不适用

较新的 edk2-ovmf 构建包括了 2011 和 2023 Microsoft 安全引导证书。这可确保使用其中任一密钥签名的 shims 的兼容性，因此客户可以立即安全地更新到这些版本。

在更新后，任何使用 OVMF 固件创建的新虚拟机都会带有正确的证书集。

如何检查使用了哪个证书来对 Shim 进行签名？

您可以使用 pesign RHEL 软件包所提供的 pesign 命令来检查 shim 的签名，如下例所示（RHEL 9.7）：

# 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 certificate。

另外，您还可以使用 sbsigntools EPEL 软件包（红帽不支持）所提供的 sbverify 命令检查 shim 的签名，如下例所示（RHEL 9.7）：

# 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

现在，x86_64 架构的所有支持的 RHEL 8、9 和 10 版本都提供了使用 Microsoft 2011 and 2023 certificates 签名的新 shim 二进制文件。从 RHEL-9.7 和 RHEL-10.0 开始，在 aarch64 中，shim 二进制文件仅使用 Microsoft 2023 证书签名。

如何更新已在 RHEL9 及更新版本中运行的虚拟机的 NVRAM？

备注：--reset-nvram 选项只从 libvirt 8.1.0 开始提供，它会包括在 RHEL9 及更新的版本中。
备注：在使用了 --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

如何在 RHEL8 上更新已在运行的虚拟机的 NVRAM？

  1. 将主机上的软件包 edk2-ovmf 更新至最新版本。此版本需要包含新证书。

    # dnf install edk2-ovmf-YYYYMMDD-.noarch

  2. 停止虚拟机：

    # virsh shutdown <vm>

  3. 检查目标虚拟机的 NVRAM 存储位置。

    # virsh dumpxml <vm> | grep nvram
<nvram>/var/lib/libvirt/qemu/nvram/<vm>.fd</nvram>

  4. 备份 NVRAM。

    # cp /var/lib/libvirt/qemu/nvram/<vm>.fd /path/to/...

  5. 删除 NVRAM。

    # rm /var/lib/libvirt/qemu/nvram/<vm>.fd

  6. 启动虚拟机：

    # virsh start <vm>

Comments