Secure Boot certificate changes in 2026: Guidance for RHEL environments

Microsoft's 2011 Secure Boot signing certificate is scheduled to expire on June 26, 2026. This has raised questions across enterprise Linux environments about system bootability, shim updates, and required actions. First and foremost, the key message is simple: Existing Red Hat Enterprise Linux (RHEL) systems that boot successfully today will continue to boot after June 26, 2026. The certificate expiration affects the ability to sign new boot components, not the ability to boot with already trusted ones.

Microsoft has started signing Secure Boot components using the 2023 UEFI CA certificate. Following this change, Red Hat is releasing updated shims signed with the 2023 key for supported Red Hat Enterprise Linux releases, beginning with RHEL 9.7, after completing full validation and testing.

You probably have lots of questions, though. This article provides comprehensive answers and resources to help.

What is UEFI Secure Boot and how does it work?

Secure Boot is a UEFI firmware security feature developed by the UEFI Consortium to ensure that only immutable and signed software are loaded during boot time. Secure Boot leverages digital signatures to validate the authenticity, source, and integrity of the code that's 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.

For more information, read What is UEFI Secure Boot and how does it work?

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 26, 2026.

The expiration only affects some customers who perform custom signing, such as signing custom kernels, bootloaders, or modules enabled with Secure Boot. It does not impact booting from already signed or existing components.

Red Hat plans to release new shims for supported releases, starting from RHEL 9.7, after signing with the new certificate has started and has been thoroughly tested.

Long-lived systems that cannot receive an update to their Secure Boot database (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.

What are the recommended actions for Red Hat environments?

If you manage RHEL deployments, here's what you should do:

1. First, assess the Secure Boot settings on your systems
   1. Review Secure Boot configuration on each system
   2. Confirm the enrolled keys are valid, and verify the installed shim version
   3. Ensure configurations align with your organization's security policies
2. Do not manually apply the 2023 UEFI DB update until your hardware vendor provides explicit instructions
3. Stay informed on security advisories
   1. Regularly monitor Red Hat errata and security advisories for updates related to shim, Secure Boot, and UEFI
   2. Plan updates and mitigations based on the advisories to avoid unplanned downtime

How can I determine whether Secure Boot is enabled on my systems?

You can verify the status of Secure Boot using the mokutil command:

$ sudo mokutil --sb-state

The output states whether Secure Boot is enabled or disabled. For example, on a system with Secure Boot enabled:

$ sudo mokutil --sb-state
SecureBoot enabled

For more information, read the How to check if Secure Boot is enabled on your systems? article.

How can I determine which Secure Boot certificates are enrolled?

You can use mokutil to list enrolled keys:

$ sudo mokutil --db
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 Linux vendor firmware service (LVFS) to ensure that the latest vendor-provided firmware is installed:

$ sudo fwupdmgr update

Firmware is provided by hardware vendors, not by Red Hat. For more information, read How do I update my firmware using LVFS?.

Can I update the UEFI Secure Boot DB directly and without 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 with 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 both the UEFI firmware and the NVRAM template when a new VM is created. This means the certificate set inside edk2-ovmf becomes the baseline for Secure Boot in any new virtual machine (VM) deployment.

To ensure that a new VM starts with the updated Microsoft 2023 Secure Boot certificates, update the edk2-ovmf package on the hypervisor or host system.

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

The packages that include the new certificates are:

• 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 you 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 Shim signature by using the pesign command. This tool is available in the pesign RHEL package. The following example shows how to do this 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.
---------------------------------------------

Alternatively, you can check the signature using sbverify command. This command is part of the sbsigntools package from Extra Packages for Enterprise Linux (EPEL). Note that Red Hat does not support EPEL. The following example shows this on RHEL 9.7:

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

# dnf 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 a Microsoft 2011 certificate. However, on RHEL 9.7 for aarch64, the binary is signed with a Microsoft 2023 certificate. In the near future, all Shim binaries for RHEL 8, 9 and 10 will be signed with both Microsoft 2011 and 2023 certificates.

Summary

Secure Boot certificate expiration in 2026 does not break existing systems. Red Hat provides shims signed with the 2023 certificate for supported RHEL releases. Secure Boot DB and firmware updates remain controlled by the vendor. For virtual environments, you must ensure that edk2-ovmf is current for new VM deployments.

The best way to manage your UEFI updates is through awareness, vendor alignment, and avoiding unnecessary manual intervention. This article has provided you with a head start.