Secure Boot certificate expiration is here
Linux users who have Secure Boot enabled on their systems rely on certificates issued by Microsoft to verify the software used to boot a system is trusted by the user. One of those certificates expired recently, but that will not cause systems that are able to boot to stop doing so. There are situations where the expiration may cause problems, however, and the window for relying on existing signed binaries is shorter than it might appear. Users and administrators will want to stay on top of these changes. Over the last year, part of my job at Microsoft has been to work on this problem. LWN wrote about the certificate expiration in July 2025, and this article follows up with where we are now.
How Linux boots under Secure Boot
UEFI Secure Boot requires firmware to refuse to execute boot code that has not been signed by a certificate in the firmware's trust database. The majority of computing hardware capable of Secure Boot is manufactured to meet Microsoft guidelines that include loading the Microsoft UEFI certificates into the firmware trust database for use as trust anchors.
Microsoft does not sign the GRUB bootloader. Instead, it signs the shim binary, which is the first-stage bootloader that then loads the distribution's own bootloader (typically GRUB), which then validates and loads the kernel.
From shim onward, the chain of trust runs through the distribution's own infrastructure. Distributions manage their own signing keys and can publish updates to GRUB and the kernel without involving Microsoft. Shim is designed to change infrequently, so that Microsoft's signing role does not become part of distribution-release or security-update processes, except in situations where shim itself needs to be signed.
The code for shim is open source. The community runs a shim-review process that serves as the primary gate to signing. A distributor, such as Debian or Red Hat, creates an issue in the GitHub repository that includes the shim.efi binary to be signed, the build logs, and additional information to review a request for a signature. After the community approves a submission, then the distributor may request the signature; Microsoft then verifies the submitter's relationship to the distribution, runs its own checks, and applies the cryptographic signature. This arrangement lets the community manage review without running signing infrastructure or requesting all of the firmware vendors to include their certificates. Part of my job has been to bridge the communication between the shim-review community and the team at Microsoft that signs the shim binary during this transition.
The Microsoft Corporation UEFI CA 2011 certificate expired on June 26, 2026 (or June 27, depending on time zone). It is being replaced by the Microsoft UEFI CA 2023 certificate, which does not expire until 2038. This will not cause existing systems (e.g., those that have booted successfully before the expiration) to stop booting; however, a system can fail to boot if it does not have the new certificate in its trust store and receives a new shim (via a system upgrade or new installation) that is signed with that certificate.
Note that there are multiple 2011 certificates used as trust anchors for various trust paths. As a family, the certificates begin expiring in June with the Windows Secure Boot certificates expiring last, in October. For Linux, the certificate that matters is the one that expired on June 26.
How expiration impacts Linux
Firmware is generally designed to ignore certificate expiration when
evaluating whether a signature is valid. The UEFI
specification's image-validation process bases the trust decision on whether
the image's signing certificate is present in the authorized database
(db) and absent from the forbidden database (dbx). It
does not check a certificate's validity period. The intermediate certificates
used to sign UEFI binaries have already expired without
consequence. Any shim that is signed with the 2011 certificate
will continue to work as it did before, barring a bug in a system's
specific firmware implementation.
In October 2025, Microsoft began returning two signed binaries for each shim submission. One is signed with the 2011 certificate, and the other one is signed with the 2023 certificate. That overlap ended with the certificate expiration. Future submissions can only receive the 2023 signature, leaving distributors to decide whether to ship a dual-signed shim while they still can, or to move directly to a 2023-only shim. The latter choice is safe only for systems whose firmware already trusts the 2023 certificate.
The focus of this article is on shim, however, option ROMs—UEFI binaries that are loaded into peripherals such as graphics cards and executed during the preboot phase—have a similar exposure.
Forced update
The UEFI boot environment has attracted increasing security scrutiny. Vulnerabilities are occasionally discovered in shim, GRUB, and other boot-chain components just like other software. If a vulnerability is discovered in shim itself that requires a code change and a new binary, that new binary can only be signed with the 2023 certificate.
Therefore, the practical window for relying on the old 2011-signed shim is the time between now and the next security vulnerability or distribution release that forces a shim respin. Matthew Garrett has argued that the transition is less urgent than some descriptions suggest: in many cases, a system could boot older media, update its trust database, and then install or boot newer media. That path exists, but it is not sufficient for every environment. Systems with strict uptime requirements, restricted boot-media policies, or remote-only access may not have that option.
For most users running a maintained distribution on maintained hardware or a maintained virtualization layer, the distribution will manage this transition. The Linux Vendor Firmware Service (LVFS) and fwupd provide a mechanism for delivering firmware updates, including Secure Boot trust-database updates.
The systems that need attention are those where that path does not work: hardware where the vendor no longer supports the model or has stopped publishing LVFS updates, and virtual machines provisioned before cloud or virtualization providers enrolled with the 2023 certificate that have not received subsequent firmware updates. For those systems, mokutil can report whether the 2023 certificate is enrolled, and tools such as pesign or sbverify can show which certificate signed an installed shim. See this post for information on upgrading.
LVFS maintains its own compatibility data and can target updates to specific hardware configurations. Microsoft has published a dataset of device configurations where the 2023 certificate update has been confirmed to apply successfully, derived from Windows fleet telemetry and made available for Linux distributions and other non-Windows operating systems to use.
That compatibility work matters because forced trust database updates are not safe on all hardware. Forced updates have left some machines unbootable. On certain hardware, recovery requires physical access, and in some cases we have observed that systems were permanently damaged.
The distribution and the compute vendor are the best sources of current status and guidance. The shim-review community is not a support channel for individual systems, and Microsoft can only assist with its own compute platforms and operating systems.
Overall, the result is less an immediate, deadline-driven outage and more of a preventative-maintenance problem; system administrators need to take action to avoid running into a situation where a system may eventually stop booting, but the certificate expiry does not automatically mean systems will no longer boot the instant the certificate expired.
The systems most likely to have trouble are not the newest or most carefully managed systems; they are the ones stranded outside the normal firmware-update machinery when a future shim update becomes necessary.
| Index entries for this article | |
|---|---|
| GuestArticles | (bex) Exelbierd, Brian |