SecureBoot/CAChanges - Debian Wiki (original) (raw)
Contents
- Background
- The problem - certificates expire...
- OMG!!! Will all my existing Secure Boot machines stop booting?
- New CAs to be aware of
- Isn't this is all a bit short notice?
- What is Debian doing about this?
- Cool! So the problem is solved then?
- What should I do?
- How do I get CA updates?
- All done? Not quite. KEK is next!
- Troubleshooting
- Diagnostics
- I've been directed here by an error from shim-signed
- This all seems a lot of hassle - should I just disable Secure Boot instead?
- Related documents elsewhere
Background
Secure Boot is a verification mechanism for ensuring that code launched by a computer's UEFI firmware is trusted. It is designed to protect a system against malicious code being loaded and executed early in the boot process, before the operating system has been loaded.
See the Secure Boot wiki page for much more information about how things work.
Secure Boot depends on signatures, which are verified during boot using a chain of X.509 certificates. The root Certification Authority (CA) certificate(s) in the chain are embedded in computer firmware, then later software such as shim can add more certificates to extend the trust.
The problem - certificates expire...
Microsoft administer the most widespread Secure Boot CA certificates, and have been doing so since the very beginning of UEFI Secure Boot as a concept. The Microsoft UEFI CA certificates are included in just about every x86 and x86-64 computer shipped, and also in quite a lot of arm64 machines too.
(The fact that Microsoft is therefore a gatekeeper for Linux running under Secure Boot on most machines is very unpopular in some quarters, but this is just a fact of life in the world we live in.)
 None of the following will affect you if you're using Secure Boot with your own keys only.
