Microsoft’s legacy Secure Boot signing certificate is nearing expiration, initiating an important transition that impacts the wider Linux ecosystem.
The Microsoft UEFI Certificate Authority from 2011, widely used in the Secure Boot chain on standard PCs, will expire this June, and Linux distributions must move their shim signing path to the newer 2023 CA.
This is significant for the Linux ecosystem, as many distros depend on a Microsoft-signed bootloader (called shim) to start Linux on Secure Boot-enabled machines – a firmware feature that ensures only trusted software runs during startup.
Long story short: when a computer powers on, the firmware verifies that the initial boot component is signed by a trusted key. If valid, the boot process continues; if not, the firmware blocks it.
For Windows, this process is seamless because PC firmware typically trusts Microsoft’s keys by default. Most Linux distros, however, are not directly trusted by firmware on consumer and enterprise PCs.
To address this, many use shim, a small first-stage UEFI bootloader signed by Microsoft. The firmware trusts shim, which then verifies subsequent Linux boot components, such as GRUB and the kernel, using the distribution’s own keys.
Most existing systems are expected to continue booting after the old certificate expires. Importantly, expiration does not remove the old key from firmware or revoke already trusted bootloaders. Therefore, a Linux system that boots today with Secure Boot enabled should not fail solely due to the certificate’s expiration.
The main risk lies in the transition period. New Linux installation images, updated shim packages, rescue media, older hardware, dual-boot systems, and machines with outdated Secure Boot databases may run into issues if they do not recognize the newer 2023 Microsoft UEFI CA. Removing the old 2011 key prematurely can also cause boot problems.
This is critical because Secure Boot depends on a chain of trust. Each stage must recognize and trust the next. If the firmware does not trust the key used to sign the shim, the shim will not start, and the Linux bootloader and kernel cannot proceed through the Secure Boot process.
For users, the key advice is to keep the operating system, shim packages, firmware, and Secure Boot database updates up to date as provided by distributions. Remember, avoid manually changing Secure Boot keys unless directed by a vendor or distribution.
I don’t use secure boot.