←back to thread

Linux and Secure Boot certificate expiration

(lwn.net)
253 points pabs3 | 4 comments | 18 Jul 25 03:53 UTC | HN request time: 0.734s | 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. mkj ◴[18 Jul 25 11:48 UTC] No.44603660[source]▶
What purpose does the expiry date have? There might be something I've missed, but I really can't see one apart from needless complication, which is what makes it a mistake. (There are other problems in the UEFI/firmware ecosystem yes, but that doesn't excuse expiry dates)
replies(1): >>44604133 #
2. jeroenhd ◴[18 Jul 25 12:49 UTC] No.44604133[source]▶
I don't know if this is why the people behind secure boot adopted this design, but expiry dates make CRLs smaller, at least in theory. If a revoked certificate expires, you don't need to add it to the CRL because trust is invalidated automatically. By rotating root keys occasionally, you can also keep the revocation list for vulnerable bootloaders smaller, as you can remove any vulnerable bootloader when its signatory key expires.

With the kind of penny-pinching that happens with NVRAM storage on boards like these, being able to reduce the size of CRLs can make a difference.

replies(2): >>44604289 #>>44607091 #
3. mkj ◴[18 Jul 25 13:10 UTC] No.44604289[source]▶
Hm, I guess that's one point. 15 years worth of accumulated revoked certs is a pretty big list though, not sure how much they win there.

Idle thought - wonder if there are perfect hash-like constructions they could use for revoked certificate lists.

4. roryirvine ◴[18 Jul 25 16:59 UTC] No.44607091[source]▶
UEFI's equivalent of the CRL is the "forbidden signature database" (or DBX) - but as far as I can see, it only has 658 entries (the source appears to be https://github.com/microsoft/secureboot_objects/blob/main/Pr... )

Another potential use is to facilitate managed deprecation of obsolete crypto functions / protocols / hash suites / etc.

That fits pretty well with a 10 year rotation period, and is probably more valuable in the long term than minimising DBX size.