The current two 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 Validity Not Before: Oct 19 18:41:42 2011 GMT Not After : Oct 19 18:51:42 2026 GMT
This expires in October this year, ~4.5 months from now (at time of writing).
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 Validity Not Before: Jun 27 21:22:45 2011 GMT Not After : Jun 27 21:32:45 2026 GMT
For Linux folks, this second certificate is more interesting - it is the root of the certificate chain that Microsoft use when signing shim for Linux distributions.
This CA expires in just over 3 weeks from today (at time of writing).
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 certificates should not be enforced for signatures here. All that matters here is the signatures themselves. Modulo buggy firmware, 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 Validity Not Before: Oct 26 19:02:20 2023 GMT Not After : Oct 26 19:12:20 2038 GMT
This has been split out into a separate CA now, rather than being combined with other third-party software like previously.
2. A new CA used for signing Windows components
Subject: C=US, O=Microsoft Corporation, CN=Windows UEFI CA 2023 Validity Not Before: Jun 13 18:58:29 2023 GMT 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 Validity Not Before: Jun 13 19:21:47 2023 GMT Not After : Jun 13 19:31:47 2038 GMT
New machines and updated older machines will most likely have all of these new CAs installed. New machines are already shipping that only include the new CAs; they will not trust older software and this has already started causing 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 the process of replacement ("rollover") when a certificate reaches half of its lifetime. Unfortunately, Microsoft have done this very late. They generated these new CA keys in 2023, but didn't start signing shim and other third-party software with the UEFI CA until October 2025.
What is Debian doing about this?
Debian unstable currently has a new version (16.1-2) of shim-signed which is dual-signed, i.e. signed using both the old and new Microsoft CAs. It should therefore boot on just about any computer that uses UEFI Secure Boot.
We expect that there will be some computers with buggy UEFI firmware that won't boot this dual-signed shim binary. If you find one, please let us know ASAP via the Debian bug tracking system so we can provide help. We have a list of known-buggy systems at SecureBoot/BuggyFirmware
This dual-signed shim should migrate into testing/forky soon. We have similar dual-signed shim binaries prepared for both Debian 12 (bookworm) and Debian 13 (trixie); these will be rolled out for users shortly.
Freexian are also working on a similar dual-signed shim update for Debian 11 (bullseye) LTS. Other Linux distributions are mostly following a similar path for their users.
So long as these dual-signed shims are available, most users should be fine with their Secure Boot systems.
Cool! So the problem is solved then?
Not quite, no...
We're OK for now. However, software moves on with time. Security bugs are found and fixed, and new versions will released. The next time we have to update shim after June 2026, we will not be able to get this signed using the old CA as that will have expired. So it will only be signed using the current Microsoft UEFI CA.
That new shim will work fine, assuming that everybody's computers have been updated to include that CA. That is the bit that matters here.
New computers will almost definitely have the latest CAs included - that's how the world works. But older computers may not.
What should I do?
If you are running Debian-based computers with Secure Boot enabled, you can check which CAs are on your system. You can look via the firmware setup ("BIOS setup") program, but that's often painful to use and really error-prone.
However, there is a better way! On a running Debian UEFI system, mokutil can tell you lots of things about the UEFI firmware setup, including which certificate are enrolled in the DB keyring - the list of certificates that are directly trusted for Secure Boot. An example computer (a Lenovo laptop) has only the old Microsoft CAs included:
$ mokutil --db | grep "Subject:.*Microsoft" Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011 Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011
but a different, newer machine you can see that both the old and new Microsoft CAs are installed:
$ mokutil --db | grep "Subject:.*Microsoft" Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011 Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011 Subject: C=US, O=Microsoft Corporation, CN=Microsoft UEFI CA 2023 Subject: C=US, O=Microsoft Corporation, CN=Windows UEFI CA 2023
Yet other machines may only include the new CAs, or other different combinations of CAs. Different computer manufacturers do things differently here, which can cause a lot of confusion.
For more information about mokutil and what it can do for you, see the manual.
How do I get CA updates?
Firmware updates
On new enough computers, firmware updates will include updates to the CAs. But older computers, particularly those from manufacturers who don't provide good support, may never get those updates in this way.
CA updates via Windows update
Microsoft themselves have for some time been aggressively pushing updates to machines running Windows - Windows users are just as prone to issues with Secure Boot CAs as Linux users. If your machine dual-boots with Windows, it may already have received those updates. Or it may do next time you reboot into Windows.
CA updates via fwupd
There are other ways to get CA updates, thankfully!
fwupd is a powerful tool, included in just about all Linux distributions including Debian. It was initially designed to manage firmware updates for a small set of specific devices, but over the years has expanded into managing firmware updates on a massive range of devices, all the way up to complete UEFI-based computers. Via the Linux Vendor Firmware Service, fwupd can download manufacturer-supported firmware updates and apply them.
Even better, recent versions of fwupd also know how to download and install CA updates directly. If you have a recent enough version of fwupd installed on your computer, it should be tracking and offering CA updates for you already.
What version is "recent enough"? We believed 2.0.8 should be enough, but we have found otherwise: see 1138871. Version 2.0.20 in trixie-backports is definitely fine; we're working on updating fwupd in bookworm and trixie to make things work here.
To check things in fwupd directly:
fwupdtool refresh
# fwupdtool get-updates Devices with no available firmware updates: • KEK CA • KEK CA • SBAT • THNSF5256GPUK TOSHIBA • ThinkPad Product CA • UEFI CA • UEFI CA • UEFI dbx • Windows Production PCA Devices with the latest available firmware version: • Embedded Controller • Intel Management Engine • System Firmware No updates available for remaining devicesIf you have firmware updates available, calling
fwupdtool update
will start the installation process. After installing updates, you will most likely need to reboot to complete the process.
Various of the desktop environments in Debian integrate with fwupd to give a friendlier user interface (e.g. gnome-software, plasma-discover).
For lots more information, check the docs at https://lvfs.readthedocs.io/en/latest/intro.html.
Manual CA updates
If fwupd doesn't work for you, or you want to do more of the hard work yourself then there is another, much more manual, way to do things.
 Be very careful when directly manipulating variables like this - it's very easy to break your system if you make mistakes here.
Microsoft publish all of their CAs in a public github repository: https://github.com/microsoft/secureboot_objects/.
In this repository you can find authenticated update payloads:
- Windows CA update
- Third Party UEFI CA update
- Option ROM CA update
You can install these db Updates using efivar, e.g. to install the Third Party UEFI CA update:
efivar \
--name d719b2cb-3d3a-4596-a3bc-dad00e67656f-db
--append
--datafile DBUpdate3P2023.bin
--attributes 0x67
Where:
- d719b2cb-3d3a-4596-a3bc-dad00e67656f-db is the Secure Boot db variable
- DBUpdate3P2023.bin is an authenticated Secure Boot update payload
- 0x67 specifies the required append-write authenticated variable attributes
This appends the authenticated update payload to the existing Secure Boot db without replacing the currently enrolled certificates.
 Be very careful when directly manipulating variables like this - it's very easy to break your system if you make mistakes here.
