Debian 13.6 Ships a Fix for the Expired Secure Boot CA

Debian 13.6, the sixth point release of trixie, shipped on July 11 with an unusually consequential package bump: fwupd moved to upstream 2.0.20, which can update the Secure Boot certificate authority, Key Exchange Key and revocation database stored in your machine's firmware. The reason a stability-only point release is touching firmware trust stores is that the 2013 UEFI Secure Boot CA, the certificate baked into most PCs and used to sign the bootloaders that let Linux boot with Secure Boot on, has expired. Your machine still boots today. The problem is the next shim update.

• Debian 13.6 released July 11, 2026, folding in security advisories DSA-6250 through DSA-6384, with over a hundred advisories addressed.
• fwupd 2.0.20 can now push CA, KEK and DBX updates to firmware, the mechanism for getting the 2023 Microsoft UEFI CA onto machines that only shipped with the 2011/2013 one.
• Expiration affects signing, not validation. A system booting Linux today keeps booting. The risk is forward-looking: future shim-signed packages carry the new CA's signature, which old firmware will not trust.
• Check your own machine with mokutil --db --short. Two entries good, one entry means you need a firmware update.

What actually expired, and what did not?

This is where most coverage gets muddled, so it is worth being precise. Debian's own announcement refers to the 2013 UEFI Secure Boot CA. Other outlets call it Microsoft's CA and date it to 2011. Both are describing the same certificate. It was issued in 2011 as "Microsoft Corporation UEFI CA 2011" and started appearing in shipping firmware around 2013, which is where the naming divergence comes from. Its job is narrow and important: signing third-party boot components, which in practice means shim, the small shimmed loader that lets a Linux distribution boot on a machine whose firmware only trusts Microsoft.

RelatedSvelteKit Ships Breaking API Changes: Sync Requests, refreshAll

That certificate's signing validity ended on June 27, 2026. Here is the part that prevents panic: expiration affects signing, not validation. The 2011 public certificate sitting in your firmware's trust database does not evaporate, and UEFI firmware checks a signature against the certificate that was valid at signing time rather than against today's date. A machine that boots Linux with Secure Boot enabled today will keep booting tomorrow, next month, and after the certificate's nominal expiry. Nothing breaks retroactively.

The risk is entirely forward-looking. Microsoft cannot use the 2011 key to sign anything new. So every new shim-signed build from here is signed by the Microsoft UEFI CA 2023. If your firmware has that 2023 certificate, the new shim validates and life continues. If your firmware only ever received the 2011 certificate and no OEM update has added the 2023 one, then the moment your distro ships a shim update signed by the new CA, your machine stops booting with Secure Boot enabled. You installed a routine security update and bricked your boot path.

What did Debian actually change?

Point releases for Debian stable do not introduce features. They exist for stability and security fixes, which makes the fwupd bump notable: getting a mechanism for updating firmware trust stores into a maintenance release is Debian deciding this is a stability issue rather than a feature.

fwupd 2.0.20 gained the ability to update the Secure Boot CA, KEK and DBX databases, using the Linux Vendor Firmware Service as the distribution channel where a vendor has published an update. Alongside it, shim and shim-signed were updated to ensure compatibility with the 2023 Microsoft UEFI CA, with pre-installation boot-issue checks and combined signature verification. The shim-helpers packages were realigned to the 2023 CA requirements too. That pre-installation check is the important defensive addition: it is the package refusing to install an update that would leave your machine unbootable.

Debian's guidance is direct: apply CA, KEK and DBX updates from your system OEM. The wiki page at wiki.debian.org/SecureBoot/CAChanges has the detail.

How do you check your own machine?

One command, and it takes a second:

mokutil --db --short

If the output lists both "Microsoft Corporation UEFI CA 2011" and "Microsoft UEFI CA 2023", your firmware is ready and you can stop reading. If only the 2011 entry appears, you need the 2023 certificate installed. The usual fix is sudo fwupdmgr update, which pulls firmware updates through the Linux Vendor Firmware Service, assuming your vendor has published one. If fwupd has nothing for your hardware, the remaining option is the manufacturer's support page directly, and the honest reality is that some older hardware will never get an update, because the OEM has moved on.

RelatedLaravel Adds Native Postgres Pooler Support for PgBouncer

That last category is the uncomfortable one. Machines whose vendors have stopped publishing firmware are the ones that will eventually hit this wall, and the workaround is either disabling Secure Boot or enrolling keys manually via MOK. Neither is a great answer for a fleet.

What else landed in 13.6?

The release folds in Debian Security Advisories DSA-6250 through DSA-6384, addressing over a hundred advisories across trixie. One oddity worth knowing about: geoip-database was reverted to a version dated around December 2019 for licensing reasons, because newer GeoLite releases are not compatible with the Debian Free Software Guidelines. If you have applications relying on that database for IP-to-location mapping, they are now working from allocation data that is more than six years stale. That is a correctness problem hiding inside a licensing decision, and it will bite quietly rather than loudly.

Our take

This is what a slow-motion infrastructure problem looks like: no exploit, no CVE, no attacker, just a certificate reaching the end of its validity period and an entire trust chain quietly discovering that nobody planned for the handoff. The technical fix is boring and correct. What is interesting is the structural lesson, which is that the Linux boot path depends on a certificate authority operated by Microsoft, and the industry's plan for rotating it amounts to hoping OEMs push firmware updates to hardware they stopped caring about years ago.

Debian handled it well. Putting fwupd 2.0.20 and the shim pre-install checks into a maintenance release, rather than waiting for the next stable, is the right call, and the pre-installation boot-issue check is genuinely thoughtful engineering: refusing to install the update that would break you is better than any documentation. The part that should worry people is the long tail. Every machine whose vendor has stopped publishing firmware is now on a countdown, and the answer for those users is going to be turning Secure Boot off. A security mechanism that degrades into "disable the security mechanism" for older hardware is not a great end state, and it was entirely foreseeable a decade ago.

Original analysis by GenZTech. Release detail from the official Debian 13.6 announcement.