Garrett: Secure boot certificate rollover is real but probably won't hurt you

[Posted July 31, 2025 by corbet]

Matthew Garrett has posted a detailed followup to our recent article on the coming expiration of Microsoft's Secure Boot signing key.

The upshot is that nobody actually enforces these expiry dates - here's the reference code that disables it. In a year's time we'll have gone past the expiration date for 'Microsoft Windows UEFI Driver Publisher' and everything will still be working, and a few months later 'Microsoft Windows Production PCA 2011' will also expire and systems will keep booting Windows despite being signed with a now-expired certificate. This isn't a Y2K scenario where everything keeps working because people have done a huge amount of work - it's a situation where everything keeps working even if nobody does any work.

403 Forbidden

Posted Jul 31, 2025 23:28 UTC (Thu) by cesarb (subscriber, #6266) [Link] (7 responses)

For those who like me can only see "403 Forbidden" no matter which ISP you try (from what I could find out last time I looked at it, that webhost seems to block all ISPs from whole countries), archive link: https://archive.ph/QWhaO

403 Forbidden

Posted Aug 1, 2025 0:29 UTC (Fri) by ttuttle (subscriber, #51118) [Link] (6 responses)

Oh weird, what country were you connecting from?

403 Forbidden

Posted Aug 1, 2025 0:54 UTC (Fri) by cesarb (subscriber, #6266) [Link] (5 responses)

> what country were you connecting from?

Brasil. I tried, in two different devices, from the ISPs with ASNs 28665 and 26599. I have seen other complaints about it, for instance at https://mastodon.social/@graydon@types.pl/114694935858208831 "[...] it looks like dw is geoblocking several countries now for spam mitigation [...]"

403 Forbidden

Posted Aug 1, 2025 2:36 UTC (Fri) by corbet (editor, #1) [Link] (3 responses)

Spam mitigation - but there is also a lot of scraperbot traffic that comes from Brazil. There are lot of sites engaging in that sort of wide-range blocking in an attempt to avoid being completely overwhelmed.

403 Forbidden

Posted Aug 1, 2025 12:01 UTC (Fri) by hmh (subscriber, #3838) [Link] (2 responses)

AFAIK, we have a very large (criminal) botnet in Brazil, mostly made up of compromised android-tv boxes (and/or dubious applications people install on those), plus the usual IoT slop. There are lots of compromised old computers, too, and maybe cellphones.

These botnet nodes are operated as for-hire "home access" proxies by the criminal organizations that control them (as well as all other services a criminal botnet usually provides, such as DDoS) -- and get rented by middleman shady companies, which are themselves hired "no questions asked" by the less savory data scrappers (lots of lesser "AI" companies among them).

This whole deal involves a lot of crimes (as far as Brazilian law is concerned), but laws that are too hard to be enforced in practice are of little help. Note that almost always the botnet gangs, the middleman companies, and any companies using their services are *NOT* Brazilian in the first place, which makes prosecuting them even harder: typically the only Brazilians involved are the owners of the compromised devices (and the vast majority would be considered victims).

BTW, I had no issues accessing mjg49's site from my mobile phone or from home yesterday, but right now it cannot be accessed from work, which has its own ASN and IP allocation (and it is a heavily monitored network). So, it really looks like some sort of partial geo-blocking is taking place.

403 Forbidden

Posted Aug 1, 2025 12:18 UTC (Fri) by hmh (subscriber, #3838) [Link] (1 responses)

Hmm, just for the record: I allowed Firefox to load and run JS from "awsaf.com", and it allowed access to mjg's site even from work. I do not know if this requirement is selective or not, but looks easy enough for real people using full browsers to access the content.

403 Forbidden

Posted Aug 1, 2025 21:57 UTC (Fri) by cesarb (subscriber, #6266) [Link]

> Hmm, just for the record: I allowed Firefox to load and run JS from "awsaf.com", and it allowed access to mjg's site even from work.

Now *that's* interesting.

The article page itself has no "awsaf.com" JS at all (it's a pure HTTP-level 403), but going to the root (https://mjg59.dreamwidth.org/) *does*. Temporarily unblocking that JS and letting it run made the 403 on the article page disappear, and the content is now there as expected.

So it's just a non-obvious trap: to see the article, you must first go to the home page, with JS temporarily unblocked, and that will release the block on everything else. No way I would guess that (if I had seen the "awsaf.com" JS on the article page, I'd have temporarily unblocked it right there and it would've been fine).

403 Forbidden

Posted Aug 1, 2025 3:53 UTC (Fri) by rsidd (subscriber, #2582) [Link]

For me too (India). I don't see this commonly.

The use of the expiry date

Posted Aug 1, 2025 2:52 UTC (Fri) by makendo (guest, #168314) [Link] (4 responses)

So the expiry date is only used to prevent boot code signed *after* the date from running?

The use of the expiry date

Posted Aug 1, 2025 7:09 UTC (Fri) by ewen (subscriber, #4772) [Link] (1 responses)

At most, yes, the expiry date applies to the signing date, not the current date.

In practice I’m expecting the biggest risk of the transition to be when there’s a shim update and Microsoft will *only* sign it with the new key. Then any systems doing secure boot will need to know about the new Microsoft key. At a guess that will happen between September 2025 and December 2026.

Hopefully Linux distro will have integrated ensuring the new CAs are added to the key database, into older (eg LTS) releases, before they push out that “new key signed only” shim update.

Ewen

The use of the expiry date

Posted Aug 13, 2025 12:34 UTC (Wed) by c23o (guest, #177016) [Link]

The *real* problem here is that starting September 11th Microsoft will not sign 3rd party bootloader image submissions with the old 2011 key, this is according to the core LVFS maintainer who is in close contact with Microsoft.

This means that distributions that patch their shim images and later sign them with Microsoft's 2023 UEFI key, will not work on systems that do not have the new key in the UEFI "db" key database, hence they wont be able to boot with Secure Boot.

As of now, you are able to update your systems UEFI database with the new key through the fwupd tool although only with a specific version, namely 2.0+ .

However, on HP systems that is currently not possible through fwupd, because after I had reported that during my "db" update tests the firmware bricked ( Microsoft has experienced as well on their HP laptop tests), the LVFS has globally disabled UEFI "db" updates. It is suspected that the SureStart feature in HP BIOSes causes this problem and we are awaiting an update from them on this matter.

https://github.com/fwupd/missing-firmware-hp/issues/6

The use of the expiry date

Posted Aug 1, 2025 7:18 UTC (Fri) by k3ninho (subscriber, #50375) [Link] (1 responses)

Work supplied a laptop that's new-enough to have only new signing keys so current shim-signed is not secure according to its database and attestation results. I guess that's the explanation, maybe I should get an ident for the keys on this device and file a bug against the Shim.

K3n.

The use of the expiry date

Posted Aug 1, 2025 7:33 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

Current Windows boot media isn't signed with the new key, so that seems unlikely. There's a subset of machines that by default only trust the Windows key, not the third party key (ironically the update here means they can all have new keys installed that trust the new third party key which kind of defeats the point there but whatever) - are you sure that's not what's happening here?