11 ms·

Linux and Secure Boot certificate expiration

253 points by pabs3 1y ago

pabs3 1y ago
Luckily I only use hardware from dumpsters that is old enough to have BIOS boot mode.
crinkly 1y ago
So is it a possibility that a grub update breaks an existing bootable node? That worries me as I have a couple of Linux desktops in the field which I can’t remember if secure boot is enabled on.
- jeroenhd 1y ago
  If users don't update their keyrings or firmware (through fwupdmgr for instance), Grub will probably stop booting with secure boot on when the certificate expires. If users update Grub once the old certificate is no longer used to sign the bootloader without updating their keyrings or firmware, Grub will probably stop booting with secure boot on when the certificate expires. If users do update their systems and software, Grub will keep working. Not updating is not a solution, unless the motherboard manufacturer really fucked up and doesn't validate the expiration date. Luckily, fwupdmgr is integrated in the GUI updater tool on just about any Linux distro I know. As long as users don't ignore the "there are system updates available" popup and as long as the desktop vendor put out bare basic software support, things will probably go down fine.
  - zozbot234 1y ago
    > Not updating is not a solution, unless the motherboard manufacturer really fucked up and doesn't validate the expiration date. The article mentions that most motherboards will probably not validate the expiration date. There is a residual concern that new versions of the Shim will not be signed with the expired key, and thus be unbootable on hardware that doesn't accept the new key.
greatgib 1y ago
It's totally crazy that we have to go through Microsoft to sign things to be able to have our OS run on third parties computers, and that Microsoft manage to win about this so easily as it was never seriously challenged.
- AStonesThrow 1y ago
  [dead]
- whatagreatboy 1y ago
  Only legal requirements can change it. Nowadays, the mokutil is good enough that linux users can build a good tool around it to automate registration at boot that should ease some pain. But otherwise, it is a big mess and still needs legal requirement.
  - riedel 1y ago
    The EU should step in and make sure that any critical OS attestation is taken out of the hands of the big players. Look at GrapheneOS is being denied Google Play Integrity [1] on pretty much no grounds with large consequences. Such security infrastructure is to easily abused to put bias into the market. On the other hand funding is needed to professionally run this stuff. [1] https://discuss.privacyguides.net/t/grapheneos-is-taking-action-against-anti-competitive-play-integrity-api/18695 https://discuss.privacyguides.net/t/grapheneos-is-taking-act...
    - nullc 1y ago
      "The EU should step in" EU mandates any hardware sold will only boot software signed by EU private key, with signatures only provided to software including government spyware and passing a billion euro certification process. "No not like that!"
- nine_k 1y ago
  Basically every x64 computer is intended to be able to run Windows. Hence MS had to be involved, and I suppose nobody else with serious money wanted the burden. AFAICT you can still disable Secure Boot in most UEFI firmware, and boot anything you like (or not like, if an attacker tampers with your system).
saidinesh5 1y ago
Just out of curiosity, how good is the secure boot experience these days? I've had to disable it on all my installations because of either nvidia drivers or virtual box modules. In general Arch based distros didn't seem too friendly for secure boot set up.
- bravetraveler 1y ago
  Signature maintenance for modules can be fully automated. Enrollment requires navigating a mildly-intimidating interface a single time to accept the new PKI. Fine for systems you physically manage, anything remote in a datacenter I wouldn't bother (without external motivation)
  - mormegil 1y ago
    Which is strange because secure boot should be useful in _exactly_ the situation you don't have physical control of the HW, shouldn't it? I guess the threat model for a common not-that-important company does not include evil data center (and it's dubious if SecureBoot would protect you in reality), but wasn't that one of the motivations?
    - bravetraveler 1y ago
      Aye, though an evil maid has higher barriers and more paperwork in a DC. I hesitate based on that mitigation and the untold operational pain. Sometimes it's worth it, other times it isn't.
    - ChocolateGod 1y ago
      Well you can tie it to TPM to store your encryption key which should only produce the key when the boot parameters match the key. This is what Windows already does but its not fully supported under Linux and somewhat insecure as you can't encrypt the initramfs (so someone can infect boot process there instead).
      - the8472 1y ago
roschdal 1y ago
Secure boot is so evil.
- eqvinox 1y ago
  No it's not. Secure boot without user control is evil. UEFI generally allows user control. Of course a vendor can make an UEFI system that doesn't allow user keys… don't buy that.
negative_zero 1y ago
Well I can say that the update is not going 100% smoothly. I have a pending KEK update in Fedora but it's a test key (bug filed but no progress as of yet).
mkj 1y ago
It's not just Linux - certificates to sign Windows are also affected in 2026. https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e https://support.microsoft.com/en-us/topic/windows-secure-boo... https://techcommunity.microsoft.com/blog/windows-itpro-blog/act-now-secure-boot-certificates-expire-in-june-2026/4426856 https://techcommunity.microsoft.com/blog/windows-itpro-blog/... Really it seems like having any expiry date for these certificates is a mistake. The one thing it might protect against is a compromised signing key, but if you have to wait 15 years for a compromised key to stop being valid, it's not very useful! Don't worry, the replacement MS certs expire in 2038 (a couple of months after the 32-bit unix time rollover).
- littlestymaar 1y ago
  Is that really a mistake? Or Microsoft just has no interest to care about computers not working as intended anymore. It certainly wouldn't be the first evidence of that…
  - pjmlp 1y ago
    Being cynic, there was the expectation that computers would get replaced before the certification expiration date.
- nirui 1y ago
  I'm feeling/guessing the expiration is more of a flow-with-tradition thing. TLS certificates expires, it's part of the security feature, so why not Secure Boot certificates too? And of course, it gives the root certificate issuer enormous amount of power as well, good riddance from the POV of Microsoft. However, I think if Microsoft REALLY care about security, they should not let application installed on their system to do anything that is unapproved by the user (such as installing a virus that encrypts all their data), which could actually enhance the user experience and security. But, with secure boot, at least you can be sure that your Windows kernel is not tampered so it can serve the virus correctly :)
  - 1y ago
