Microsoft Secure Boot certificate for Linux expires: What to do

Key points:
  • Microsoft's 2011 certificate used to sign the "shim" layer of Linux distributions expires at the end of June 2026.
  • Expiration will not prevent existing systems from booting, as UEFI Secure Boot only locks keys if they have been explicitly revoked (DBX).
  • Fedora and other distributions are already distributing dual-signed shim layers that include Microsoft's new 2023 certificate.
  • It is recommended to update the firmware using fwupdmgr to securely incorporate the new keys.
  • It is vital not to manually delete the 2011 key from the firmware, as it is used to validate peripheral hardware and deleting it could render the equipment unusable.
David Y. NaranjoUpdated on

4 minutes

secure-boot-linux

A few days ago, news broke that at the end of this month (June 2026), the Microsoft certificate used to digitally sign the Linux shim layer will reach its expiration date. Since this is the essential component that allows modern Linux distributions (such as Fedora, Ubuntu, and openSUSE) to boot on systems with UEFI Secure Boot enabled, it's understandable that the news has raised some concerns. However, the Fedora developers have been very clear on the matter: there's no reason to panic; your computer will continue to boot normally.

To understand why there won't be a massive Linux shutdown, it's necessary to understand how the chain of trust works. During the boot process, the UEFI system doesn't check if the certificate has expired, as its sole concern is verifying that the cryptographic signature is valid and that the key hasn't been explicitly revoked due to compromise. The expiration of the 2011 certificate simply means that Microsoft will no longer be able to use it to sign new versions of the bootloader.

The transition to the new key of 2023

To maintain compatibility and ensure that Linux systems can be installed on modern hardware, Microsoft generated a new certificate in 2023. The transition to this new key has been designed to be completely invisible to the user.

Currently, repositories like Fedora Rawhide (the basis for the upcoming Fedora 45) already include a dual-signed shim boot manager . This means it's certified by both the 2011 and 2023 keys, ensuring compatibility with both older computers that don't know the new key and modern motherboards that already have it pre-installed. Eventually, future versions of the shim will be signed exclusively with the 2023 key.

Real vulnerabilities: The danger lies in the old code

What can actually prevent a system from booting is not expiration, but revocation via the UEFI Certificate Revocation List (known as DBX). Security reports recently published detailing two critical vulnerabilities (CVE-2026-8863 and CVE-2026-10797) that allow an attacker to execute malicious code by bypassing Secure Boot protection.

Fortunately, these vulnerabilities only affect extremely old versions of the shim (version 0.9 and earlier, created before 2016). The signatures of these vulnerable layers have been added to the database of prohibited signatures (DBX). If you have a very outdated system (such as CentOS 7.2 or RHEL 7.2) and your UEFI database is updated, your computer will fail to boot for security reasons.

What should you do (and what should you NOT do)?

Although the expiration won't break your current system, the developers strongly recommend updating your firmware's key database to receive the new 2023 key and be future-proof. Here are the commands to check your device's status:

Check if you are using UEFI or BIOS (Legacy):

[[ -d /sys/firmware/efi ]] || echo BIOS

Check if Secure Boot is enabled:

mokutil --sb-state

List the public keys in the firmware:

mokutil --db --short (Here you should see the 2011 key and, if you're up to date, the 2023 key).

Update your firmware and keys automatically:

sudo fwupdmgr update (Download updates from the Linux Vendor Firmware Service).

Verify which key your shim is signed with (requires the pesign package):

sudo pesign -S -i /boot/efi/EFI/fedora/shimx64.efi

Finally, it's worth mentioning that the Fedora developers have issued a warning:

Do not attempt to update the database manually unless you are an expert, and under no circumstances should you delete or revoke the 2011 key. This key has not been compromised and is still used to validate the ROMs in your peripherals (Option ROMs). Deleting it risks causing hardware components to malfunction and preventing the system from booting the dual-signature version of the shim.

If you are interested in learning more, you can find the details at the following link.


Add as preferred source in Google