Secure Boot Certificate Changes in 2026: Guidance for RHEL Environments

Updated -

Overview

This article clarifies the upcoming expiration of Microsoft's 2011 Secure Boot signing certificate, scheduled for June 27, 2026, and its implications for Red Hat Enterprise Linux (RHEL) systems. It explains that existing systems using the current shim and enrolled certificates will remain bootable after the expiration date.

As of May 19, Red Hat has released a new version of shim, signed with multiple signing certificates, for all supported RHEL-9 and RHEL-10 releases for the x86_64 architecture. RHEL-8 z-streams will receive the same update in June 2026. Since the new shim is signed with Microsoft's 2011 and 2023 Secure Boot signing certificates, it will boot on all machines that have either or both of those certificates enrolled.

What is UEFI Secure Boot, and how does it work?

Secure Boot is a UEFI firmware security feature developed by the UEFI Consortium that ensures only immutable and signed software are loaded during the boot time. Secure Boot leverages digital signatures to validate the authenticity and source of the code that is loaded, thereby ensuring its integrity. These validation steps are taken to prevent malicious code from being loaded and to prevent attacks, such as the installation of certain types of rootkits.

Microsoft acts as a certificate authority and signs the first stage bootloader, called the shim, with their private key, and the associated public certificate is enrolled in firmware by hardware vendors. Signing with the 2011 key will no longer be possible after June 2026, so the public certificate needs to be updated in order for shim updates, signed with the new key, to boot.

What Does the 2026 Certificate Expiration Mean for RHEL?

  • Systems with the 2011 Microsoft UEFI CA certificate already enrolled will continue to boot after June 27, 2026.
  • The expiration only impacts the ability to sign new binaries, not booting from existing ones.
  • Red Hat will release new shim versions for all RHEL-8, RHEL-9 and RHEL-10 supported releases before the end of June 2026.
  • Legacy systems (e.g. old physical servers, old laptops / desktops, systems with no vendor firmware updates, appliances that never get BIOS/UEFI updates) that cannot receive an update to their Secure Boot db may face issues when a bootloader or shim update is required after the expiration.
  • Updates to the UEFI db will result in changes to Trusted Platform Module (TPM) Platform Configuration Register (PCR) values, particularly to PCR7. If you are relying on the value of particular PCRs for TPM-based automatic unlocking of LUKS-encrypted volumes, Measured Boot with local or remote attestation, Trusted Boot, or you are sealing some other secrets against this value, please be aware that it will change. After updating the db, do not reboot. First reseal against a PCR value that did not change, e.g., PCR0, reboot, and only then reseal against the new PCR7 value.
  • Systems running stable configurations with Secure Boot disabled are not impacted.

Recommended Actions for Red Hat Environments

Organizations managing RHEL deployments should consider the following:

  1. Assess Secure Boot Settings

    • Review Secure Boot configuration on all systems.
    • Check enrolled keys and verify the installed shim version.
    • Ensure configurations align with your security policies.

  2. Handle UEFI db Updates Carefully

    • Carefully test updating the UEFI db using fwupd before auto-updating all machines of the same model and firmware version.
    • If an update for your hardware is not offered by fwupd, contact your OEM vendor.

  3. Stay Informed on Security Advisories

    • Regularly monitor Red Hat errata and security advisories for updates related to shim, Secure Boot, and UEFI.
    • Plan updates and mitigations based on the advisories to avoid unplanned downtime.

How to Check if Secure Boot is Enabled on the Systems?

  • You can check the status of Secure Boot using the mokutil command:

    # mokutil --sb-state

  • The output will state whether Secure Boot is enabled or disabled.

    If Secure Boot is enabled:
SecureBoot enabled

If Secure Boot is disabled:
SecureBoot disabled

How can I check which Secure Boot certificates are enrolled?

Identify enrolled keys:

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

Example output on 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

How do I update my firmware using LVFS?

Enable and use LVFS (Linux Vendor Firmware Service) to ensure the latest vendor-provided firmware is installed:

# fwupdmgr update

Note: Firmware is provided by the hardware vendor, not Red Hat.

See also How to use fwupd to enroll the Microsoft UEFI CA 2023 certificate.

Should I install the 2023 UEFI db update now?

Yes, if an update is available via fwupd. Please first test the update before deploying it in production.

Can I update the UEFI Secure Boot db directly, without doing a full firmware update?

Not always. Standalone db updates are blocked on some platforms, including HP and Fujitsu, due to observed boot failures following an update. Hardware from these vendors requires a firmware update before the db and KEK updates can safely be deployed. Please contact your hardware vendor to find out if the firmware version is new enough to accept KEK and db updates.

Do not force install db updates. Always follow vendor guidance.

How does this apply to virtual machines using OVMF?

Virtual environments rely on the edk2-ovmf package to provide the UEFI firmware and the NVRAM template used when a new VM is created. This means the certificate set inside edk2-ovmf becomes the baseline for Secure Boot in any new VM deployment.
To ensure that new VMs start with the updated Microsoft 2023 Secure Boot certificates, update the edk2-ovmf package on the hypervisor or host system.

Why this matters:

If edk2-ovmf is outdated, newly created VMs will inherit older certificate bundles. These VMs may later hit Secure Boot validation issues when newer shims are released.

Packages that include the new certificates

  • RHEL 10 : edk2-ovmf-20241117-2.el10.noarch and later
  • RHEL 9 : edk2-ovmf-20231122-6.el9.noarch and later
  • RHEL 8 : Not applicable

The newer edk2-ovmf builds include both the 2011 and 2023 Microsoft Secure Boot certificates. This ensures compatibility with shims signed by either key, so customers can safely update to these versions immediately.

After the update, any new VM created with OVMF firmware will start with the correct certificate set.

How to check which certificate was used for signing Shim?

You can check the signature of shim through using pesign command available with pesign RHEL package, as shown in the example below on 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.
---------------------------------------------

Here above Microsoft Windows UEFI Driver Publisher is the Microsoft 2011 certificate.

Alternatively, you can check the signature of shim through using sbverify command available with sbsigntools EPEL package (not supported by Red Hat), as shown in the example below on 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

New shim binaries signed with both Microsoft 2011 and 2023 certificates are now available for all supported RHEL 9 and 10 releases for the x86_64 architecture. RHEL-8 will receive the same update by mid-June. On aarch64, the shim binary is only signed with the Microsoft 2023 certificate, starting with RHEL-9.7 and RHEL-10.0.

How to update the NVRAM of a VM that is already running, on RHEL9 and later?

Note: The --reset-nvram option is only available starting with libvirt 8.1.0, which is available on RHEL9 and later.
Note: After using --reset-nvram, any information stored in NVRAM will be lost. This is why updating via fwupd is preferable. That includes the UEFI boot order. fallback.efi is expected to take care of restoring the boot order on first boot after resetting NVRAM.

  1. Update package edk2-ovmf on the host to the latest version. That version needs to include the new certificates.

    # dnf install edk2-ovmf-YYYYMMDD-.noarch

  2. Stop the VM:

    # virsh shutdown <vm>

  3. Reset the NVRAM.

    # virsh start <vm> --reset-nvram

How to update the NVRAM of a VM that is already running, on RHEL8?

  1. Update package edk2-ovmf on the host to the latest version. That version needs to include the new certificates.

    # dnf install edk2-ovmf-YYYYMMDD-.noarch

  2. Stop the VM:

    # virsh shutdown <vm>

  3. Check the NVRAM storage location for the target VM.

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

  4. Back up the NVRAM.

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

  5. Remove the NVRAM.

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

  6. Start the VM:

    # virsh start <vm>

Comments