Artoooooor 1y ago
Just another factor creating electro-junk. Currently I can install 30 year old system on 30 year old hardware (assuming that I keep both the machine and the installation media in a good shape). With current computers it will be impossible because they will be "unsupported".
- jeroenhd 1y ago
  Just disable secure boot if you can't update the certificate. You can still use your computer.
omnibrain 1y ago
I'm sure this is a naive take, but why is it not possible to enter a new key into the BIOS (dating myself, I know it's EFI) by hand?
- nottorp 1y ago
  You'd have control over what boots on your computer then...
  - ozgrakkurt 1y ago
    That would be a disaster. Or imagine what would happen if you just disabled secure boot, your computer will be infected with viruses and your bank account emptied instantly I reckon
    - Dead_Lemon 1y ago
      Secure boot doesn't stop user-space malicious activity. I'd argue that it only helps check a tick box on corporate security manifest, as it indicates the kernel being booted, is not tampered with.
      - OldfieldFund 1y ago
        OP was being sarcastic
  - nicman23 1y ago
    you literally have though. you can self sign everything and set up uefi to only boot your signature
    - const_cast 1y ago
      Only on x86 secure boot implementations. On most devices with trusted boot, you don't have this option.
      - 1y ago
xiconfjs 1y ago
Is there a reliable command in Ubutu to check for the secure boot key and its expiration date?
- porridgeraisin 1y ago
  mokutil Check its various options The 'Validity' field in the output will tell you the expiration date.
  - eqvinox 1y ago
    mokutil is technically the wrong tool for this, it lists shim-installed machine owner keys (MOK). This is about UEFI-installed key exchange keys (KEK). If you don't know what's going on you'll be very confused about empty key lists. It can in fact show KEKs but you need to know that this is a KEK thing to begin with… mokutil --kek | egrep '(Not |Subject:|^[^ ])' is the magic incantation if you really want to use mokutil
porridgeraisin 1y ago
Secure boot, disk encryption, etc are more trouble than they are worth IME. I have them all off. Qualifier: for personal computers that you don't take regular backups of, test backups, etc
- flexagoon 1y ago
  Secure Boot's benefits are definitely not as strong (I don't think flashing custom backdoored firmware is a common attack vector for personal computers), but FDE is still useful in case your laptop gets stolen, because thieves looking for sensitive data on a hard drive is a thing that does actually happen. I also wouldn't really say it's much trouble. If you have a TPM and use systemd, you can set it up to unlock FDE automatically on boot, otherwise, you just have to input an extra password when turning on your machine.
  - zozbot234 1y ago
    SB does not protect against backdoored firmware at all. You would need something like BootGuard which is a separate feature.
    - palata 1y ago
      Can you elaborate on that? Isn't it the whole point of secure boot? My understanding is that at least on Android you can't modify the system: you have to format everything if you want to make a change at this level.
      - Avamander 1y ago
        No, SB starts with actually firmware already booting something. It is just one link in the chain. You can also look up Trusted Boot and Secure Launch, how this entire chain can/could be secured.
        palata 1y ago
        > SB starts with actually firmware already booting something. I don't understand that sentence. So instead of a bootloader in the ROM that starts the next bootloader and verifies that it is signed (I think that's how it is on Android?), on a laptop the first bootloader can be installed by the user and nothing checks its signature? EDIT: what I read here [1] is that Secure Boot is verified from the ROM to the moment it starts "the Windows kernel" (on Windows). But it's not completely clear to me: say on Linux, if Secure Boot verifies up to my /boot partition (does it?), then it should be okay because I have FDE on the rest, right? [1]: https://learn.microsoft.com/en-us/windows/security/operating-system-security/system-security/trusted-boot https://learn.microsoft.com/en-us/windows/security/operating...
chabad360 1y ago
It should be noted, it is 100% possible to use Secure Boot with Linux and not be impacted at all. AFAIK, most (if not all) UEFI firmwares allow enrolling your own keys. Managing secure boot these days is as easy as installing sbctl and adding a hook to sign your kernel when rebuilding the initramfs. For the same price, as noted by the article, the key new key can be updated while the system is online without anyone being the wiser. The FUD that gets spread around SB helps no one, and other than a small list of exceptions, you are always in control of your system. SB allows MS to transparently enable Full Disk Encryption by default, which I think is a win for all users. It allows you to do the same on Linux. It lets server operators be sure their systems have not been tampered with. While there are many problems with UEFI, SB is not one of them.
- nullc 1y ago
  There is hardware that requires drivers to even reach the bios. The drivers are signed with the MSFT key. And if you change to your own key you'll find you can't even get into the bios anymore.
