Discussed at the time (of the article):<p><i>Linux and Secure Boot certificate expiration</i> - <a href="https://news.ycombinator.com/item?id=44601045">https://news.ycombinator.com/item?id=44601045</a> - July 2025 (265 comments)
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.<p>Archive [2] <i>in the event I was too aggressive in blocking bots.</i><p>[1] - <a href="https://nochan.net/b/Internet-Crap/20260621-Update-Secure-Boot-Cert-Before-It-Expires/" rel="nofollow">https://nochan.net/b/Internet-Crap/20260621-Update-Secure-Bo...</a><p>[2] - <a href="https://archive.is/ml3jv" rel="nofollow">https://archive.is/ml3jv</a>
FYI your server returns Brotli encoded content, even if the request has only Accept-Encoding: gzip, deflate, zstd - making it unreadable in for me (Firefox on Fedora).
Found this on one machine. Key expires in 5 days. System runs Linux only and has never booted Windows, ever. Secure boot may be off.<p><pre><code> SHA1 Fingerprint: 46:de:f6:3b:5c:e6:1c:f8:ba:0d:e2:e6:63:9c:10:19:d0:ed:14:f3
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
61:08:d3:c4:00:00:00:00:00:04
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
Validity
Not Before: Jun 27 21:22:45 2011 GMT
Not After : Jun 27 21:32:45 2026 GMT
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011</code></pre>
I had to vouch your comment, not sure what happened there. Something in your technical output must have triggered HN. One can use mokutil to see if Secure Boot is enabled after installing it. I assume the OEM installation or update of the BIOS must have included that cert but I am just guessing.<p><pre><code> mokutil --sb-state</code></pre>
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.
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.
On my Fedora machine I was able to run<p><pre><code> mokutil --db --short
</code></pre>
To check my secure boot keys. As long as there's 2023 Microsoft keys you should be fine. Otherwise, my understanding is that you just need to update your firmware, but please somebody correct me if I'm wrong.
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.
In 2012, Windows 8 stopped booting on computers without UEFI secure boot. Hardware companies weren’t enthusiastic, but they couldn’t ignore Microsoft’s demand. Microsoft published the spec for how Windows 8 would handle secure boot, and that included the crypto key that will be expiring in September. Microsoft’s spec did actually have provisions for non-Microsoft operating systems.<p>Linux developers didn’t all agree about whether Linux needed to do anything about Microsoft’s plan, but ultimately a Red Hat programmer convinced enough people that it would be easier to follow Microsoft’s spec than to tell new users to “turn off secure boot” if they wanted to run Linux ( <a href="https://mjg59.dreamwidth.org/12368.html" rel="nofollow">https://mjg59.dreamwidth.org/12368.html</a> ). This wasn’t a popular decision, and it hasn’t become any more popular over time, but it has worked.
You can load your own Secure Boot keys and sign your bootloader yourself; as for why the Microsoft ones are preloaded, probably because they're the only entity that interacts with all of these OEMs and had enough leverage over them to force Secure Boot adoption in the first place.
It's not exactly new for Microsoft to slide themselves in somewhere and become the "standard" before anyone has really thought about how terrible their products are.
I mean, NSA-blessed or not, the way this happened was not some hidden conspiracy. It was in the open. The reason it happened is all of these machines are basically made to run Windows, so they need to have Microsoft keys. Microsoft was pushing for Secure Boot, for security and "trusted computing" (evil or good, depending on your PoV, and open source complained that this is a way to lock in users to Windows, so the compromise choice was to have them sign a GRUB shim so that Linux could just as easily be run without enrolling your own keys.
It's for your own security, duh ;)
> presumably NSA-blessed<p>You have your answer
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.<p>Secure Boot has been deeply broken for years, not providing meaningful security on most consumer machines.
> The KEK updates are going out at ~98% success, and db update is ~99% success<p>glad to see the opt in fwupd analytics being so useful for something like this<p>Not envious of the running around contacting vendors they must of been doing on such short order.
It needs to be said, this is what you get by "trusting" Microsoft.<p>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.