The Secure Boot Cert Expiry Won't Brick Your Box — But It Bites Elsewhere

Every few years a cryptographic clock runs out and the internet briefly convinces itself that millions of machines are about to stop booting. The expiration of Microsoft's 2011 Secure Boot signing certificate is this season's version, and the reflexive panic is mostly misplaced. A system that boots Linux with Secure Boot enabled today will keep booting after the key expires — that part is settled across every serious source. But "your laptop is fine" is doing a lot of quiet work to hide where the actual exposure sits: new installs, fleet-wide firmware rollouts, TPM-sealed secrets, and the long tail of hardware nobody will ever patch again.

The real story here isn't a deadline. It's that the entire Linux Secure Boot chain hangs off a single, vendor-controlled trust anchor baked into firmware shipped by dozens of OEMs — and rotating that anchor at planetary scale is exactly as messy as you'd expect.

What's actually expiring, and why your machine doesn't care

The certificate in question is the Microsoft Corporation UEFI CA 2011, the key Microsoft uses to sign third-party boot components — most importantly shim, the small first-stage bootloader almost every Linux distribution uses to satisfy Secure Boot before handing off to GRUB and the kernel. Per Red Hat's guidance, that certificate expires on June 27, 2026, with the related KEK CA 2011 — which signs updates to the firmware's trusted (db) and forbidden (dbx) databases — aging out three days earlier, on June 24.

When this first surfaced on the Fedora and LWN side in mid-2025, the timeline looked more urgent, with a near-term 2025 expiry flagged for the shim-signing key. The picture has since sharpened: the operative deadline for the Linux trust anchor is June 2026, and the months in between bought maintainers time to do the work properly.

The critical distinction — the one that gets mangled in every breathless thread — is signing versus validation. Expiration stops Microsoft from signing new shim binaries with the old key. It does not revoke the key or yank it out of your firmware's db. Firmware checks a signature against the certificate that was valid at signing time, not against today's date. Your already-signed shim was signed while the key was valid, so it keeps validating. Nothing reboots into a brick.

The replacement, Microsoft UEFI CA 2023, has been signing components since October 2025. The clever bit of the transition is dual signing: a single shim binary carrying both the 2011 and 2023 signatures, which boots on any machine that trusts either certificate. That's the whole point — it papers over the fact that out in the field, some firmware has only the 2011 key, some has both, and a growing share of newer hardware ships with only the 2023 key (and therefore can't even boot today's older install media).

Where the distros stand

If you run a mainstream distribution and keep it patched, the maintainers have already absorbed the worst of this for you. The fix on every distro is the one-liner you already run.

Red Hat's new shim is signed with both Microsoft certificates, so it boots regardless of which key a given board trusts. AlmaLinux and Rocky inherit this essentially for free because they track RHEL's shim packaging. The enterprise fleet, in other words, is the easy case.

The part that will actually hurt

Here's where a threat-model lens earns its keep. The genuine operational risk is concentrated in three places, none of which is "the certificate."

TPM-sealed secrets. Updating the UEFI db to enroll the 2023 key changes the system's measured boot state — specifically the TPM Platform Configuration Register values, and PCR7 in particular. If you've sealed anything against PCR7, that seal breaks on the next boot. The obvious casualty is TPM-based automatic LUKS unlocking: enroll the new key, reboot, and the disk no longer auto-unlocks because the measurement it was sealed to no longer matches. The same applies to Measured Boot with local or remote attestation, Trusted Boot, and any secret you've bound to PCR7.

Red Hat's prescribed sequence is unintuitive enough that it's worth burning into muscle memory: after updating the db, do not reboot. First reseal against a PCR that didn't change — PCR0 is the suggested anchor — then reboot, then reseal against the new PCR7 value. Get the order wrong and you're typing recovery passphrases into a console at 2 a.m.

The firmware long tail. The 2023 key only helps if it actually lands in your firmware's database, and that depends on the OEM. The plumbing for this on Linux is fwupd and the Linux Vendor Firmware Service, which can push either a full firmware update or a narrower Key Exchange Key (KEK) update that injects the new key. LVFS's own numbers put KEK updates at roughly 98% success and db updates at roughly 99% — reassuring until you remember that 1% of millions is still a lot of failed deployments. The common failure is efivarfs running out of contiguous space for new EFI variables; the field fix is to reboot and reset the BIOS to factory defaults, which "defragments" the variable store. Older firmware is disproportionately likely to hit it.

And that's the hardware that gets updates. Old physical servers, abandoned consumer laptops, appliances, and embedded devices that never see another firmware bump after they ship cannot update their db at all. For those, the only path to installing fresh media may be disabling Secure Boot outright — trading the security feature for the ability to function.

Process risk at the root. Two details from the kernel and firmware discussions deserve more alarm than they've gotten. A KEK update has, by some accounts, never happened before at this scale, so there's real chance some BIOS vendors implemented it wrong. Worse, at least one manufacturer has reportedly lost the private half of its platform key (PK) — the vendor key burned into the hardware. Replacing platform keys in the field is uncharted territory and, from an attestation standpoint, a genuinely bad idea: the whole value of a hardware root of trust evaporates if the root can be quietly swapped.

What to do, in order

For a single workstation, this is nearly a non-event: keep your distro patched and you've shipped the dual-signed shim already. For anyone running a fleet, attestation, or encrypted-at-rest infrastructure, treat it as a scheduled change with a rollback plan.

# Is Secure Boot even on?
sudo mokutil --sb-state

# Which certs does this firmware already trust?
# Look for "Microsoft UEFI CA 2023" alongside the 2011 entry.
sudo mokutil --db

# Pull vendor firmware / KEK updates via LVFS
sudo fwupdmgr update

Concrete sequence:

• Inventory first. Script mokutil --db across the fleet and bucket machines into has-2023, has-both, has-only-2011, and has-only-2023. The last bucket can't boot your older install media; the third is your update target.
• Test db/KEK updates per model before automating. Validate fwupdmgr on one box of each model/firmware revision. If LVFS offers nothing for a board, that's an OEM ticket, not a Linux problem.
• Quarantine your PCR7-sealed systems. Anything using TPM LUKS unlock, clevis/systemd-cryptenroll bindings, or remote attestation gets the don't-reboot, reseal-PCR0, reboot, reseal-PCR7 dance — not a blind fwupdmgr update in a maintenance window.
• Don't forget the virtual estate. Per Broadcom, vSphere VMs with Secure Boot that lack the 2023 certificates are affected regardless of guest OS, though VMs on Hardware Version 12 or earlier aren't in scope. Cloud images carry the same baggage — Shielded VMs created before certain cutoff dates may need the updated certs enrolled too.
• Refresh your install media. Old ISOs signed only with the 2011-era shim will fail to Secure Boot on 2023-only firmware. Rebuild golden images on current shim.

The take

Strip away the countdown-clock framing and this is a well-telegraphed certificate rotation that the major distributions handled competently and early. For the patched mainstream, it's a dnf update away from done. The honest verdict: not a crisis, but not a non-event either — the risk simply moved off the desktop and onto the places that don't make headlines. If you operate fleets with measured boot or TPM-sealed disks, the PCR7 reseal ordering is the single detail most likely to ruin your week. And the unsolved residue — unpatchable firmware, a never-before-exercised KEK rotation, an OEM that lost its platform key — is a quiet reminder that a single vendor-controlled trust anchor in hardware was always going to be hard to rotate. June 27 is the easy deadline. The long tail is the one with no clean answer, and we won't know its real size until people start hitting it in the field.