Microsoft’s legacy Secure Boot signing certificate is nearing expiration, initiating an important transition that impacts the wider Linux ecosystem.
The Microsoft UEFI Certificate Authority from 2011, widely used in the Secure Boot chain on standard PCs, will expire this June, and Linux distributions must move their shim signing path to the newer 2023 CA.
This is significant for the Linux ecosystem, as many distros depend on a Microsoft-signed bootloader (called shim) to start Linux on Secure Boot-enabled machines – a firmware feature that ensures only trusted software runs during startup.
Long story short: when a computer powers on, the firmware verifies that the initial boot component is signed by a trusted key. If valid, the boot process continues; if not, the firmware blocks it.
For Windows, this process is seamless because PC firmware typically trusts Microsoft’s keys by default. Most Linux distros, however, are not directly trusted by firmware on consumer and enterprise PCs.
To address this, many use shim, a small first-stage UEFI bootloader signed by Microsoft. The firmware trusts shim, which then verifies subsequent Linux boot components, such as GRUB and the kernel, using the distribution’s own keys.
Most existing systems are expected to continue booting after the old certificate expires. Importantly, expiration does not remove the old key from firmware or revoke already trusted bootloaders. Therefore, a Linux system that boots today with Secure Boot enabled should not fail solely due to the certificate’s expiration.
The main risk lies in the transition period. New Linux installation images, updated shim packages, rescue media, older hardware, dual-boot systems, and machines with outdated Secure Boot databases may run into issues if they do not recognize the newer 2023 Microsoft UEFI CA. Removing the old 2011 key prematurely can also cause boot problems.
This is critical because Secure Boot depends on a chain of trust. Each stage must recognize and trust the next. If the firmware does not trust the key used to sign the shim, the shim will not start, and the Linux bootloader and kernel cannot proceed through the Secure Boot process.
For users, the key advice is to keep the operating system, shim packages, firmware, and Secure Boot database updates up to date as provided by distributions. Remember, avoid manually changing Secure Boot keys unless directed by a vendor or distribution.
If Microsoft is in your chain of ‘trust,’ you already have some insurmountable problems.
I’m not begging Microsoft for the ability to use my computer. Nobody else should, either.
Secure Boot is a problem looking for victims. This is how Mirosoft operates. Take a look at their history.
Turn it off, never look back.
This is why windows isnt on my systems, secure boot isnt even relevant now for me
U should ask your self: Why is that so ? Hardware vendors have commit end user betrayal with MS allowing to tamper bios, thats why we have now problems ! Instead of secure boot is in end user hand its in MS hands (not all hardware affected) !
Just another way Microslop wants to control your PC and your whole life. Soon someone is going to try and make secure boot the only option with no way to turn it off. Thank God for the open source community.
My custom secure boot kicks M$ and trusts my linux bootloader.
Check secureboot state with
mokutil –sb-state
Check the installed certificates with
mokutil –db –short
mokutil –kek –short
Update your firmware (possibly containing updated certificates) with
fwupdmgr refresh –force ; fwupdmgr get-updates ; fwupdmgr update
This didn’t work for me, this worked:
Check the installed certificates with:
mokutil –db | grep Microsoft
mokutil –kek | grep Microsoft
Secure boot is just a huge unessarry pain in the ass
This is why I don’t use secure boot. Anything tied to Micro$lop has to go!
“A chain is only as strong as its weakest link.” I heard that somewhere.
“Chain of trust”
“Microsoft”
Hmmmm…..
“secure boot” Of course.
Your computer’s funeral then, dude. Given the number of flaws being found in Linux lately, don’t come crying when it gets infected.
That’s a great response from someone ignorant of how useless secure boot really is. If you have access to the hardware then game over. It has nothing to do with ‘infection’.
Linux flaws get fixed before they can be exploited. That’s not the case with Microsoft Windows. No wonder why there’s a lot of trojan viruses in MS world.
CopyFail Flaw (CVE-2026-31431) 9yrs old and Claude Code Found a Linux NFS Vulnerability Hidden for 23 Years
With respect,
This exploit wasn’t being used by anyone, since nobody knew of its existence. Claude finding it was a good thing, as it was patched in the same week before anyone actually learned how to exploit it.
Keep your respect, and perhaps try to understand better what you are talking about instead of trying to make denigrating statements. Nobody was affected by this, by the way.
Yeah rhat’s my advice too, for running Linux I would just turn off secure boot. if you’ve got someone poking around as root you’re done for anyway, and if not they can’t load kernel modules anyway. This is the one big thing secure boot prevents on linux, loading unsigned kernel modules. Well or replacing your kernel of course.
Never heard of privilege escalation? But yeah, if they have root you’re probably in for a bad time. Some kernel lockdown features require Secure Boot though, so you might be enabling a path to root.
If you’re talking about a home PC, then the risk probably isn’t there. But for servers at work, best of luck.
I don’t use secure boot.
That’s really stupid. Easy way to be hacked and never even know.
I was trying to delete that comment above as it was meant to be a reply. The only way to do secure boot is to create your own custom keys.
Agreed. Do people really think that it is a challenge for a malicious actor to sign a bootloader with a key that is a decade old? Let alone considering who the source of the key is.