TacticalCoder 1y ago
> Any installed distribution should have a bootloader signed with its own key that will continue to boot I'm kinda concerned here: as long as there's no mandatory security upgrade requiring a reboot, I'm the kind of person to reach six months of uptime with my desktop (yup, Linux is that stable, a far cry from Windows). So I'm concerned about not being about to boot in x months and forgetting why (ah, yes, Microsoft having a key expiring). Am I correct in my understanding that this only affects my installation media and not my already installed systems? Lastest Debian stable FWIW. Oh well, I take it it's going to be mokutil and whatnots when I get back home.
palata 1y ago
[Warning: I'm not interested in sarcasm or uninformed rants against secure boot, there are plenty already] I'm hoping to get insights from people who understand secure boot well here. My understanding on Android (for the minority of Android manufacturers that do it correctly) is that there is a "manufacturer key" burnt somewhere on the ROM that cannot ever be changed, and once a first system is installed properly: 1. It is impossible to overwrite the system partitions unless the bootloader is unlocked from the already-installed OS (I assume that something makes sure that only the signed OS can unlock the bootloader?). 2. Once the bootloader is unlocked, it is impossible to overwrite only parts of the system: it's all or nothing, such that one cannot inject stuff into an existing system (evil maid style). Still on Android, it's possible to add custom keys. That's what GrapheneOS and the likes use. How is it on UEFI? It sounds like the "manufacturer keys" are always from Microsoft, but is there not a way to use custom keys?
- jeroenhd 1y ago
  > Still on Android, it's possible to add custom keys. That's what GrapheneOS and the likes use. AFAIK, that depends on the hardware used. Google Pixels allow it, but it's not universally permitted. Plenty of stories can be found on XDA where people tried to lock their bootloader that bricked their phone.
  - palata 1y ago
    > AFAIK, that depends on the hardware used. Google Pixels allow it, but it's not universally permitted. You're right! That's what I mentioned the few manufacturers who do it correctly. GrapheneOS only supports Pixels for other reasons than that. CalyxOS supports other devices (one constraint being to be able to relock the bootloader). /e/OS doesn't seem care so much about the secure boot. > Plenty of stories can be found on XDA where people tried to lock their bootloader that bricked their phone. That raises a question: what is the point of relocking the bootloader? If overwriting the keys means that the whole system will be formatted, then I don't see why it should ever be prevented at all? If an evil maid wants me to lose my data, they can leave with the laptop, right?
- vbezhenar 1y ago
xyst 1y ago
Reading into the history of Secure Boot. Discovered Intel and AMD processors have back doors via Intel Management Engine [1] and AMD Platform Security Processor [2]. Both are closed source and have had a number of vulnerabilities over the years. They are essentially backdoors. Seems disabling these "features" is nearly impossible as well. [1] https://en.m.wikipedia.org/wiki/Intel_Management_Engine https://en.m.wikipedia.org/wiki/Intel_Management_Engine [2] https://en.m.wikipedia.org/wiki/AMD_Platform_Security_Processor https://en.m.wikipedia.org/wiki/AMD_Platform_Security_Proces...
jeroenhd 1y ago
I wonder what my laptop will do soon. Lenovo, in their infinite wisdom, has decided to load an Nvidia blob signed by Microsoft before even being able to access the UEFI firmware interface. People who have tried to install their own secure boot keys found out the hard way that you can't even get into the firmware configuration interface to undo the change. Their official workaround is to only load secure boot keys through their firmware interface (rather than the standard Linux utility) which refuses to wipe the certificate used to sign the Nvidia firmware. However, that workaround will obviously stop working when that certificate expires.
- craftkiller 1y ago
  The Framework laptop with the AMD 7840U works perfectly without any microsoft keys enrolled. For your current laptop, you might be able to use the `--tpm-eventlog` to `sbctl enroll-keys` to enroll hashes of your OptionROM to whitelist that blob.
eqvinox 1y ago
> Linux users who have Secure Boot enabled on their systems knowingly or unknowingly rely on a key from Microsoft that is set to expire in September. No I don't because I installed my own keys, and so should you, and can we please stop assuming that Secure Boot means Microsoft keys?
laserbeam 1y ago
The article should include a very obvious way for someone to test if they are affected. How does one verify (in an in a VERY clear and straightforward way) if some arbitrary system will run into this issue in September?
- mkj 1y ago
  Set your clock to December, reboot, and see what happens.
iforgotpassword 1y ago
Fuck secure boot. A fun project, even if mostly for educational purposes, would be to collect all the different exploits that have been found over the past years and try to create a universal secure boot bypass loader that targets as many of those as possible. I guess chances are that if your vendor didn't update the firmware to include the newer ms keys, they also didn't patch any of the exploits. So we just need to also get this super exploit loader signed so that it works everywhere :o)
horseradish8h 1y ago
could we just set the clock backwards on shutdown and forwards on boot? or do the keys delete themselves after the date?
upofadown 1y ago
>Currently, shim is signed with a Microsoft key from 2011 that expires on September 11. What security benefit did adding an expiry date to the certificate provide? "Oh no! Someone has gotten our secret key and is certifying new shims! ... Not to worry, the certificate will expire in 14 years. Everything is fine!" Does anyone know the rationale for such expiry?
- Avamander 1y ago
  Knowing that any quicker rollover would've hindered or even stopped uptake before the technology got established?
jmclnx 1y ago
And this is why I avoid and will always avoid "Secure Boot". I can see many newer Linux people being locked out starting in Sept.
- craftkiller 1y ago
  Or you could just remove microsoft's keys from your systems and sign your bootloader with your own key. That's what I do on all of my systems so I am unimpacted by this.
  - ekianjo 1y ago
    do you have any source on how to do that?
    - craftkiller 1y ago
      I followed https://github.com/nix-community/lanzaboote/blob/master/docs/QUICK_START.md https://github.com/nix-community/lanzaboote/blob/master/docs... but naturally you don't want to include the `--microsoft` flag when running `sbctl enroll-keys` if you want to avoid microsoft keys. Also Lanzaboote is only for NixOS.
    - marcthe12 1y ago
      The arch wiki has the best source https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot https://wiki.archlinux.org/title/Unified_Extensible_Firmware... Note sbctl is one of the easier tools to do this.
  - josephcsible 1y ago
    Sure, but that's a lot more work than just disabling Secure Boot, and for most people's threat models, there's zero actual security benefit gained in return.
    - deleted 1y ago
      [deleted]
