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.

Red Hat is in contact with Microsoft with regard to their signing schedule, and will release a new shim, signed with the 2023 certificate, once Microsoft starts signing with it. The start of signing is currently planned for October 2025.

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, source, and integrity of the code that is loaded. 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 plans to release new shims for supported releases, starting from RHEL 9.7, after signing with the new certificate has started, and been thoroughly tested.
  • Long-lived systems() that cannot receive an update to their Secure Boot db may face issues when a bootloader or shim update is required after the expiration.
  • 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

    • Do not manually apply the 2023 UEFI DB update until your hardware vendor provides explicit instructions.

  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

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

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 hardware vendor, not Red Hat.

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 previous system failures. These vendors require Secure Boot db updates to be delivered via approved firmware updates.
Do not force install db updates. Always follow vendor guidance.

Should I install the 2023 UEFI db update now?

Delay manual installation until the hardware vendor provides guidance, especially if on HP or Fujitsu systems.

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

As of March 25, 2026, all shim binaries are signed with Microsoft 2011 certificate, except on RHEL 9.7 aarch64 which is signed with Microsoft 2023 certificate.
In a near future, all shim binaries for RHEL 8, 9 and 10 will be signed with both Microsoft 2011 and 2023 certificates.

Comments