5 ms·

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-expirat

by 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 :)
- hulitu 1y ago
  > 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 Is Microsoft REALLY cares about security, they should fix their bugs and not make "new features" at every release.
jeroenhd 1y ago
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.
- RedShift1 1y ago
  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.
  - tliltocatl 1y ago
    That's not realistic. Too much stuff is board-dependent and trusting vendors to upstream it (or even disclose documentation) isn't going to work never ever. I think what should be done instead is to swap privilege levels so that after-boot firmware services runs under operating systems, not above it. ACPI, with all it's sins, is pretty close. On the other hand, RISC-V made same old mistake of introducing SMM under other name into their supervisor spec and addeed their own secret sauce of forcing damn TIMER interface to go via SBI (seriously, WHY? High timer latency was known to be a problem om x86s requiring all sorts of weird tricks since Win95 or so).
  - hypercube33 1y ago
    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.
    - hulitu 1y ago
      > EFI was part of the itanium culture at Intel That explains a lot. Was EFI also part of the strategy to destroy alternative architectures, like Itanium was ?
semi-extrinsic 1y ago
> Really it seems like having any expiry date for these certificates is a mistake. Especially when most relevant attacks occur in the scenario where attacker has control over the system clock.
trebligdivad 1y ago
Disaster recovery planning must be fun - 'take a fresh machine from store A, and use the Windows CDs stored in box B, and....'

by mkj 1y ago

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

hulitu 1y ago
> 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 Is Microsoft REALLY cares about security, they should fix their bugs and not make "new features" at every release.

jeroenhd 1y ago

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.

RedShift1 1y ago
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.
- tliltocatl 1y ago
  That's not realistic. Too much stuff is board-dependent and trusting vendors to upstream it (or even disclose documentation) isn't going to work never ever. I think what should be done instead is to swap privilege levels so that after-boot firmware services runs under operating systems, not above it. ACPI, with all it's sins, is pretty close. On the other hand, RISC-V made same old mistake of introducing SMM under other name into their supervisor spec and addeed their own secret sauce of forcing damn TIMER interface to go via SBI (seriously, WHY? High timer latency was known to be a problem om x86s requiring all sorts of weird tricks since Win95 or so).
- hypercube33 1y ago
  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.
  - hulitu 1y ago
    > EFI was part of the itanium culture at Intel That explains a lot. Was EFI also part of the strategy to destroy alternative architectures, like Itanium was ?

semi-extrinsic 1y ago

> Really it seems like having any expiry date for these certificates is a mistake. Especially when most relevant attacks occur in the scenario where attacker has control over the system clock.

trebligdivad 1y ago

Disaster recovery planning must be fun - 'take a fresh machine from store A, and use the Windows CDs stored in box B, and....'