> [...] systems that only trust the new certificate and not the old one would refuse to boot older Linux, wouldn't support old graphics cards, and also wouldn't boot old versions of Windows. Nobody wants that [...]
EVERYBODY wants that! And I mean ABSOLUTELY EVERYBODY! Updates are now mandatory everywhere, in both Windows and Linux, and GPU manufactureres would LOVE to make the old cards obsolete, even if technically the new cards aren't much better.
So expect to see the old certificate invalidated quickly and automatically, in the name of security, of course!
Recent and related:
Linux and Secure Boot certificate expiration - https://news.ycombinator.com/item?id=44601045 - July 2025 (265 comments)
the steps to import the new keys from microsoft are here:
https://techcommunity.microsoft.com/blog/windows-itpro-blog/...
worked perfectly on a fully updated Windows 11 24H2 installed on an old Surface Pro LTE i5-7300U that is perhaps unlikely to receive another firmware update...
There is also the option of enrolling your own certs and resigning the bootloader and any Option ROMs you need, if you're really worried / expect to actually be broken by this.
The moment I lose access to my computer or data due to this nonsense is the day I have a Stallman moment and refuse to play. I'll use a Chinese risc-v machine with 5 year old performance or whatever. This stuff has lived in the far background of my mind for years with thoughts like "fedora somehow handles this so I don't need to worry." But if it hits I'm done. Won't support such hardware ever.
> So, uh, what's the story here? Why is there any engineering effort going on at all? [...] Microsoft will shortly start signing things with a new certificate that chains to a new root, and most systems don't trust that new root. [...] If something is signed purely with the new certificate then it won't boot on something that only trusts the old certificate (which shouldn't be a realistic scenario due to the above), but if something is signed purely with the old certificate then it won't boot on something that only trusts the new certificate.
So, dumb question: If the expiry dates are not enforced, why rotate the certificates at all? The only consequences of Microsoft introducing new keys seems to be that compatibility with old software and systems will over time become worse. But what's the upside - or the actual threat model this is defending against?
yeah, that sounds about right for UEFI
Can someone knowledgeable on the subject explain if I understand the following right:
- on a mobo the motherboard provider signs the PK
- there's only one PK
- the PK signs one or more KEK, like "Microsoft Corporation UEFI CA 2011"
If I add the new Microsoft key myself, shall it be as a KEK or in the dbx?
Will motherboard manufacturer release new firmware, with the new Microsoft key already signed? In that case, shall be a KEK ?
Basically instead of thinking, as TFA suggests: "Let's not worry about anything, everything shall be fine and keep working because keys expiration date aren't enforced", can I pro-actively enroll the new Microsoft key myself?
P.S: I don't drink the SecureBoot kool-aid but something has to be said about having a Linux unikernel (kernel+initramfs) signed and enforced by SecureBoot. And SecureBoot does at least somehow work. Source: I modified on bit of my kernel and had a SecureBoot error and the kernel refused to boot. You can try it for yourself.
This article notes that "nobody actually enforces these expiry dates". So this is another way that secure boot is proven to be nowhere as secure as it claims to be. Coupled with LogoFAIL and most hardware shipping with insecure debug keys.. has Secure Boot ever provided meaningful security? It sure causes all sorts of practical problems.
https://arstechnica.com/security/2023/12/just-about-every-wi...
https://arstechnica.com/security/2024/07/secure-boot-is-comp...