Linux and Secure Boot certificate expiration

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

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.

Which to me leads me to a bigger problem, UEFI is trash, too complicated, too bloated, too hard to implement all the various bits and pieces.

In my opinion the system firmware should do the absolute minimum possible. Find a piece of data somewhere that the processor can start executing, like in the BIOS days where it would just load in the first 512 bytes and start running that. Anything else like hardware configuration, power management, etc... should be left to the operating system.

EFI was part of the itanium culture at Intel to reinvent the IBM PC. I think it's one of the few surviving legacies of all of that.