Secure Boot certifikáty v Linuxu končí. Stihnete to do září?

Secure Boot's Expiration Problem Is Closer Than You Think

Here's something most Linux users don't think about until it breaks: Secure Boot. It's enabled by default on most modern hardware, and if you're running Ubuntu, Fedora, or any major distro on a machine from the past few years, you're probably using it right now without even knowing.

That "probably" is doing a lot of work in that sentence. And come September 11, it might start causing real problems.

What's Actually Happening

The shim bootloader is the bridge that makes Linux work with UEFI Secure Boot. Without it, your system wouldn't even start. Right now, this little piece of software is signed by a Microsoft key that dates back to 2011—yes, over a decade old. Microsoft has had a replacement key ready since 2023. But here's the catch: a huge number of machines out there still don't have it.

The old signing key expires on September 11. After that date, systems with outdated firmware databases will refuse to load the shim. And for some hardware, getting the necessary update might mean waiting on a firmware patch from your vendor that may never arrive.

Who's Actually Going to Have Issues

For most people already running Linux? You'll probably be fine. Your distro's bootloader has its own keys signed and those should keep working through the transition.

The real trouble shows up in a few specific situations:

• Installing a fresh Linux system on Secure Boot hardware
• Booting from USB or DVD media on machines with old firmware
• Edge cases where hardware vendors have dropped support

Richard Hughes, the mind behind LVFS (Linux Vendor Firmware Service), put it this way: "The KEK updates are going out at ~98% success, and db update is ~99% success—but even 1% multiplied by millions of people is a fair few failures to deploy."

So it's not a catastrophe. But it's not exactly something you want to discover at 2 AM when you're setting up a new server.

The Actual Problem Isn't What You'd Expect

The keys themselves aren't failing. The issue is much more mundane: storage space.

Older UEFI firmware has limited room for EFI variables. When these certificate updates need to be deployed, the system sometimes needs to clear out that storage—which means resetting BIOS to factory defaults. Hughes notes that "the older your BIOS, the more likely you are to hit this."

If you're in that unlucky 1-2%, the workaround usually looks like this:

1. Reboot
2. Reset BIOS to defaults
3. Try the update again

Not elegant, but it works.

How the Community Is Handling It

Here's the good news: the open-source world saw this coming.

The LVFS and fwupd projects—tools that let you update system firmware directly from Linux—have been upgraded to handle certificate rollovers. Most major distributions will ship shim binaries signed with the new Microsoft key, so fresh installs should go smoothly if your hardware is reasonably current.

Vendors are pushing out KEK (Key Exchange Key) updates that let fwupd safely inject the new certificate into your system's firmware database.

For systems where the vendor has gone completely dark? Disabling Secure Boot might be your only option. It's not ideal from a security perspective, but sometimes you work with the hardware you have.

Your Action Plan

If you're managing Linux systems:

1. Audit before September - Know what you're running and which machines have Secure Boot enabled
2. Check for firmware updates - If your vendor released patches, install them now
3. Keep recovery options ready - USB with bootable media, external drive, whatever gets you out of a bind
4. For new installs after September - Make sure your installation media includes the updated shim

The Bottom Line

This isn't the Linux apocalypse. The ecosystem has handled certificate expirations before and will handle this one too. Most systems will sail through without any issues.

But if you're managing multiple machines or planning a deployment in the coming months, a little prep work now beats emergency troubleshooting later. Take an hour to check your firmware status. Update what you can. Document your workarounds.

A few minutes of attention today could save you from a very frustrating morning.