Secure Boot Certificate Expired: Billions of PCs Affected Including Linux Distros

Quick take: The "Microsoft 3rd Party UEFI CA 2011" certificate — embedded in the firmware of billions of PCs and used to sign Linux shim bootloaders — expired in 2026. Systems that haven't received a UEFI firmware update embedding the replacement "Microsoft UEFI CA 2023" certificate and an updated shim package may fail Secure Boot validation on next boot.

Introduction

Secure Boot is one of the most widely deployed firmware-level security features on modern PCs. It validates every piece of software that executes before the operating system loads, stopping unauthorized bootloaders, rootkits, and early-stage malware cold. The whole system depends on a chain of trust anchored in X.509 certificates stored in UEFI firmware.

When one of those root certificates expires, that chain of trust breaks. And the certificate that just expired — "Microsoft Corporation 3rd Party UEFI CA 2011" — is used to validate the shim bootloaders shipped by virtually every major Linux distribution. It is also embedded in OEM firmware on a huge number of Windows PCs. The impact is broad: estimates suggest more than two billion devices carry this certificate in their UEFI key databases.

What Is Secure Boot and Why Do Certificates Matter?

Secure Boot is a UEFI standard that requires each component in the boot chain — firmware, bootloader, kernel — to carry a cryptographic signature that the firmware can verify. The firmware holds an allowlist of trusted public keys (the Secure Boot Key Database, or "db") and a blocklist of revoked keys and hashes ("dbx"). If a binary's signature doesn't validate against a trusted key in "db", the firmware refuses to execute it.

Microsoft operates as the de facto root of trust for the Secure Boot ecosystem on the x86-64 PC platform. OEMs embed Microsoft's keys in firmware during manufacturing. Linux distributions can't publish their own keys into every OEM's firmware, so they instead ship a small pre-bootloader called shim, which is signed by Microsoft's "3rd Party UEFI CA" key. Once shim is validated and runs, it loads GRUB (or another bootloader) using its own enrolled Machine Owner Key (MOK). That's the standard Secure Boot path for Linux on most PCs.

The critical point: if the Microsoft key that signed shim has expired and the firmware's certificate store doesn't contain a valid successor, the firmware will reject shim and Linux won't boot under Secure Boot.

Which Certificate Expired?

The expired certificate is formally identified as:

Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011
Thumbprint (SHA-1): 580a6f4cc4e4b669b9ebdc1b2b3e087b80d0678d
Valid until: 2026 (approximately mid-year, depending on exact OEM key database build date)

This certificate was enrolled in the UEFI "db" (trusted keys database) of virtually every major OEM — Dell, HP, Lenovo, ASUS, MSI, Gigabyte, and more — during the Secure Boot rollout that accompanied Windows 8 in 2012. It has been in continuous use for 14 years. All Linux shim bootloaders signed in that era carry signatures validated by this certificate.

Windows Systems Affected

Windows itself uses a separate signing path through the "Microsoft Windows Production PCA 2011" certificate for its own boot components, so mainstream Windows 10 and Windows 11 installations are not directly broken by this expiry. However, several Windows-adjacent scenarios are affected:

• Recovery environments and WinPE images signed under the third-party CA path.
• Windows RT and ARM-based devices that used the third-party CA for some driver or bootloader components.
• BitLocker recovery flows on systems that boot through a third-party-signed component before the Windows boot manager.
• Dual-boot systems where Linux shim is the first-stage bootloader and Windows is launched from GRUB.

Most pure Windows-only systems booting directly through the Windows Boot Manager are unaffected by this specific certificate's expiry.

Linux Distributions Affected

The impact on Linux is broader. Every major distribution that ships Secure Boot support through the Microsoft-signed shim is potentially affected:

• Ubuntu and Debian — ship shim-signed as the Secure Boot entrypoint.
• Fedora and Red Hat Enterprise Linux — use a shim signed by Microsoft for the Red Hat signing chain.
• CentOS Stream, AlmaLinux, Rocky Linux — inherit the RHEL shim signing path.
• openSUSE and SUSE Linux Enterprise — ship their own Microsoft-signed shim.
• Linux Mint, Pop!_OS, and other Ubuntu derivatives — inherit the Ubuntu shim.

Distributions that don't participate in the Microsoft Secure Boot ecosystem — notably Arch Linux, Gentoo, and others where users manage their own Secure Boot keys — are not affected as long as they're not relying on the expired Microsoft CA.

Microsoft's Response and the Replacement Certificate

Microsoft issued a replacement certificate well in advance: Microsoft Corporation UEFI CA 2023. This new certificate has been distributed through:

• UEFI firmware updates pushed by OEMs through Windows Update and OEM-specific update utilities.
• Updated Secure Boot key database (db) packages available through Linux distribution package managers.
• New shim releases signed by the 2023 CA, distributed through Linux distribution package managers.

The problem is roll-out coverage. Not all OEMs have released UEFI firmware updates for every affected product. Older systems — especially those that haven't received firmware updates in years — may still carry only the 2011 CA in their firmware's key database.

How to Check If Your System Is Affected

Before rebooting into a system where the Secure Boot path might fail, verify your current state:

# Check Secure Boot status
mokutil --sb-state

# List all enrolled Secure Boot keys (look for expiry dates)
mokutil --list-enrolled

# Check signatures on your shim binary
sbverify --list /boot/efi/EFI/ubuntu/shimx64.efi
# Adjust path for your distro: shimx64.efi, shimia32.efi, etc.

# Check GRUB signature
sbverify --list /boot/efi/EFI/ubuntu/grubx64.efi

If mokutil --list-enrolled shows the 2011 CA and its expiry has passed with no 2023 CA present, your firmware may reject the current shim on next boot. Also check your OEM's support site for UEFI firmware updates specifically mentioning Secure Boot key database updates for the 2023 CA.

Remediation Steps

The fix requires action at two levels: the firmware (UEFI) and the operating system (shim package).

Step 1 — Update UEFI firmware. Check your OEM's support site for the latest UEFI/BIOS update for your specific model. Firmware updates that include the 2023 CA will be described in release notes as "Secure Boot key database update" or "UEFI CA 2023". On Linux, tools like fwupdmgr can check and apply firmware updates from the LVFS (Linux Vendor Firmware Service):

sudo fwupdmgr refresh
sudo fwupdmgr update

Step 2 — Update the shim package. Once your firmware recognises the 2023 CA, install the updated shim that carries signatures from the new certificate:

# Debian / Ubuntu
sudo apt update
sudo apt install --reinstall shim-signed shim-unsigned

# Fedora / RHEL / CentOS Stream
sudo dnf update shim

# openSUSE / SLES
sudo zypper update shim

Step 3 — Regenerate the GRUB configuration and reboot:

# Debian/Ubuntu
sudo update-grub

# RHEL/Fedora
sudo grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

Temporary workaround: If you're locked out and can't boot, enter UEFI firmware settings and temporarily disable Secure Boot. This allows you to boot, apply updates, then re-enable Secure Boot.

Final Thoughts

Certificate expiry events like this expose a structural tension in the Secure Boot ecosystem: the trust anchors are baked into firmware at manufacturing time, but certificates eventually expire. The industry relies on OEMs proactively distributing firmware updates — a process that is slow, incomplete, and effectively never reaches devices that are no longer supported by their manufacturers.

For system administrators managing fleets of mixed-age hardware, the action items are clear: audit firmware currency across your estate using tools like fwupdmgr, prioritise shim package updates on all Secure Boot-enabled Linux machines, and schedule UEFI firmware update cycles as a routine maintenance task alongside OS patching. The Secure Boot chain is only as strong as its least-maintained link.