1970-01-01 1y ago
So in 2025,2026 the simplicity of BIOS still haunts us. I realize this time it is a one-off cert issue, but there have been so many other non-trivial paper cuts in secure boot and UEFI implementation that I can't help but see this upcoming fix as spinning a roulette wheel of fixed/failed/bricked.
RecycledEle 1y ago
This is yet another why I do not encrypt.
- craftkiller 1y ago
  Secure boot has nothing to do with encryption. It is verifying crytographic signatures. The bootloader is signed, not encrypted.
  - vbezhenar 1y ago
    There's some link between secure boot and encryption. If you don't do secure boot, you need to secure your boot chain in other ways, to prevent attacker from modifying your software to log entered passphrase. Secure boot allows to build a verifiable chain of software (UEFI -> Bootloader -> Kernel -> Initrd) which will protect against any modification, so you can be sure that your key presses are not being logged by the malicious software. That said, commonly used Linux distros have some problems protecting initrd, but that's issue of those distros. Another link is TPM. I set up my system in a way to keep encryption key in TPM and release it only when secure boot is enabled. This allows to decrypt root automatically, without entering passphrase and my configuration only allows to boot UKI kernel signed with my key. It trades security with convenience, of course (because now attacker, who stolen my computer, only has to break through gdm or perform other ways of attacks like extracting RAM sticks), but for me it's acceptable.
    - ahoka 1y ago
      I think it’s primarily to avoid someone just putting your SSD into any other computer and access all files. Anything more is probably not a realistic threat to most people.
      - sgjohnson 1y ago
        Secure Boot does nothing whatsoever to prevent that. Disk Encryption has got nothing to do with Secure Boot.
    - 1y ago
max-privatevoid 1y ago
Using "Secure Boot" with MS keys is not real Secure Boot. It's "Microsoft decides what you may boot". Enrolling your own keys should be the standard way of operating. shim is a joke.
WhereIsTheTruth 1y ago
Every single time when this concern is being raise, people get called "conspiracy theorist" and get "flagged" or muted, aka censored Fast forward today, yall are getting fucked deep in the ass Fuck Microsoft
- cindyllm 1y ago
  [dead]
londons_explore 1y ago
Things that might not get updates shouldn't use the current date/time when checking certificates. Instead, they should see if the certificate would have been valid on the day the firmware was compiled (ie. behaviour will never change through the passage of time alone).
- AnotherGoodName 1y ago
  Expired certificates should also at worst be a skippable warning. No one’s relying on certificates expiring for security. If you did you might have to wait many years for the expiration of a stolen certificate - lol! It’s absolutely a minor “hey btw the certificate expired, check for an update” yet various systems treat certificate expiration as an end of the world lock it down scenario.
  - Tuna-Fish 1y ago
    Oh it's skippable all right. Just pull the cmos battery and wait a few seconds before putting it back in.
    - londons_explore 1y ago
      There's gonna be a bunch of linux users who write a shutdown script to set the date back to 2015 then poweroff... And at startup, reset the date back to today using the internet. Sounds like a cleaner solution than any of the ones in the article too!
      - Tuna-Fish 1y ago
        That's risky, an unclean shutdown would require resetting the clock which is a bother. It's much more likely that someone will write a driver that adds an offset to the clock, keeping the hw date in a safe range.
        homebrewer 1y ago
        You can simply avoid adjusting the hardware clock. The kernel clock is not tied to it and can be modified separately. chrony can do that, for example. https://wiki.archlinux.org/title/Chrony#Real-Time_Clock https://wiki.archlinux.org/title/Chrony#Real-Time_Clock
deleted 1y ago
[deleted]
jacquesm 1y ago
Can't you just disable the internet connection, set the BIOS clock to a date before the expiration date to boot from the secure installation media and then reset it to the proper time after the installation is complete?
LocalH 1y ago
It irks me that Microsoft managed to shim their way into the Linux boot process like this. No key signed by Microsoft should ever come into play when booting Linux, on a moral basis.
- Maxious 1y ago
  you dont have to use the shim, just follow this https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html https://www.rodsbooks.com/efi-bootloaders/controlling-sb.htm...
- deleted 1y ago
  [deleted]
- ThrowawayR2 1y ago
  Libre operating systems are coded to run on machines that conform to Microsoft's hardware standards and conformance tests (Windows HLK) that define Windows compatible hardware. Linux is shimming its way into Windows' boot process, not the other way around, even on machines sold with Linux from the manufacturer. If you want to be clean on "a moral basis", whatever that means, the FSF would have to create their own hardware standard and persuade OEMs to adhere to it. Good luck.
  - jacquesm 1y ago
    This is only the case because we let it be the case. Microsoft should have had zero influence on this. Consumer protection laws have utterly failed us.
  - LocalH 1y ago
    TIL UEFI is apparently a "Windows boot process" /s
Sophia95 1y ago
TLDR Linux systems using Secure Boot rely on a Microsoft certificate (from 2011) that will expire on September 11, 2024. After that, new Linux installs using Secure Boot may fail to boot unless the system firmware includes Microsoft’s newer 2023 key and updating the key often requires a firmware update from hardware vendors which doesn’t always happen. It’s crazy that many users are relying on an outdated Microsoft key unknowingly (I will be checking if I’m among them smh) Also great that people are bringing awareness to this
porridgeraisin 1y ago
I always have Secure boot off Disk encryption off Tpm off mitigations=off in linux kernel cmdline
cm2187 1y ago
It's not just secure boot. Modern OS have certificates all over the place. These are ticking self-destruct time bombs in those machines that the manufacturers of hardware based on these OS may not necessarily realize. I am thinking ATM machines, voting machines, medical equipment, smart-fridges and other IOT, probably many cars, etc.
- jacquesm 1y ago
  Oh, they realize it just fine. To them it is just another source of revenue. Planned obsolescence is going to wipe out our digital heritage at some point.
  - hulitu 1y ago
    > Planned obsolescence is going to wipe out our digital heritage at some point. I presume words like "Crowdstrike" or "Microsoft Update" don't say anything to you. /s
hcfman 1y ago
Is there a reason why the secure boot thing could not have had several secure boot slots and each one independent of others? So that microsoft world could run securely and other people could boot their system securely out of another slot? Just wondering what the technical reason would be that Microsoft had to control the whole of the PC?? Surely, the control of the boot environment and any the the boot shims could have been restricted to system that could boot out of said shim. Then the two worlds could have securely co-existed could they not ?
hcfman 1y ago
You would think it would be illegal to sell compute resources into Europe without an artificial expiration date controlled by a US company.
kragen 1y ago
I didn't realize that the Secure Boot certificates that allow us to boot Linux at Microsoft's pleasure are things that expire. So all Microsoft has to do to kill end-user Linux is... nothing. How the hell did we get ourselves into this situation? After Microsoft spent years secretly threatening people with lawsuits for running Samba and Linux VFAT, and describing open source as "cancer"?

