Secure Boot certificate expiration on Linux: 2023 CA, shim and dbx checks

Linux systems with Secure Boot keep booting after the 2026 certificate expirations, because UEFI firmware does not check expiry dates when it verifies a signature. The certificate that matters for Linux, the Microsoft UEFI CA 2011 that shim is signed under, expired on June 27, 2026, and the Microsoft Corporation KEK CA 2011 expired on June 24. What changes is servicing: new shims and new revocation updates are signed only under the 2023 replacements, so a machine needs Microsoft UEFI CA 2023 in db to boot future shims and Microsoft Corporation KEK 2K CA 2023 in KEK to apply future db and dbx updates.

The quick test is two commands: mokutil --db | grep 'Microsoft UEFI CA 2023' and mokutil --kek | grep 'KEK 2K CA 2023'. If both print a line, the machine is ready. Status below is as of October 2026; see also our Security section.

Which certificates expired

Microsoft's expiration table lists three 2011 certificates and their successors:

• Microsoft UEFI CA 2011 (stored in db): expired June 27, 2026. It signed third-party boot loaders such as shim, and option ROMs on add-in cards. It is replaced by Microsoft UEFI CA 2023 for boot loaders and Microsoft Option ROM UEFI CA 2023 for option ROMs.
• Microsoft Corporation KEK CA 2011 (stored in KEK): expired June 24, 2026. It signs updates to db and dbx. Its successor is Microsoft Corporation KEK 2K CA 2023.
• Microsoft Windows Production PCA 2011 (stored in db): signs the Windows boot loader and expired on October 19, 2026. Our Windows checklist covers it.

The new third-party CA is valid until June 2038, as the certificate listing in Red Hat's guidance shows.

Why existing installs keep booting

When firmware loads shim, it checks that the signature chains to a certificate in db and that nothing involved is listed in dbx. Canonical says UEFI firmware ignores CA expiry dates in that check, so shims signed under the 2011 CA stay bootable unless they are revoked. Debian's wiki notes the exception: buggy firmware.

The problem is on the signing side. From October 2025 until the old CA expired, Microsoft returned shims with two signatures, one per CA. New submissions can now only receive the 2023 signature, LWN reports, including any future shim security fix, and such a shim will not boot on a machine whose db lacks Microsoft UEFI CA 2023.

Revocations work the same way. Since June 24 the old KEK can no longer sign authenticated db or dbx updates, according to the shim-review guidance for distributions. A machine without the 2023 KEK keeps the dbx it has, but cannot apply revocations Microsoft signs after the expiry.

What distributions ship as of October 2026

• Red Hat Enterprise Linux: the x86_64 shim for RHEL 8, 9 and 10 (shim-x64 16.1-2, 16.1-7 and 16.1-4) is signed with both keys. On aarch64, Red Hat ships a shim carrying only the 2023 signature. Red Hat's blog says RHEL 7.9 will not get a dual-signed shim.
• Debian: the July 11, 2026 point releases, 13.6 and 12.15, updated shim-signed for compatibility with the 2023 CA and shipped fwupd 2.0.20, which can update the CA, KEK and DBX databases. Debian describes the new shim as dual-signed and expects some machines with buggy firmware not to boot it.
• Ubuntu: Canonical says shims it ships after the June expiry are signed with the 2023 CA, and that new releases, plus stable-release updates from Q4 2026 onward, will need that CA; without it, package management may fail. Existing installation media, including 26.04 LTS, and the 26.04 LTS cloud images still require the 2011 CA.
• AlmaLinux mirrors the RHEL approach and keeps a step-by-step checklist.

Debian also notes that some new machines ship with only the 2023 CAs and will not trust older software, so a 2011-only installer can fail on them.

How to check a Linux machine

1. Secure Boot state: mokutil --sb-state prints SecureBoot enabled or SecureBoot disabled.
2. db: mokutil --db | grep 'Subject:' should list CN=Microsoft UEFI CA 2023 and CN=Microsoft Option ROM UEFI CA 2023 next to the 2011 entries.
3. KEK: mokutil --kek | grep 'Subject:' should list CN=Microsoft Corporation KEK 2K CA 2023.
4. Platform Key: mokutil --pk shows who owns the PK; a KEK update must be signed with that key, so it tells you whose update you need.
5. Without mokutil: efitools gives the same view with efi-readvar -v db and efi-readvar -v KEK.
6. Your shim's signatures: sudo pesign -S -i /boot/efi/EFI/redhat/shimx64.efi (use your distribution's directory), or sbverify --list on the same file. A 2011 signature names the signer Microsoft Windows UEFI Driver Publisher; a dual-signed shim shows a 2023 signature as well.
7. Revocations: fwupdmgr get-devices lists a UEFI dbx device whose version is a date (see the dbx plugin notes), and mokutil --list-sbat-revocations prints the SBAT revocation entries that shim enforces.

Adding the 2023 certificates with fwupd

