Mustafa ERBAY

Posted on Sep 9 Originally published at mustafaerbay.com.tr

Secure Boot's 2011 Certificates Expired and Everything Booted Anyway

#secureboot #uefi #windowsserver #linux

When a certificate expires, you expect noise. An alert fires, a page throws an error, the phone rings. Secure Boot's 2011 certificates expired on 24 and 27 June 2026, and nothing happened. The servers came up the next morning exactly as always, not a single ticket was raised, nobody called.

This is the kind of incident I like least: the kind that invoices you later. Black boxes spend their worst nights without telling anyone.

This piece is about what those quietly expiring certificates actually broke, what they did not break, and what changes on 19 October. I started by looking at my own fleet, because I wanted to see the table before the theory.

What the fleet actually showed

I ran a one-line query across the machines I manage. Windows keeps the state of this update in two registry values:

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' `
  -ErrorAction SilentlyContinue |
  Format-List UEFICA2023Status, WindowsUEFICA2023Capable

Keep in mind that the query can come back empty: if the key was never created, the output is silently blank, and that means "no data", not "no problem". Count a missing value as zero in your inventory.

Across 16 Windows machines (15 servers, 1 client), today's result was this:

State	Count
`Updated` — the update completed	9
`InProgress` — running	1
`NotStarted` — never began	6

The second column turned out to be more interesting: on 3 machines the 2023 certificate is not in the firmware database at all (WindowsUEFICA2023Capable = 0). One 2016 box, one 2019 box, and — the one that surprised me — a 2022 server. So you cannot wave this away as "the old versions lag behind"; the distribution follows firmware and update history, not the OS version.

My two physical virtualization hosts then demonstrated exactly the trap that made me write this article. Their status line said NotStarted, and I reflexively noted them as exposed. The second value changed the picture: WindowsUEFICA2023Capable = 2, meaning the certificate is already in the database and the machine is booting from the 2023-signed boot manager. An inventory that reads one key would have sent me chasing the wrong servers.

What expired, and what replaced it

Three certificates Microsoft issued in 2011 began expiring in sequence. The dates:

Expiring certificate	Date
Microsoft Corporation KEK CA 2011	24 June 2026
Microsoft UEFI CA 2011	27 June 2026
Microsoft Windows Production PCA 2011	19 October 2026

The 2023 certificates replacing them land on different shelves of the firmware: Microsoft Corporation KEK 2K CA 2023 goes into the KEK, while Windows UEFI CA 2023, Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023 go into the DB.

Do not treat that split as trivia, because those shelves hold different links of the chain. The KEK is the authority to accept subsequent updates, revocation list included. The DB is the list of "which signatures may boot". I wrote about the trust root itself in a piece on Secure Boot and TPM; the difference here is that the same architecture has now collided with a calendar.

So why did nothing break?

One sentence: firmware does not look at a certificate's expiry date when it validates a signature. Canonical states this plainly — existing boot assets remain bootable unless they are explicitly revoked.

Microsoft says the same thing from its side: devices that have not received the new certificates "will continue to start and operate normally", and regular Windows updates keep installing.

What you lose is felt tomorrow, not today. A machine that has not been updated cannot receive new protection for the early boot phase: boot manager updates, Secure Boot database and revocation list (dbx) updates, fixes for newly discovered boot-level vulnerabilities. In Microsoft's own words, a device in that state becomes "progressively less protected".

Let me put the stakes plainly: code that runs in the early boot phase runs before the operating system. Your EDR does not see it, because your EDR has not loaded yet.

The real loss is on the revocation side

The conversation usually circles around "will my machine boot", but in my view the real loss is on the revocation side.

Secure Boot does not only keep an allow list; it keeps a deny list too. The DB says "this signature may boot", while dbx says "this signature is no longer valid". When a vulnerability is found in the boot path, the defence produced is often not a patch but a revocation entry: the broken component's signature is written into dbx and it never boots again.