253 points by pabs3 1y ago

Luckily I only use hardware from dumpsters that is old enough to have BIOS boot mode.

So is it a possibility that a grub update breaks an existing bootable node? That worries me as I have a couple of Linux desktops in the field which I can’t remember if secure boot is enabled on.

jeroenhd 1y ago
If users don't update their keyrings or firmware (through fwupdmgr for instance), Grub will probably stop booting with secure boot on when the certificate expires. If users update Grub once the old certificate is no longer used to sign the bootloader without updating their keyrings or firmware, Grub will probably stop booting with secure boot on when the certificate expires. If users do update their systems and software, Grub will keep working. Not updating is not a solution, unless the motherboard manufacturer really fucked up and doesn't validate the expiration date. Luckily, fwupdmgr is integrated in the GUI updater tool on just about any Linux distro I know. As long as users don't ignore the "there are system updates available" popup and as long as the desktop vendor put out bare basic software support, things will probably go down fine.
- zozbot234 1y ago
  > Not updating is not a solution, unless the motherboard manufacturer really fucked up and doesn't validate the expiration date. The article mentions that most motherboards will probably not validate the expiration date. There is a residual concern that new versions of the Shim will not be signed with the expired key, and thus be unbootable on hardware that doesn't accept the new key.

greatgib 1y ago

It's totally crazy that we have to go through Microsoft to sign things to be able to have our OS run on third parties computers, and that Microsoft manage to win about this so easily as it was never seriously challenged.

AStonesThrow 1y ago
[dead]
whatagreatboy 1y ago
Only legal requirements can change it. Nowadays, the mokutil is good enough that linux users can build a good tool around it to automate registration at boot that should ease some pain. But otherwise, it is a big mess and still needs legal requirement.
- riedel 1y ago
  The EU should step in and make sure that any critical OS attestation is taken out of the hands of the big players. Look at GrapheneOS is being denied Google Play Integrity [1] on pretty much no grounds with large consequences. Such security infrastructure is to easily abused to put bias into the market. On the other hand funding is needed to professionally run this stuff. [1] https://discuss.privacyguides.net/t/grapheneos-is-taking-action-against-anti-competitive-play-integrity-api/18695 https://discuss.privacyguides.net/t/grapheneos-is-taking-act...
  - nullc 1y ago
    "The EU should step in" EU mandates any hardware sold will only boot software signed by EU private key, with signatures only provided to software including government spyware and passing a billion euro certification process. "No not like that!"
nine_k 1y ago
Basically every x64 computer is intended to be able to run Windows. Hence MS had to be involved, and I suppose nobody else with serious money wanted the burden. AFAICT you can still disable Secure Boot in most UEFI firmware, and boot anything you like (or not like, if an attacker tampers with your system).

saidinesh5 1y ago

Just out of curiosity, how good is the secure boot experience these days? I've had to disable it on all my installations because of either nvidia drivers or virtual box modules. In general Arch based distros didn't seem too friendly for secure boot set up.

bravetraveler 1y ago
Signature maintenance for modules can be fully automated. Enrollment requires navigating a mildly-intimidating interface a single time to accept the new PKI. Fine for systems you physically manage, anything remote in a datacenter I wouldn't bother (without external motivation)
- mormegil 1y ago
  Which is strange because secure boot should be useful in _exactly_ the situation you don't have physical control of the HW, shouldn't it? I guess the threat model for a common not-that-important company does not include evil data center (and it's dubious if SecureBoot would protect you in reality), but wasn't that one of the motivations?
  - bravetraveler 1y ago
    Aye, though an evil maid has higher barriers and more paperwork in a DC. I hesitate based on that mitigation and the untold operational pain. Sometimes it's worth it, other times it isn't.
  - ChocolateGod 1y ago
    Well you can tie it to TPM to store your encryption key which should only produce the key when the boot parameters match the key. This is what Windows already does but its not fully supported under Linux and somewhat insecure as you can't encrypt the initramfs (so someone can infect boot process there instead).
    - the8472 1y ago

roschdal 1y ago

Secure boot is so evil.

eqvinox 1y ago
No it's not. Secure boot without user control is evil. UEFI generally allows user control. Of course a vendor can make an UEFI system that doesn't allow user keys… don't buy that.

negative_zero 1y ago

Well I can say that the update is not going 100% smoothly. I have a pending KEK update in Fedora but it's a test key (bug filed but no progress as of yet).

mkj 1y ago

It's not just Linux - certificates to sign Windows are also affected in 2026. https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e https://support.microsoft.com/en-us/topic/windows-secure-boo... https://techcommunity.microsoft.com/blog/windows-itpro-blog/act-now-secure-boot-certificates-expire-in-june-2026/4426856 https://techcommunity.microsoft.com/blog/windows-itpro-blog/... Really it seems like having any expiry date for these certificates is a mistake. The one thing it might protect against is a compromised signing key, but if you have to wait 15 years for a compromised key to stop being valid, it's not very useful! Don't worry, the replacement MS certs expire in 2038 (a couple of months after the 32-bit unix time rollover).

littlestymaar 1y ago
Is that really a mistake? Or Microsoft just has no interest to care about computers not working as intended anymore. It certainly wouldn't be the first evidence of that…
- pjmlp 1y ago
  Being cynic, there was the expectation that computers would get replaced before the certification expiration date.
nirui 1y ago
I'm feeling/guessing the expiration is more of a flow-with-tradition thing. TLS certificates expires, it's part of the security feature, so why not Secure Boot certificates too? And of course, it gives the root certificate issuer enormous amount of power as well, good riddance from the POV of Microsoft. However, I think if Microsoft REALLY care about security, they should not let application installed on their system to do anything that is unapproved by the user (such as installing a virus that encrypts all their data), which could actually enhance the user experience and security. But, with secure boot, at least you can be sure that your Windows kernel is not tampered so it can serve the virus correctly :)
- 1y ago

