Microsoft’s UEFI root certificates for Secure Boot are expiring within weeks, threatening bootability on newer hardware for Linux distributions that still rely on the old shim signatures. The Debian EFI team outlines the timeline, the new Microsoft CAs, and a pragmatic path forward—dual‑signed shims—to keep both legacy and modern machines bootable.
Secure Boot Certificate Rollover: Why Distributions Must Act Now
By Steve Miller, Debian EFI team member
Friday, 22 May 2026
Thesis
Microsoft’s UEFI root certificates that underpin Secure Boot are set to expire in the next five weeks. If Linux distributions continue to ship shims signed only with the aging certificates, a growing segment of newer hardware will refuse to boot their installers. The solution is to obtain dual‑signed shim binaries that carry signatures from both the legacy and the newly‑issued Microsoft CAs, thereby preserving compatibility across the full spectrum of machines.
The imminent expiry problem
Secure Boot works by validating a chain of X.509 certificates that start in the firmware’s embedded Microsoft root. Two of those roots—Windows Production PCA 2011 and Third Party Marketplace Root—were created in 2011 and will expire on 19 Oct 2026 and 27 Jun 2026 respectively. The latter, which is the trust anchor for the shim binaries used by most Linux distributions, will become invalid five weeks from today.
The UEFI specification does not require firmware to reject signatures whose signing certificates are past their Not‑After date, so existing installations will not instantly fail. However, newer firmware that ships only the new Microsoft CAs (generated in 2023) will not recognise the old shim signatures at all, resulting in an immediate boot block for users who have not updated.
The new Microsoft CAs
Microsoft has already published three replacement root certificates:
- Microsoft Option ROM UEFI CA 2023 – valid until 2038, for signing device option ROMs.
- Windows UEFI CA 2023 – valid until 2035, for Windows components.
- Microsoft UEFI CA 2023 – valid until 2038, for third‑party software such as shim.
All new hardware ships with these roots pre‑installed, and firmware updates for older machines are beginning to add them as well. Consequently, a distribution that continues to ship a shim signed only with the 2011 root will be unable to boot on any system that lacks the legacy root.
What distro maintainers must do
- Obtain a new shim build signed with the 2023 Microsoft UEFI CA. This requires submitting the binary to the shim‑review team, which will then forward it to Microsoft for signing.
- Publish dual‑signed shims: Microsoft now returns two signed binaries for each submission—one with the old CA and one with the new CA. By extracting both signatures and attaching them to a single shim, maintainers can produce a dual‑signed binary that satisfies both old and new firmware.
- Update installer images: Replace the existing shim in all installer and live images with the dual‑signed version. This step must be completed before the 27 June 2026 deadline.
- Communicate to users: Encourage users to update their systems now, before the old CA expires, and explain the need to reinstall the latest installer if they are on a machine that already lacks the legacy root.
The dual‑signing process is not without risk. Some buggy firmware implementations have trouble handling multiple signatures in a single PE file, but early testing with Fedora’s dual‑signed shim showed no adverse effects. Distributions should therefore include a fallback plan—maintaining a separate legacy shim for the few machines that still exhibit firmware bugs.
Implications for the broader ecosystem
- User experience: A smooth transition preserves the “just works” promise of Secure Boot for Linux users, preventing a wave of boot failures that could erode confidence in the platform.
- Distribution workload: Maintaining two shim binaries, two installers, and two sets of images would double the effort for each release. Dual‑signing consolidates this burden into a single artifact, albeit with a more complex build step.
- Vendor coordination: The late timing of Microsoft’s key roll‑out highlights the need for tighter coordination between firmware vendors, Microsoft, and the open‑source community. Future rollovers should follow the “half‑life” rule to avoid last‑minute scrambles.
- Security posture: The new CAs extend the trust window to 2035‑2038, reducing the frequency of such disruptive rollovers and giving maintainers a longer horizon to plan updates.
Counter‑perspectives and mitigations
Some administrators argue that disabling Secure Boot on affected machines is a simpler workaround. While technically feasible, this approach undermines the security guarantees that Secure Boot provides—namely, protection against unsigned or malicious bootloaders. Moreover, many enterprise policies mandate that Secure Boot remain enabled, making a blanket disablement untenable.
Another possible mitigation is to rely on vendor‑specific keys (e.g., Dell’s or Lenovo’s custom Secure Boot keys). This sidesteps Microsoft’s root entirely but introduces fragmentation, as each vendor would need to maintain its own key lifecycle and distribution channels.
Both alternatives increase operational complexity and reduce the universality that the Microsoft‑rooted model offers. The dual‑signed shim strategy therefore remains the most pragmatic path forward for the majority of Linux distributions.
A call to action
The clock is ticking: five weeks remain before the legacy Microsoft CA expires. Distribution maintainers should:
- Submit a new shim build to the shim‑review team today.
- Generate a dual‑signed shim and integrate it into the next release image.
- Publish clear upgrade instructions for users on both legacy and modern hardware.
If you are unsure how to proceed, reach out to the shim‑review team (see the Debian wiki) for guidance. Early preparation will spare users the frustration of a broken boot process and keep the Linux ecosystem securely bootable across the entire hardware spectrum.
References
- Microsoft’s repository of Secure Boot objects, including the new CA certificates: https://github.com/microsoft/secureboot_objects
- Debian’s Secure Boot documentation (ongoing updates): https://wiki.debian.org/UEFI/SecureBoot
- Shim‑review team information and submission guidelines: https://wiki.debian.org/UEFI/SecureBoot/ShimReview
Comments
Please log in or register to join the discussion