Linux and Secure Boot certificate expiration [LWN.net]
LWN<br>.net<br>News from the source
Content Weekly Edition<br>Archives<br>Search<br>Kernel<br>Security<br>Events calendar<br>Unread comments
LWN FAQ<br>Write for us
Edition Return to the Front page
User:<br>Password: |
Log in /<br>Subscribe /<br>Register
Linux and Secure Boot certificate expiration
We're bad at marketing
We can admit it, marketing is not our strong suit. Our strength is<br>writing the kind of articles that developers, administrators, and<br>free-software supporters depend on to know what is going on in the<br>Linux world. Please subscribe today to help us keep doing that, and so<br>we don’t have to get good at marketing.
By Jake Edge<br>July 16, 2025
Linux users who have Secure Boot<br>enabled on their systems knowingly or unknowingly rely on a key from<br>Microsoft that is set to expire in September. After that point, Microsoft<br>will no longer use that key to sign the shim<br>first-stage UEFI bootloader that is used by Linux distributions to boot the<br>kernel with Secure Boot. But the replacement key, which has been available<br>since 2023, may not be installed on many systems; worse yet, it may require<br>the hardware vendor to issue an update for the system firmware, which may<br>or may not happen. It seems that the vast majority of systems will not be<br>lost in the shuffle, but it may require extra work from distributors and<br>users.
Mateus Rodrigues Costa raised<br>the issue on the Fedora devel mailing list on July 8. He had noticed a<br>warning that came with "this month's Windows 11 cumulative<br>update"; it talked about Secure Boot certificates that are scheduled to<br>expire starting in June 2026. Those particular certificates<br>are separate from the one used for shim, which expires much sooner. In any<br>case, the problem of certificate expiration is one that the Linux world<br>will need to tackle.
The situation is rather complicated. Daniel P. Berrangé pointed to a page at the<br>Linux Vendor Firmware Service (LVFS) site<br>that describes it. LVFS is the home of fwupd<br>and other tools that are used to update system firmware from Linux. LVFS<br>and fwupd are the subject of an LWN article from 2020.
There are multiple moving parts to the problem. In order to do a Secure<br>Boot into the Linux kernel, the UEFI boot process requires the first-stage<br>bootloader to be signed with a key in the<br>firmware database that has not expired. Those keys are contained in<br>certificates, which have other information, such as an<br>expiration date and signature(s). The certificate expiration should largely only be a problem<br>when installing a new distribution on a Secure Boot system; the shim that gets installed<br>will have distribution-specific keys and can act as the root of trust for<br>running other programs (e.g. GRUB) using<br>those keys.
Currently, shim is signed with a Microsoft key from 2011 that expires on<br>September 11. Past that point, installation media will no longer boot<br>unless it has an updated shim that is signed with the Microsoft 2023 UEFI<br>key for third-parties (which is different than the specific key mentioned<br>in the Windows update). Any installed distribution should have a<br>bootloader signed with its own key that will continue to boot.
But there are lots of systems out there with a firmware database that lacks<br>Microsoft's new key, some have both old and new keys, while<br>there are likely some that only have the new key and cannot Secure Boot Linux<br>installation media at all at this point. Vendors can (and hopefully most<br>will) provide firmware updates that add the new key, and installation<br>media can be created with a shim signed by it, but those updates have to<br>be installed on systems. That's where LVFS and fwupd come in.
LVFS is a repository of vendor-firmware updates of various sorts, which<br>fwupd and other tools can use to install the pieces that are needed<br>into the firmware from Linux.<br>Berrangé noted that older versions of fwupd were unable to solve all of<br>the problems, "but recent releases<br>have been enhanced to handle the updates that Linux users will need<br>to see, which should mitigate the worst of the impact". There may<br>still be a bit of a bumpy ride, however: "Users should be 'aware' of the potential for trouble,<br>but hopefully the worst of the 'worry' part is handled by the OS vendors<br>and maintainers."
LVFS creator and maintainer Richard Hughes agreed,<br>noting that there were various ways that people's systems would be able to<br>get updated Secure Boot functionality. A full firmware update might be<br>provided by the vendor, which would (presumably) add the new database,<br>including the new Microsoft key. Another avenue would be a "key exchange key"<br>(KEK) update, which is a vendor-specific key that is signed by the<br>Microsoft key; it can be used by fwupd to update the database with the new key. But there are some<br>caveats:
The KEK updates are going out at ~98% success, and db update is ~99%<br>success -- but even 1% multiplied by millions of people is a fair few<br>failures to deploy -- the "failed to write efivarfs" thing. What fixes...