Steve's blog
-->
Steve's blog
About
Steve's blog,<br>The Words of the Sledge
steve@einval.com
Subscribe
Subscribe to the RSS feed.
Links
Home
Debian
PlanetDebian
Search PlanetDebian
Friends
Matthew Garrett
Jonathan McDowell
Jo McIntyre
Martin Michlmayr
Andrew Mobbs
Mike Pitt
Daniel Silverstone
Andy Simpkins
Neil Williams
Friday, 22 May 2026
Secure Boot and Microsoft CA Rollover - a heads-up for distributions
Background
I'm a member of the EFI team in Debian, and I've done much of the<br>work for Debian to support UEFI Secure Boot (SB) in recent years. We<br>have included that support for a number of releases now, starting back<br>with Debian 10 (aka Buster).
I'm also a long-time accredited member of<br>the shim-review<br>team, the group that checks and approves shim binaries before<br>Microsoft will sign them.
See the Debian<br>wiki for lots of background details about Secure Boot and how we<br>do things in Debian.
Secure Boot depends on signatures, which are verified during boot<br>using a chain of X.509 certificates. The root certificate(s) in the<br>chain are embedded in computer firmware, then later software such as<br>shim can add more certificates to extend the trust. Easy, right?
The problem - certificates expire...
Microsoft administer the most widespread Secure Boot root<br>certificates, and have been doing so since the very beginning of UEFI<br>Secure Boot as a concept. The Microsoft UEFI CA certificates are<br>included in just about every x86 and x86-64 computer shipped, and also<br>in quite a lot of arm64 machines too.
(The fact that Microsoft is therefore a gatekeeper for Linux<br>running under Secure Boot on most machines is very unpopular in some<br>quarters, but this is just a fact of life in the world we live<br>in. None of the following will affect you if you're using<br>Secure Boot with your own keys only. )
The current certificates have been around since 2011:
1. Windows Production PCA 2011 (used for signing Windows components)
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011<br>Validity<br>Not Before: Oct 19 18:41:42 2011 GMT<br>Not After : Oct 19 18:51:42 2026 GMT
This expires in October this year, ~5 months from now.
2. Third Party Marketplace Root (used for signing option ROMs and other software)
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011<br>Validity<br>Not Before: Jun 27 21:22:45 2011 GMT<br>Not After : Jun 27 21:32:45 2026 GMT
For Linux folks, this second certificate is more interesting - it<br>is the root of the certificate chain that Microsoft use when<br>signing shim for Linux<br>distributions
This CA expires 5 weeks from today.
OMG!!! Will all my existing Secure Boot machines stop booting?
Almost definitely not, no.
The specification for UEFI Secure Boot expects that valid dates on<br>certificates should not be enforced for signatures here. All that<br>matters here is the signatures themselves. Modulo buggy firmware,<br>existing signed binaries should continue just fine.
New CAs to be aware of
Microsoft have published three new CAs:
1. A new CA used for signing device option ROMs
Subject: C=US, O=Microsoft Corporation, CN=Microsoft Option ROM UEFI CA 2023<br>Validity<br>Not Before: Oct 26 19:02:20 2023 GMT<br>Not After : Oct 26 19:12:20 2038 GMT
2. A new CA used for signing Windows components
Subject: C=US, O=Microsoft Corporation, CN=Windows UEFI CA 2023<br>Validity<br>Not Before: Jun 13 18:58:29 2023 GMT<br>Not After : Jun 13 19:08:29 2035 GMT
3. A new CA used for signing other software (e.g. shim)
Subject: C=US, O=Microsoft Corporation, CN=Microsoft UEFI CA 2023<br>Validity<br>Not Before: Jun 13 19:21:47 2023 GMT<br>Not After : Jun 13 19:31:47 2038 GMT
New machines and updated older machines will most<br>likely have all of these new CAs installed. New machines are<br>already shipping that only include the new CAs; they<br>will not trust older software and this has already started causing<br>problems for some users.
Isn't this is all a bit short notice?
Yes it is. :-(
A common rule of thumb when deploying CA certificates is to start<br>the process of replacement ("rollover") when a certificate reaches<br>half of its lifetime. Unfortunately, Microsoft have done this very<br>late. They generated new keys in 2023, but didn't start signing shim<br>and other third-party software with the UEFI CA until October<br>2025.
If I'm a distro developer, what should I do?
If you already have an old shim signed by Microsoft for your<br>distribution from before October 2025, then it will only be signed<br>using the older CA that expires soon. On newer machines, your users<br>will already not be able to boot your distro with Secure Boot<br>enabled.
If you want your users to be able to use Secure Boot in future, you<br>will need to get a new shim build submitted, reviewed and signed using<br>the new CA. However, that signed build will not work on older machines<br>unless they have had the new CAs installed. This is also likely to<br>cause problems for some users. You should encourage your...