On physical hardware there are two routes: an OEM firmware update that includes the new certificates, or fwupd, which installs db, KEK and dbx payloads that Microsoft and hardware vendors publish through the LVFS (Linux Vendor Firmware Service). The db and KEK plugins arrived in fwupd 2.0.8 (db and KEK plugin notes), the minimum in Microsoft's Azure Linux guidance; Debian found 2.0.8 insufficient and recommends 2.0.20 from trixie-backports. Canonical says Ubuntu 22.04 and 24.04 LTS now have a fwupd new enough for the certificate updates, and older releases can use the fwupd snap.

1. sudo fwupdmgr refresh downloads current metadata.
2. sudo fwupdmgr get-updates shows what is offered. On Ubuntu the transition appears as four updates: Windows Production PCA, UEFI CA, KEK CA and UEFI dbx.
3. sudo fwupdmgr update installs them; reboot and rerun the mokutil checks.

The shim-review guidance recommends installing the db update first, rebooting and verifying, and only then the KEK. Microsoft's Azure guidance adds that UEFI variables must be updated before the shim, or a VM may fail to boot.

Before running it:

• The KEK depends on your vendor. fwupd can offer a KEK update only if the OEM has published one signed with its Platform Key on the LVFS; Microsoft's own KEK payload fits only machines whose PK is Microsoft's. If nothing is offered, ask the vendor; Debian considers the KEK less urgent than db.
• Some firmware rejects standalone db updates. Red Hat says certain HP and Fujitsu systems need a firmware update first. Do not force the payload.
• TPM-bound encryption. Updates to KEK, db or dbx generally change the PCR 7 measurement. Re-seal TPM-bound LUKS keys around the reboot (Red Hat suggests temporarily sealing to an unchanged PCR such as PCR 0) and keep recovery passphrases ready.
• Leave the 2011 CA in place. Red Hat warns that option ROMs signed under it will not run if it is removed or revoked, and revoking it in dbx would also block dual-signed shims.

Dual-boot PCs, virtual machines and images

Dual boot with Windows. When the 2011 third-party CA is already in db, Windows' Secure Boot task also adds Microsoft UEFI CA 2023 and the Option ROM CA 2023, per Microsoft's IT guidance, so an updated Windows install may have done the db step for Linux already. Check with mokutil first. Microsoft also documents that some BitLocker configurations go into recovery when a Secure Boot update is applied, so keep the recovery key at hand.

KVM and libvirt. New VMs copy their variable store from the host's OVMF template, so update edk2-ovmf (ovmf on Debian and Ubuntu) on the hypervisor; Red Hat lists the minimum builds with both CAs. Existing VMs keep their old NVRAM: run fwupd in the guest, or recreate the store with virsh start vm-name --reset-nvram (libvirt 8.1.0 or later), which also resets boot order and MOK enrollments.

Ubuntu VMs. The private Platform Key for Ubuntu's OVMF and AAVMF variable templates was discarded at generation time, so the normal KEK path is closed. Canonical instead added firmware logic that applies the update at boot. When it posted, that firmware had shipped for Ubuntu 26.04 LTS and LXD 6.8, with older releases in preparation. TPM-encrypted VMs may then ask for a recovery key.

Azure. Microsoft says Linux Trusted Launch and Confidential VMs created before April 2024, plus snapshots, backups and gallery images made from them, need the update. Confidential VMs from that period should not be updated by hand because disk encryption depends on PCR 7; recreate them from a Compute Gallery image. More in our Cloud section.

Other platforms and images. On Hyper-V, VMware and public clouds, run the same mokutil checks inside the guest. Keep installer ISOs and golden images on a dual-signed shim during the transition.

Frequently asked questions

Will Linux stop booting now that the Secure Boot certificates have expired?

No. Firmware ignores certificate expiry, so installed shims signed under the 2011 CA keep booting unless they are revoked. The risk is that future shim and revocation updates need the 2023 certificates.

How do I check for Microsoft UEFI CA 2023 on Linux?

Run mokutil --db | grep 'Microsoft UEFI CA 2023'. Any output line naming that certificate means it is in db; for the KEK, run mokutil --kek | grep 'KEK 2K CA 2023'.

Can fwupd update the Secure Boot KEK?

Yes, from fwupd 2.0.8, but only if your hardware vendor has published a KEK update signed with the machine's Platform Key on the LVFS. If none is offered, install the db update if one is available and ask the vendor.

Do I still need dbx updates on Linux?

Yes. fwupd installs dbx updates from the LVFS, but revocations Microsoft signs after June 2026 use the 2023 KEK, so the machine needs that KEK to receive them. Shim also enforces its own SBAT revocations, which ship inside shim updates.

Does any of this matter if Secure Boot is disabled?

Not for booting: Red Hat says systems with Secure Boot disabled are not affected. Debian's wiki still advises against turning Secure Boot off to avoid the transition, since it blocks persistent boot-level malware.