We’ve already talked about the secure boot certificates from Microsoft that are about to become invalid, but Debian EFI team member and longtime Debian contributor Steve McIntyre published a blog post with more information for users and distribution developers alike. Why are Microsoft’s secure boot certificates relevant for the Linux world? Well, Linux distributions use shim to provide secure boot functionality, and this shim is signed with Microsoft’s certificates, because they are included in just about every single computer or motherboard ever shipped.
The expiration of these oldest certificates should most likely not be a problem, as existing signed binaries should keep working. This is because the UEFI specification does not look at the expiration dates; it only cares that the signature is valid. Unless you have buggy firmware, your machine will continue to boot Linux just fine.
Microsoft is already handing out new certificates, but they started the rollout of these way too late, so that’s why it’s an actual issue today.
New machines and updated older machines will most likely have all of these new CAs installed. New machines are already shipping that only include the new CAs; they will not trust older software and this has already started causing problems for some users.
[…]
If you already have an old shim signed by Microsoft for your distribution from before October 2025, then it will only be signed using the older CA that expires soon. On newer machines, your users will already not be able to boot your distro with Secure Boot enabled.
If you want your users to be able to use Secure Boot in future, you will need to get a new shim build submitted, reviewed and signed using the new CA. However, that signed build will not work on older machines unless they have had the new CAs installed. This is also likely to cause problems for some users. You should encourage your users to update their systems NOW before things break for them.
↫ Steve McIntyre
I think the Linux world will be able to handle this just fine, but the fact that Microsoft started this process of replacement so late is a real shame. I’m by no means an expert in this field, but I wonder if there isn’t some better solution than relying on Microsoft. I understand their certificates will effectively always be installed on every motherboard, but shouldn’t we be able to move that responsibility to a more independent entity?
@thom-holwerda What do you mean by, “Microsoft started this process of replacement so late”? They’ve been announcing this, for years at this point. They started this all the way back in 2023 in response to the Black Lotus UEFI attack, then slowly felt out how to install the new signing keys across a massively heterogeneous software and hardware environment for two years, before finally deeming it ready last year.
https://support.microsoft.com/en-us/topic/how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d#ID0EFP
And even still there are systems that choke on installing it due to non-spec behavior in their firmware,
If the signing keys aren’t trusted, then signing things with them will only cause issues, so I can easily understand why they’d delay until they got that (broadly) figured out.
This is not something they started late on. It just turns out to be much harder than the industry anticipated to install new certs into the Secure Boot DB of hundreds of thousands of different devices, running different firmware versions and different OSs. The enormous PITA of this process was likely one of the drivers for Microsoft to create Pluton.
Read the linked article:
Yes! The solution is called “shipping your own hardware (with your own Desktop Linux desktop pre-installed)” and by “shipping” I don’t mean built-to-order systems from some obscure website such as System76 but hardware available on the store shelves of major Main Street shops such as Best Buy.
Simply put, relying on hardware designed to run a competitor’s OS (Windows) to run your OS means the hardware vendor will strive to meet the arbitrary requirements defined by your competitor (Microsoft), even if meeting those arbitrary requirements (for example, Secure Boot) means making it harder for users to run your OS (on top of the fact that installing an OS is already difficult for most users).
Generally, one of the things I find very off-putting with Desktop Linux is that too many of the problems boil down to “the distro vendor can’t afford that”. From not having hardware available on the store shelves of major Main Street shops, to not being able to pay royalties for FRAND codecs, to not being able to pay some developers to make sure the latest version of Photoshop and Microsoft Office run well under Wine. Why would I want an OS from such a financially feeble OS vendor? In fact, let me be less polite: Why would I want to associate myself with an OS vendor that reeks of financial desperation and general poorfag-ness? This is an OS, the foundation of my digital home, not some dinky little utility app.
If I undestand your point, you’re asking for every machine having their OS’ key, which is not a solution.
What if I buy a Dell which comes with Ubuntu and I want to install Fedora on it?
We need a central signer but not Microsoft or any other company, maybe some sort of Secure Boot Alliance.
Otherwise manufacturers (or worse, users) will end up having to install MS keys, RH keys, Canonical keys, Suse keys, …
That sounds like something right up the Linux Foundation’s alley.
Enforcing Secure Boot by default is not a requirement of UEFI, enforcing Secure Boot by default is a requirement that Microsoft imposes on OEMs shipping PCs with Windows pre-installed (which comes back to the “hardware vendor will strive to meet the arbitrary requirements defined by your competitor” thing I said above).
If you disable Secure Boot enforcement in UEFI, the OS will boot even if the certificate is not recognized by UEFI, so it’s reasonable to assume that a laptop that doesn’t come with Windows pre-installed will have Secure Boot enforecement disabled by default.
As an aside, there is no such thing as an “Ubuntu UEFI certificate” and “Fedora UEFI certificate”, all major Linux distros use the “3rd Party UEFI CA” provided by Microsoft (and the one article is about), because that’s what most laptops recognize (though some laptops like Lenovos have the acceptance of this “3rd Party CA certificate” disabled by default in the UEFI settings (see here for details). But in a world where PCs that don’t ship with Windows were common, it’s reasonable to assume that Linux Foundation would have standardized a common certificate for all major Desktop Linux distros. But again, such certificate is not needed in the current market, Microsoft’s “3rd Party UEFI CA” it is.
OS Install mode. Every machine has its own root keys, or the OS installer injects the key to be trusted. A central signer is only a way to lock you out of your machine.
Yes I do roll my own keys. Yes it’s way too complicated. No, I can’t boot anything else without disabling SecureBoot.
That of course assumes that the UEFI will allow you to disable Secure Boot, which in turn assumes that Microsoft won’t come up with a new rule that says “Secure Boot must always be enabled and cannot be disabled in the UEFI settings” for OEMs shipping laptops with Windows pre-installed (which isn’t too far-fetched btw, they already mandate that Secure Boot be enabled by default). In fact, Microsoft can even mandate the non-acceptance of the Microsoft 3rd party UEFI CA they themselves created if they want to be extra petty.
And if that happens, you are locked out, your PC will only boot “approved” OSes. In fact, such a change can ship on existing PCs as a UEFI update (though this is highly unlikely compared to just imposing it on new PCs).
And this is why relying on hardware designed primarily to run a competitor’s OS (Windows) is a huge strategic mistake for the Canonicals and RedHats. Again, I know System76 exists, it doesn’t matter.
You could have reduced this comment to “Phones” 😀 locked bootloaders, signed software, walled gardens.
“Microsoft is already handing out new certificates, but they started the rollout of these way too late, so that’s why it’s an actual issue today.”
As usual an other coordination problem within Microsoft, just like we’ve seen from things like domain name and certificate expiration over the years.
> I understand their certificates will effectively always be installed on every motherboard, but shouldn’t we be able to move that responsibility to a more independent entity?
Nowadays more and more devices are available that use Coreboot. Those do not have any of these problems and also have better compatibility as one can always use a SeaBIOS payload and boot up operating systems that rely on BIOS support.
With anything that involves high level security, Coreboot is a must. UEFI firmware generally is proprietary and full of (supply chain) security issues.
I just disable secureboot, since i dont want anything to do with microsoft.
> I understand their certificates will effectively always be installed on every motherboard, but shouldn’t we be able to move that responsibility to a more independent entity?
can’t wait for this to be added to systemd