Artoooooor 1y ago

Just another factor creating electro-junk. Currently I can install 30 year old system on 30 year old hardware (assuming that I keep both the machine and the installation media in a good shape). With current computers it will be impossible because they will be "unsupported".

jeroenhd 1y ago
Just disable secure boot if you can't update the certificate. You can still use your computer.

omnibrain 1y ago

I'm sure this is a naive take, but why is it not possible to enter a new key into the BIOS (dating myself, I know it's EFI) by hand?

nottorp 1y ago
You'd have control over what boots on your computer then...
- ozgrakkurt 1y ago
  That would be a disaster. Or imagine what would happen if you just disabled secure boot, your computer will be infected with viruses and your bank account emptied instantly I reckon
  - Dead_Lemon 1y ago
    Secure boot doesn't stop user-space malicious activity. I'd argue that it only helps check a tick box on corporate security manifest, as it indicates the kernel being booted, is not tampered with.
    - OldfieldFund 1y ago
      OP was being sarcastic
- nicman23 1y ago
  you literally have though. you can self sign everything and set up uefi to only boot your signature
  - const_cast 1y ago
    Only on x86 secure boot implementations. On most devices with trusted boot, you don't have this option.
    - 1y ago

xiconfjs 1y ago

Is there a reliable command in Ubutu to check for the secure boot key and its expiration date?

porridgeraisin 1y ago
mokutil Check its various options The 'Validity' field in the output will tell you the expiration date.
- eqvinox 1y ago
  mokutil is technically the wrong tool for this, it lists shim-installed machine owner keys (MOK). This is about UEFI-installed key exchange keys (KEK). If you don't know what's going on you'll be very confused about empty key lists. It can in fact show KEKs but you need to know that this is a KEK thing to begin with… mokutil --kek | egrep '(Not |Subject:|^[^ ])' is the magic incantation if you really want to use mokutil

porridgeraisin 1y ago

Secure boot, disk encryption, etc are more trouble than they are worth IME. I have them all off. Qualifier: for personal computers that you don't take regular backups of, test backups, etc

flexagoon 1y ago
Secure Boot's benefits are definitely not as strong (I don't think flashing custom backdoored firmware is a common attack vector for personal computers), but FDE is still useful in case your laptop gets stolen, because thieves looking for sensitive data on a hard drive is a thing that does actually happen. I also wouldn't really say it's much trouble. If you have a TPM and use systemd, you can set it up to unlock FDE automatically on boot, otherwise, you just have to input an extra password when turning on your machine.
- zozbot234 1y ago
  SB does not protect against backdoored firmware at all. You would need something like BootGuard which is a separate feature.
  - palata 1y ago
    Can you elaborate on that? Isn't it the whole point of secure boot? My understanding is that at least on Android you can't modify the system: you have to format everything if you want to make a change at this level.
    - Avamander 1y ago
      No, SB starts with actually firmware already booting something. It is just one link in the chain. You can also look up Trusted Boot and Secure Launch, how this entire chain can/could be secured.
      - palata 1y ago
        > SB starts with actually firmware already booting something. I don't understand that sentence. So instead of a bootloader in the ROM that starts the next bootloader and verifies that it is signed (I think that's how it is on Android?), on a laptop the first bootloader can be installed by the user and nothing checks its signature? EDIT: what I read here [1] is that Secure Boot is verified from the ROM to the moment it starts "the Windows kernel" (on Windows). But it's not completely clear to me: say on Linux, if Secure Boot verifies up to my /boot partition (does it?), then it should be okay because I have FDE on the rest, right? [1]: https://learn.microsoft.com/en-us/windows/security/operating-system-security/system-security/trusted-boot https://learn.microsoft.com/en-us/windows/security/operating...

chabad360 1y ago

It should be noted, it is 100% possible to use Secure Boot with Linux and not be impacted at all. AFAIK, most (if not all) UEFI firmwares allow enrolling your own keys. Managing secure boot these days is as easy as installing sbctl and adding a hook to sign your kernel when rebuilding the initramfs. For the same price, as noted by the article, the key new key can be updated while the system is online without anyone being the wiser. The FUD that gets spread around SB helps no one, and other than a small list of exceptions, you are always in control of your system. SB allows MS to transparently enable Full Disk Encryption by default, which I think is a win for all users. It allows you to do the same on Linux. It lets server operators be sure their systems have not been tampered with. While there are many problems with UEFI, SB is not one of them.

nullc 1y ago
There is hardware that requires drivers to even reach the bios. The drivers are signed with the MSFT key. And if you change to your own key you'll find you can't even get into the bios anymore.

TacticalCoder 1y ago

> Any installed distribution should have a bootloader signed with its own key that will continue to boot I'm kinda concerned here: as long as there's no mandatory security upgrade requiring a reboot, I'm the kind of person to reach six months of uptime with my desktop (yup, Linux is that stable, a far cry from Windows). So I'm concerned about not being about to boot in x months and forgetting why (ah, yes, Microsoft having a key expiring). Am I correct in my understanding that this only affects my installation media and not my already installed systems? Lastest Debian stable FWIW. Oh well, I take it it's going to be mokutil and whatnots when I get back home.

palata 1y ago

