Linux and Secure Boot certificate expiration (2025)

They left out the steps to update it. I made a rough attempt at a document for this. [1] Please let me know if I missed a validation step. I have done this on six machines but they were all Linux. Not tested on BSD.

Archive [2] in the event I was too aggressive in blocking bots.

[1] - https://nochan.net/b/Internet-Crap/20260621-Update-Secure-Bo...

[2] - https://archive.is/ml3jv

> triggering a "de-fragmentation" of the available efivar space so that there's enough contiguous space to deploy the update.

I didn't even realize this could be a problem despite the next paragraph implying it's very well known.

I saw 2-3 flavors of this news. None of them include a basic “how do I check if I need to do anything” guide that a linux newbie can do.

Well, it seems like keeping secure boot disabled was gonna help me in the future haha

I know it is not recommended but the options to have my own keys seemed a bit of a hack than a solution.

Last time I installed Arch, I put Secure Boot in setup mode and enrolled by own keys. The idea of using someone else's keys seems absurd.

> The KEK updates are going out at ~98% success, and db update is ~99% success

glad to see the opt in fwupd analytics being so useful for something like this

Not envious of the running around contacting vendors they must of been doing on such short order.

What is the convincing reason that MicroSlop is the trusted party to sign the shim with their (presumably NSA-blessed key)? Why is there no charitable equivalent like a small/mini LetsEncrypt foundation for the PKI aspect of Secure Boot? I also do not see a convincing reason it meaningfully improves security posture.

Discussed at the time (of the article):

Linux and Secure Boot certificate expiration - https://news.ycombinator.com/item?id=44601045 - July 2025 (265 comments)

I'm surprised more people aren't freaking out about this. It seems likely a whole lot of Linux machines are going to fail to reboot in the next few months. The problem affects VMs too. I was grateful Proxmox put a little warning in its hypervisor GUI with a button to press to fix the BIOS of its VMs.

Secure Boot has been deeply broken for years, not providing meaningful security on most consumer machines.

How do desktop Linux distros avoid attackers from rolling back the operating system to a vulnerable, but signed version?

[dead]

It needs to be said, this is what you get by "trusting" Microsoft.

There really is no need for secure boot in Linux. The only reason to have it is if you dual boot because M/S says so. If using Linux by itself, just disable secure boot and have done with it.

The word from Red Hat is existing systems will continue to boot — presumably because they are time-stamped and counter-signed or because the dates are ignored entirely.

99% of secure boot discussions are drowned out by people who don't have a clue what they're talking about, yet are spittingly, furiously mad.

They've also had over a year to prepare for this so if Linux distros are only telling you now, that's on them.