←back to thread

Linux and Secure Boot certificate expiration

(lwn.net)
253 points pabs3 | 3 comments | 18 Jul 25 03:53 UTC | HN request time: 0.436s | source
Show context
mkj ◴[18 Jul 25 07:23 UTC] No.44602124[source]▶
It's not just Linux - certificates to sign Windows are also affected in 2026.

https://support.microsoft.com/en-us/topic/windows-secure-boo...

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).

replies(5): >>44602428 #>>44602690 #>>44602733 #>>44602895 #>>44617707 #
jeroenhd ◴[18 Jul 25 09:24 UTC] No.44602733[source]▶
The mistake was not to put an expiry date on the certificates, but to trust hardware vendors to do even basic firmware maintenance after motherboards and laptops leave the warehouse.

In theory a KEK update will fix the expiry issue just like a CA package update on any normal operating system will do.

In practice, most UEFI firmware is written like trash, unmaintained, and mostly untested.

replies(5): >>44603271 #>>44603290 #>>44603448 #>>44603660 #>>44604239 #
1. account42 ◴[18 Jul 25 11:01 UTC] No.44603290[source]▶
No, the real mistake was putting the root of trust anywhere else than the user.
replies(2): >>44604080 #>>44619057 #
2. jeroenhd ◴[18 Jul 25 12:44 UTC] No.44604080[source]▶
The user can load their own keys into their secure boot storage and use those keys without any interference from pre-installed certificate authorities.

This issue only affects the people who don't want to bother being the root of trust.

3. kragen ◴[19 Jul 25 20:27 UTC] No.44619057[source]▶
From Microsoft's point of view, that's not a mistake. It's the whole point! The user is a potential pirate, after all.