[Warning: I'm not interested in sarcasm or uninformed rants against secure boot, there are plenty already] I'm hoping to get insights from people who understand secure boot well here. My understanding on Android (for the minority of Android manufacturers that do it correctly) is that there is a "manufacturer key" burnt somewhere on the ROM that cannot ever be changed, and once a first system is installed properly: 1. It is impossible to overwrite the system partitions unless the bootloader is unlocked from the already-installed OS (I assume that something makes sure that only the signed OS can unlock the bootloader?). 2. Once the bootloader is unlocked, it is impossible to overwrite only parts of the system: it's all or nothing, such that one cannot inject stuff into an existing system (evil maid style). Still on Android, it's possible to add custom keys. That's what GrapheneOS and the likes use. How is it on UEFI? It sounds like the "manufacturer keys" are always from Microsoft, but is there not a way to use custom keys?

jeroenhd 1y ago
> Still on Android, it's possible to add custom keys. That's what GrapheneOS and the likes use. AFAIK, that depends on the hardware used. Google Pixels allow it, but it's not universally permitted. Plenty of stories can be found on XDA where people tried to lock their bootloader that bricked their phone.
- palata 1y ago
  > AFAIK, that depends on the hardware used. Google Pixels allow it, but it's not universally permitted. You're right! That's what I mentioned the few manufacturers who do it correctly. GrapheneOS only supports Pixels for other reasons than that. CalyxOS supports other devices (one constraint being to be able to relock the bootloader). /e/OS doesn't seem care so much about the secure boot. > Plenty of stories can be found on XDA where people tried to lock their bootloader that bricked their phone. That raises a question: what is the point of relocking the bootloader? If overwriting the keys means that the whole system will be formatted, then I don't see why it should ever be prevented at all? If an evil maid wants me to lose my data, they can leave with the laptop, right?
vbezhenar 1y ago

xyst 1y ago

Reading into the history of Secure Boot. Discovered Intel and AMD processors have back doors via Intel Management Engine [1] and AMD Platform Security Processor [2]. Both are closed source and have had a number of vulnerabilities over the years. They are essentially backdoors. Seems disabling these "features" is nearly impossible as well. [1] https://en.m.wikipedia.org/wiki/Intel_Management_Engine https://en.m.wikipedia.org/wiki/Intel_Management_Engine [2] https://en.m.wikipedia.org/wiki/AMD_Platform_Security_Processor https://en.m.wikipedia.org/wiki/AMD_Platform_Security_Proces...

jeroenhd 1y ago

I wonder what my laptop will do soon. Lenovo, in their infinite wisdom, has decided to load an Nvidia blob signed by Microsoft before even being able to access the UEFI firmware interface. People who have tried to install their own secure boot keys found out the hard way that you can't even get into the firmware configuration interface to undo the change. Their official workaround is to only load secure boot keys through their firmware interface (rather than the standard Linux utility) which refuses to wipe the certificate used to sign the Nvidia firmware. However, that workaround will obviously stop working when that certificate expires.

craftkiller 1y ago
The Framework laptop with the AMD 7840U works perfectly without any microsoft keys enrolled. For your current laptop, you might be able to use the `--tpm-eventlog` to `sbctl enroll-keys` to enroll hashes of your OptionROM to whitelist that blob.

eqvinox 1y ago

> Linux users who have Secure Boot enabled on their systems knowingly or unknowingly rely on a key from Microsoft that is set to expire in September. No I don't because I installed my own keys, and so should you, and can we please stop assuming that Secure Boot means Microsoft keys?

laserbeam 1y ago

The article should include a very obvious way for someone to test if they are affected. How does one verify (in an in a VERY clear and straightforward way) if some arbitrary system will run into this issue in September?

mkj 1y ago
Set your clock to December, reboot, and see what happens.

iforgotpassword 1y ago

Fuck secure boot. A fun project, even if mostly for educational purposes, would be to collect all the different exploits that have been found over the past years and try to create a universal secure boot bypass loader that targets as many of those as possible. I guess chances are that if your vendor didn't update the firmware to include the newer ms keys, they also didn't patch any of the exploits. So we just need to also get this super exploit loader signed so that it works everywhere :o)

horseradish8h 1y ago

could we just set the clock backwards on shutdown and forwards on boot? or do the keys delete themselves after the date?

upofadown 1y ago

>Currently, shim is signed with a Microsoft key from 2011 that expires on September 11. What security benefit did adding an expiry date to the certificate provide? "Oh no! Someone has gotten our secret key and is certifying new shims! ... Not to worry, the certificate will expire in 14 years. Everything is fine!" Does anyone know the rationale for such expiry?

Avamander 1y ago
Knowing that any quicker rollover would've hindered or even stopped uptake before the technology got established?

jmclnx 1y ago

And this is why I avoid and will always avoid "Secure Boot". I can see many newer Linux people being locked out starting in Sept.

craftkiller 1y ago
Or you could just remove microsoft's keys from your systems and sign your bootloader with your own key. That's what I do on all of my systems so I am unimpacted by this.
- ekianjo 1y ago
  do you have any source on how to do that?
  - craftkiller 1y ago
    I followed https://github.com/nix-community/lanzaboote/blob/master/docs/QUICK_START.md https://github.com/nix-community/lanzaboote/blob/master/docs... but naturally you don't want to include the `--microsoft` flag when running `sbctl enroll-keys` if you want to avoid microsoft keys. Also Lanzaboote is only for NixOS.
  - marcthe12 1y ago
    The arch wiki has the best source https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot https://wiki.archlinux.org/title/Unified_Extensible_Firmware... Note sbctl is one of the easier tools to do this.
- josephcsible 1y ago
  Sure, but that's a lot more work than just disabling Secure Boot, and for most people's threat models, there's zero actual security benefit gained in return.
  - deleted 1y ago
    [deleted]

1970-01-01 1y ago

So in 2025,2026 the simplicity of BIOS still haunts us. I realize this time it is a one-off cert issue, but there have been so many other non-trivial paper cuts in secure boot and UEFI implementation that I can't help but see this upcoming fix as spinning a roulette wheel of fixed/failed/bricked.

RecycledEle 1y ago

This is yet another why I do not encrypt.