The KEK is the key authorised to update both lists. Picture the chain like this: the KEK updates the lists, the DB permits booting, dbx takes permission away. If the KEK side has aged out, the tap above closes — Microsoft explicitly writes that devices without the new certificates will not receive Secure Boot database and revocation list updates either.

In practice that means this: the machine may have no known boot-level vulnerability today, but you also have no way to close the one that shows up tomorrow. You count yourself protected because Secure Boot is enabled, while the part of that protection that gets updated has quietly frozen on your machine. The most dangerous state for a security control is not being switched off; it is looking switched on while nothing updates.

Why 19 October is the date that matters

What expired in June was signing authority. What expires in October is the certificate that signs the Windows boot manager: Microsoft Windows Production PCA 2011.

Boot managers produced after that date will be signed with Windows UEFI CA 2023. A machine without that certificate in its DB cannot validate the new boot manager. The result is not a crash — the machine keeps booting the old, still-verifiable boot manager — but it drops out of boot manager updates permanently.

In my fleet that is three machines with names I can point at. Do not guess your own number; measure it. I did not expect the spread to be this uneven before I looked.

Read both keys, not one

The two values from that query answer different questions.

UEFICA2023Status tells you where the process is: NotStarted (it has not run yet), InProgress (running), Updated (completed successfully).

WindowsUEFICA2023Capable tells you what that produced in firmware: 0 (or the value missing entirely) the certificate is not in the DB, 1 it is in the DB, 2 it is in the DB and the system is starting from the 2023-signed boot manager.

Neither substitutes for the other, because they measure different things: one is where Windows' servicing flow stands, the other is what the firmware currently holds. The certificate can have reached the DB by another route while the servicing flow never ran — that is what happened on my hosts. The reverse happens too.

There is a third signal worth collecting: in the event log, ID 1808 reports that the certificates were applied, and 1801 that they were not. Since April 2026 the Windows Security app also shows the same state under Device security > Secure Boot with a green, yellow or red badge, covering Windows Server 2019, 2022 and 2025. Do not skip Microsoft's caveat here: a green check alone does not confirm the certificates are updated — you have to read the text underneath it.

Checking machines one by one works at fifteen servers, not at three hundred. Microsoft publishes a sample inventory collection script, and on the deployment side it documents Group Policy and Intune methods alongside the registry. I collected my first pass with a single command through my own remote-management tooling; which tool you use does not matter, only that the results land in one table.

Do not produce this inventory once and shelve it. The values move — the machine I saw as InProgress has probably finished by the time you read this. A monthly check will spare you an avoidable surprise before October.

Who applies the update: Microsoft, or you?

There are two paths, and the choice genuinely depends on your situation.

The first path hands the work to Microsoft: you set MicrosoftUpdateManagedOptIn to 1 under HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot. It is disabled by default and requires the device to send optional diagnostic data.

The second path keeps control: you set AvailableUpdates in the same place to 0x5944 and trigger the \Microsoft\Windows\PI\Secure-Boot-Update scheduled task. The task already runs every 12 hours on its own, so waiting is a legitimate option if you are patient.

On that second path you can watch progress through AvailableUpdates itself. The value is a bit mask: each step clears its own bit as it completes. When you see 0x4100, the reboot is your move. The 0x4000 left behind is not a step but a condition flag that is never cleared — in practice you can read it as "the work is done". Microsoft fixes the order of the steps, and each one waits for the previous to succeed:

If it were my call, I would put the client fleet on the first path and the servers on the second. The reason is simple: on servers I want to decide when the reboot happens; on clients, trying to make that decision is wasted effort.

On some devices the process will not complete without a firmware update. If UEFICA2023Error is non-zero, look at the OEM's BIOS version before poking the registry again.

Let me name the most unpleasant possibility too: updating the KEK requires authorisation signed by the device's Platform Key, and that key belongs to the OEM. If the vendor never ships an update, the machine stays stuck at that step permanently; Microsoft says recovery then requires OEM-specific guidance, and Canonical writes that availability of KEK updates varies by device vendor, with some devices having no updates available yet. On end-of-life hardware the answer may simply be "replace this machine".

