Archive [2] in the event I was too aggressive in blocking bots.
[Edit] I should also include this [3] thread for completeness sake. Some people people were playing with a shim work around but it looks like a lot of unnecessary complexity and fragility to me.
[1] - https://nochan.net/b/Internet-Crap/20260621-Update-Secure-Bo...
[2] - https://archive.is/ml3jv
[3] - https://www.reddit.com/r/archlinux/comments/1pvw6td/grub_shi...
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 mokutil --sb-stateJust checked. Secure Boot is not enabled on any of my machines, which are Linux-only. Whew!
(I wonder if any of the ASUS subnotebooks I bought off eBay for minor embedded stuff have this problem. Have to power them up.)
mokutil --db --short
I didn't even realize this could be a problem despite the next paragraph implying it's very well known.
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.
The threat model secure boot was actually designed to protect against is not someone else booting a different OS in your hardware; the real threat model it protects against is malware loading before the OS can start the antivirus. With UEFI, malware could in theory run even when you boot from your OS install media, making it much harder to detect and remove. That's the reason installing your own secure boot key requires a one-time confirmation through a physical input device (which malware can't fake).
Unfortunately, protecting against that threat model (persistent malware loading before the OS) created another threat model, which IMO is a bigger worry: that you could one day be forbidden from running your own OS in your own devices. AFAIK, there have already been a few devices where secure boot cannot be disabled, your own secure boot keys cannot be enrolled, and the "third party" (aka "non-Microsoft") key is not available.
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 ( https://mjg59.dreamwidth.org/12368.html ). This wasn’t a popular decision, and it hasn’t become any more popular over time, but it has worked.
I hope the firmware either doesn't check the expiry date or that the firmware itself has been upgraded, or several years worth of Thinkpad are about to stop booting in the near future.
Not to say that having Microsoft as the custodian of the keys preloaded on all PCs is the optimal solution, but I don't think a token yes/no to add any random key on boot is a good idea either.
For OEMs, presumably the stranglehold they have on them via Windows. For users, not much, but none of the ones making these decisions really care about that.
shim didn't exist at first. Linux was planning to go without until Red Hat's hand was forced likely because their paying customers demanded it.
> Why is there no charitable equivalent like a small/mini LetsEncrypt foundation for the PKI aspect of Secure Boot?
This would be pointless and erode the security of the system. Users who care can already remove Microsoft's root keys and enroll their own. There's a small corner case with UEFI Extensions / device firmware, but in this case a lightweight "sign everything" foundation would only serve to erode the security of the system. The problem space is completely orthogonal to website SSL and by and large simply good and not bad when properly configured.
> I also do not see a convincing reason it meaningfully improves security posture.
Secure boot paired with secure boot-sealed disk encryption massively reduces attack surface; with only Secure Boot-sealed keys (ie, BitLocker default), it reduces attack surface for the data on your disk to "post-boot authentication bypass or RCE" from "literally anyone or any piece of software who touches your computer or a disk that came out of it, ever." With keys sealed by Secure Boot and sealed or even just stretched by another mechanism (password, PIN, etc.), it reduces attack surface to "machine unlocked."
> MicroSlop is the trusted party to sign the shim with their (presumably NSA-blessed key)
I've been on Hacker News for an extremely long time and respect the community wish to avoid meta-discourse in general, but this kind of rubbish discourse with weird slurs and unfounded conspiracy theories is getting horrendous lately; I wish this site could more collectively move towards a productive curiosity rather than evidence-free statements based on arbitrary prejudice.
You have your answer
Linux and Secure Boot certificate expiration - https://news.ycombinator.com/item?id=44601045 - July 2025 (265 comments)
Secure Boot has been deeply broken for years, not providing meaningful security on most consumer machines.
https://mjg59.dreamwidth.org/72892.html (Secure boot certificate rollover is real but probably won't hurt you)
https://wiki.debian.org/SecureBoot/CAChanges#OMG.21.21.21_Wi...
Does this means that updating my system kernel would fail or even break boot?
As for VMs, whilst the problem indeed affects them too, the reality is that most hypervisors - even commercial ones - don't actually enable Secure Boot by default, you'd have to go really out of your way to enable it for a VM.
The reason: the VM refuses to boot when provided with an ISO (via virtual CDROM) with a meaningless error (permission denied: go figure out what permission and why was it denied and by whom).
Secureboot is meaningless / useless for most people running VMs, be it on own or rented hardware. It takes some pain and extra work to get it to work sometimes, and a huge amount of work to get it to work always. I doubt anyone was dedicated enough to get it to work always. So, I believe you are right. This is extremely unlikely to be a problem for anyone running Linux VMs, and the more VMs they need to run, the less likely it is a problem.
Whatever ms and hp / Lenovo do with their certs doesn’t affect me, since I only have my certs installed. Except on a single machine whose purpose is running windows, but it’s not on the critical path for my job.
I know it is not recommended but the options to have my own keys seemed a bit of a hack than a solution.
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.
Secure boot prevents tampering of your kernel and/or bootloader, nothing about Linux prevents this from being possible.
You might argue that you don't care about this, but some people such as myself do!
By trusting another chain of trust and firmware binary blobs involved in booting your PC.
Secure boot exists only as one of the puzzle pieces for remote attestation for MS and trusted OEMs, nothing to do with your security.
So what? I'm still preventing a random person from tampering with my bootloader?
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.
The issue seems to be that Microsoft will refuse to sign anything new with the expiring certificate (which is correct behaviour), so any UEFI firmware that hasn't got the new certificate will refuse newly signed bootloaders.
I don't see anything wrong with this scenario, it's on distros to properly make sure they're distributing secure boot certificate updates.
Edit: Apparently RHEL will even refuse to install a 2023 signed shim if the firmware lacks the certificate for it.
Why is that? RHEL own blog post described that RHEL is distributing dual signed shim by both 2011 and 2023 certificates, so that it works either way, only 2011 present or only 2023.
Well yea - as someone who has 0 understanding of why we need it, and only ever get greatly frustrated by it, I am pretty mad that people feel entitled to call my distro managers "that's on them"