After applying the update, reboot the system and verify enrollment using
mokutil --db
Should I trust binary blobs like this?
That's a very good question! These blobs are signed (see the KEK section next!), and your system should reject them if they have been tampered with by somebody else.
All done? Not quite. KEK is next!
There will be more UEFI CA updates in the future. To ensure that your system will accept automatic updates with future CAs, it may also need similar updates to the Key Exchange Key (KEK) keyring. The KEK is used by the system to check signatures on updates to DB. (Yes, keyrings all the way down.)
The KEK update is not critical immediately in the same way as the DB update, but there are also KEK updates available. Again, it's recommended to apply updates here from your computer manufacturer and/or via fwupd.
Mokutil can again be used to show what keys your system has, e.g.:
mokutil --kek | grep Subject:.*Microsoft
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation KEK CA 2011 Subject: C=US, O=Microsoft Corporation, CN=Microsoft Corporation KEK 2K CA 2023
NOTE: It may take a while for KEK updates to be rolled out by all manufacturers; don't worry if they're not yet available immediately for your computers.
Troubleshooting
 If any of the instructions on this page don't work, do not attempt to force things. Ask for guidance before going any further!
Diagnostics
If you need to report a bug, then please carefully note down:
- The make and model of your computer
- What keys are in the DB and KEK keyrings (use mokutil)
- Complete error messages from whatever went wrong.
I've been directed here by an error from shim-signed
shim-signed used to be a very simple package - it just installed the shim binary signed by Microsoft that was expected to run on just about any computer of the right architecture.
Now that there are computers out there with differing CA certificates installed, we have to be much more careful when installing that shim. For now we have a dual-signed shim that is expected to work everywhere, but we can no longer assume this will always be the case. So, at installation time shim-signed will attempt to verify that the binary it contains will safely boot on your system.
There are two likely error cases to consider here:
1. No valid UEFI Secure Boot signatures found
In this situation, go and look at what certificates your system includes in the DB keyring using
mokutil --db | grep "Subject:.*Microsoft"
as already described above. If your system is missing current UEFI CA keys, go and update them, If it's not, please raise a bug and we'll try to help.
2. Shim signed with a revoked key
This situation is more awkward to solve. The signed shim binary is valid, but one of the keys used has been marked as revoked on your system for some reason.
Revocations in Secure Boot are controlled by adding keys and/or checksums to the UEFI revocation keyring, known as DBX. Revoking CA certs by doing this is strongly disrecommended due to potential fallout.
This should basically never happen in normal operation, so if you see this error please contact us immediately so we can debug the problem.
This all seems a lot of hassle - should I just disable Secure Boot instead?
Really, no.
UEFI Secure Boot is absolutely a useful layer of protection for blocking boot-time persistent malware. That hasn't changed at all.
Unfortunately, the CA and KEK rollovers described here have not been handled well and for that we can only apologise on behalf of others. When designing certificate-based security like this, developers must consider expiration and therefore rotation of keys and certificates and how to achieve that smoothly. Nothing lasts forever...
At least future rotations should work better, based on the experiences here.
- Secure Boot and Microsoft CA Rollover - a heads-up for distributions, SteveMcIntyre
- Windows Secure Boot certificate expiration and CA updates, Microsoft
- Guidance for the Microsoft 2023 Secure Boot CA Transition, Jan Setje-Eilers
- Microsoft UEFI CA rotation: What it means for Ubuntu users and vendors, Julian Klode
- Secure Boot Certificate Changes in 2026: Guidance for RHEL Environments, Red Hat
- Expiration of Secure Boot signing certificates in 2026 RedHat blog, Marta Lewandowska
- What you need to know about the Microsoft Secure Boot certificate expiration: Don’t Panic!, Fedora Magazine, Marta Lewandowska
- https://support.scc.suse.com/s/kb/Microsoft-secure-boot-certificate-changes?language=en_US, SUSE
- https://rockylinux.org/news/2026-06-02-secure-boot-ca-kek-transition, Rocky Linux
- Secure Boot certificate updates for Linux on Azure virtual machines, Microsoft Support