Then there is disk encryption. An operation that changes Secure Boot variables and the boot manager shifts the measured boot values, and that can drop BitLocker into its recovery screen. Microsoft describes this as usually transient, hitting the first restart only: the firmware does not yet report the updated values when Windows tries to reseal, so the seal fails and the next boots return to normal. Recurring cases are documented as well. That is why I confirm the recovery keys are genuinely reachable before touching a pilot ring, and suspend BitLocker if a firmware update is part of the job. On a server, a recovery screen you cannot reach a console for is an outage.

The Linux side: shim's signature is changing

On Linux the story turns around the same certificate, but the trap sits somewhere else.

Linux distributions enter Secure Boot through a small loader called shim; as Debian's own wiki explains, this loader is signed by Microsoft and embeds the distribution's own keys. If the signing certificate is missing from the DB, the machine fails to boot with a security violation; in Debian's own framing, the firmware simply does not trust shim, and that is the end of it.

Here is where it actually bites. Canonical says the shim updates it ships after the June 2026 expiry will be signed with the new 2023 CA, and that updates released in Q4 2026 or later will require it. In its own words, failing to upgrade the CA can break package management — the ability to install updates, security ones included, as well as new packages.

This next part is my inference, not Canonical's sentence: on a machine whose DB lacks Microsoft UEFI CA 2023, replacing a boot component with one carrying a different signature puts the boot at risk. So do not invert the order — the DB update belongs before the shim update.

Canonical's recommended path goes through the firmware update tool: fwupd 2.0.0 or newer, then sudo fwupdmgr refresh and sudo fwupdmgr update. The updated components shipped with 25.10 and 26.04 LTS; the backports for 22.04 and 24.04 LTS were released on 9 June 2026.

The inverse case exists too, and it concerns anyone buying new hardware: some 2024-and-later machines never carried the 2011 certificate in their DB, only the 2023 one. Your existing installation image will not boot there.

Virtual machines and Hyper-V

On virtual machines the firmware comes from the hypervisor, so the question becomes who does the updating. Microsoft describes two routes: either the virtualization platform ships the certificates in its own firmware, or — if the virtual firmware supports Secure Boot updates — the update is applied through Windows like on any other device.

There is one Hyper-V detail worth knowing, or you will spend a while blaming yourself: a known issue caused the update to fail on virtual machines with event ID 1795, it was marked resolved on 30 March 2026, and the fix requires the March 2026 updates to be installed on both the Hyper-V host and the guest OS. If an earlier attempt got stuck, check the host first, then try again.

The spread in my own fleet backs this up: most of the virtual servers sit at Updated, while a 2019 server on the same host is still at 0.

What to do this week

Prepare your way out first: verify BitLocker/encryption state and that recovery keys are reachable, and confirm out-of-band console access to your servers works.
Build the inventory. Collect both registry values plus events 1808/1801 into one table; do not trust a single key.
Separate the machines where WindowsUEFICA2023Capable = 0. That is the group which drops out of boot manager updates after 19 October.
Check firmware versions. On machines that error out, the fix is usually on the OEM's side.
Pick a pilot ring and run the 0x5944 path there; plan the reboot window yourself.
On Linux machines, check the fwupd version and get the DB update done before the shim update arrives.
Do not forget your installation images and recovery media. An old image on new hardware, a new image on old hardware — both fail the same way.

Closing

What this episode teaches is not really about Secure Boot. Trust roots age quietly. When a certificate expires the system does not fall over; it simply closes itself to the future — and the most expensive failures in infrastructure are the ones that do not look like failures.

19 October is on your calendar. The question to answer before then is not "do my servers still boot" — they all do. The question is this: when a vulnerability appears in the early boot layer tomorrow, who is on the list of machines that can still take the fix?

DEV Community