craftkiller 1y ago
Secure boot has nothing to do with encryption. It is verifying crytographic signatures. The bootloader is signed, not encrypted.
- vbezhenar 1y ago
  There's some link between secure boot and encryption. If you don't do secure boot, you need to secure your boot chain in other ways, to prevent attacker from modifying your software to log entered passphrase. Secure boot allows to build a verifiable chain of software (UEFI -> Bootloader -> Kernel -> Initrd) which will protect against any modification, so you can be sure that your key presses are not being logged by the malicious software. That said, commonly used Linux distros have some problems protecting initrd, but that's issue of those distros. Another link is TPM. I set up my system in a way to keep encryption key in TPM and release it only when secure boot is enabled. This allows to decrypt root automatically, without entering passphrase and my configuration only allows to boot UKI kernel signed with my key. It trades security with convenience, of course (because now attacker, who stolen my computer, only has to break through gdm or perform other ways of attacks like extracting RAM sticks), but for me it's acceptable.
  - ahoka 1y ago
    I think it’s primarily to avoid someone just putting your SSD into any other computer and access all files. Anything more is probably not a realistic threat to most people.
    - sgjohnson 1y ago
      Secure Boot does nothing whatsoever to prevent that. Disk Encryption has got nothing to do with Secure Boot.
  - 1y ago

max-privatevoid 1y ago

Using "Secure Boot" with MS keys is not real Secure Boot. It's "Microsoft decides what you may boot". Enrolling your own keys should be the standard way of operating. shim is a joke.

WhereIsTheTruth 1y ago

Every single time when this concern is being raise, people get called "conspiracy theorist" and get "flagged" or muted, aka censored Fast forward today, yall are getting fucked deep in the ass Fuck Microsoft

cindyllm 1y ago
[dead]

londons_explore 1y ago

Things that might not get updates shouldn't use the current date/time when checking certificates. Instead, they should see if the certificate would have been valid on the day the firmware was compiled (ie. behaviour will never change through the passage of time alone).

AnotherGoodName 1y ago
Expired certificates should also at worst be a skippable warning. No one’s relying on certificates expiring for security. If you did you might have to wait many years for the expiration of a stolen certificate - lol! It’s absolutely a minor “hey btw the certificate expired, check for an update” yet various systems treat certificate expiration as an end of the world lock it down scenario.
- Tuna-Fish 1y ago
  Oh it's skippable all right. Just pull the cmos battery and wait a few seconds before putting it back in.
  - londons_explore 1y ago
    There's gonna be a bunch of linux users who write a shutdown script to set the date back to 2015 then poweroff... And at startup, reset the date back to today using the internet. Sounds like a cleaner solution than any of the ones in the article too!
    - Tuna-Fish 1y ago
      That's risky, an unclean shutdown would require resetting the clock which is a bother. It's much more likely that someone will write a driver that adds an offset to the clock, keeping the hw date in a safe range.
      - homebrewer 1y ago
        You can simply avoid adjusting the hardware clock. The kernel clock is not tied to it and can be modified separately. chrony can do that, for example. https://wiki.archlinux.org/title/Chrony#Real-Time_Clock https://wiki.archlinux.org/title/Chrony#Real-Time_Clock

deleted 1y ago

[deleted]

jacquesm 1y ago

Can't you just disable the internet connection, set the BIOS clock to a date before the expiration date to boot from the secure installation media and then reset it to the proper time after the installation is complete?

LocalH 1y ago

It irks me that Microsoft managed to shim their way into the Linux boot process like this. No key signed by Microsoft should ever come into play when booting Linux, on a moral basis.

Maxious 1y ago
you dont have to use the shim, just follow this https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html https://www.rodsbooks.com/efi-bootloaders/controlling-sb.htm...
deleted 1y ago
[deleted]
ThrowawayR2 1y ago
Libre operating systems are coded to run on machines that conform to Microsoft's hardware standards and conformance tests (Windows HLK) that define Windows compatible hardware. Linux is shimming its way into Windows' boot process, not the other way around, even on machines sold with Linux from the manufacturer. If you want to be clean on "a moral basis", whatever that means, the FSF would have to create their own hardware standard and persuade OEMs to adhere to it. Good luck.
- jacquesm 1y ago
  This is only the case because we let it be the case. Microsoft should have had zero influence on this. Consumer protection laws have utterly failed us.
- LocalH 1y ago
  TIL UEFI is apparently a "Windows boot process" /s

Sophia95 1y ago

TLDR Linux systems using Secure Boot rely on a Microsoft certificate (from 2011) that will expire on September 11, 2024. After that, new Linux installs using Secure Boot may fail to boot unless the system firmware includes Microsoft’s newer 2023 key and updating the key often requires a firmware update from hardware vendors which doesn’t always happen. It’s crazy that many users are relying on an outdated Microsoft key unknowingly (I will be checking if I’m among them smh) Also great that people are bringing awareness to this

porridgeraisin 1y ago

I always have Secure boot off Disk encryption off Tpm off mitigations=off in linux kernel cmdline

cm2187 1y ago

It's not just secure boot. Modern OS have certificates all over the place. These are ticking self-destruct time bombs in those machines that the manufacturers of hardware based on these OS may not necessarily realize. I am thinking ATM machines, voting machines, medical equipment, smart-fridges and other IOT, probably many cars, etc.

jacquesm 1y ago
Oh, they realize it just fine. To them it is just another source of revenue. Planned obsolescence is going to wipe out our digital heritage at some point.
- hulitu 1y ago
  > Planned obsolescence is going to wipe out our digital heritage at some point. I presume words like "Crowdstrike" or "Microsoft Update" don't say anything to you. /s

hcfman 1y ago

Is there a reason why the secure boot thing could not have had several secure boot slots and each one independent of others? So that microsoft world could run securely and other people could boot their system securely out of another slot? Just wondering what the technical reason would be that Microsoft had to control the whole of the PC?? Surely, the control of the boot environment and any the the boot shims could have been restricted to system that could boot out of said shim. Then the two worlds could have securely co-existed could they not ?

hcfman 1y ago

You would think it would be illegal to sell compute resources into Europe without an artificial expiration date controlled by a US company.

kragen 1y ago

I didn't realize that the Secure Boot certificates that allow us to boot Linux at Microsoft's pleasure are things that expire. So all Microsoft has to do to kill end-user Linux is... nothing. How the hell did we get ourselves into this situation? After Microsoft spent years secretly threatening people with lawsuits for running Samba and Linux VFAT, and describing open source as "cancer"?