HN Debrief

Linux and Secure Boot certificate expiration (2025)

  • Security
  • Linux
  • Infrastructure
  • Developer Tools

The article is about a certificate rollover inside the Linux Secure Boot chain. Many Linux distributions rely on a small Microsoft-signed loader called shim so they can boot on PCs whose firmware trusts Microsoft's UEFI keys by default. The older Microsoft certificate used in that path expires in 2026, and systems that still only trust the old key may reject newly signed boot components unless firmware databases and related keys are updated first. That is why distributors and tools like fwupd have been pushing updates now.

Treat this as an upgrade-path problem, not a mass reboot apocalypse. Check whether Secure Boot is enabled and whether your firmware trusts the 2023 Microsoft key, especially on managed fleets, laptops, and Secure Boot-enabled VMs.

Discussion mood

Mostly pragmatic and mildly irritated. People were frustrated by vague coverage and by Secure Boot's dependency on Microsoft and flaky firmware behavior, but the mood shifted away from panic once commenters clarified that existing systems usually keep booting and that the real pain is around updates, firmware state, and VM edge cases.

Key insights

  1. 01

    Existing boots are usually safe

    Existing installed EFI binaries generally keep loading after the old certificate expires. The breakage shows up when firmware that only knows the 2011 Microsoft key is asked to verify newer boot components signed through the 2023 chain, which is why Debian's guidance focuses on updating trust databases before later bootloader updates land.

    Do not schedule emergency maintenance just to avoid a one-day cliff. Audit upgrade and recovery workflows instead, because that is where old firmware trust stores will bite you.

      Attribution:
    • epakai #1 #2
    • ChocolateGod #1
  2. 02

    There is a simple first check

    You can get a quick answer with mokutil rather than digging through firmware menus. Commenters used `mokutil --sb-state` to see whether Secure Boot is enabled and `mokutil --db --short` to inspect enrolled keys, with the practical rule of thumb that seeing the 2023 Microsoft keys means you are on the modern path.

    Add a lightweight Secure Boot health check to your fleet scripts and workstation docs. It is faster than guessing from BIOS settings or waiting for a failed upgrade.

      Attribution:
    • Hugsbox #1
    • Bender #1
    • Animats #1
  3. 03

    Firmware variable storage can block updates

    The ugly implementation detail here is UEFI variable storage, or efivar space. Machines can have too little non-volatile space, or not enough contiguous free space, to accept the updated key databases, which turns a routine trust-store refresh into firmware cleanup and sometimes forces people to disable Secure Boot entirely.

    If you manage laptops or embedded PCs, test certificate rollout on representative hardware before broad deployment. Low efivar capacity can turn a policy update into a support incident.

      Attribution:
    • 0xCMP #1
    • Bender #1
  4. 04

    Custom keys avoid the Microsoft dependency

    Several people pointed out that the cleanest long-term setup is to put Secure Boot in setup mode, enroll your own keys, and sign your own boot chain. That removes the certificate rollover problem tied to Microsoft's default OEM trust path, though it also shifts lifecycle work onto you.

    For high-trust internal devices, developer laptops, or appliance-like systems, consider standardizing on your own Secure Boot keys. You trade convenience for control, but you stop inheriting Microsoft's key transitions.

      Attribution:
    • drnick1 #1
    • Borealid #1
    • vladvasiliu #1
  5. 05

    Shim was a compatibility compromise

    The current model exists because OEMs already ship Microsoft's keys for Windows, not because Microsoft is some uniquely appropriate steward for Linux. Red Hat pushed shim as the only scalable way to let ordinary users boot Linux on commodity PCs without manual key enrollment, and commenters argued that a generic 'trust this media' prompt would gut the whole point of Secure Boot by training users to click through.

    If you are designing a product on commodity PCs, assume the Microsoft-rooted path is the default operational reality. If that is unacceptable, budget for owning key enrollment and support instead of treating it as a small tweak.

      Attribution:
    • maxlybbert #1
    • bri3d #1
    • calgarymicro #1
  6. 06

    VM impact depends on whether Secure Boot is on

    The virtualization angle is narrower than the scary headlines suggested. Secure Boot is often off by default in VMs, and some operators disable it because libvirt and install media handling can be brittle, but platforms like Proxmox have started surfacing warnings and one-click fixes for VMs that do use UEFI Secure Boot.

    Inventory Secure Boot-enabled VM templates now. If your virtualization stack exposes firmware updates separately from guest updates, make that part of image maintenance before new signed media starts failing.

      Attribution:
    • NelsonMinar #1
    • d3Xt3r #1
    • crabbone #1

Against the grain

  1. 01

    fwupd telemetry made the rollout measurable

    Opt-in fwupd analytics gave maintainers real success-rate data for KEK and db updates instead of anecdote. That cuts against the usual complaint that Linux desktop infrastructure is too fragmented to manage, because in this case the ecosystem had enough visibility to spot where updates were landing and where vendor outreach was needed.

    If you build update infrastructure, keep opt-in telemetry on the table for low-level maintenance paths. You need hard rollout data before firmware issues turn into field failures.

      Attribution:
    • its-summertime #1
  2. 02

    Secure Boot still materially protects disk data

    The strongest defense of Secure Boot was not about abstract platform trust. It was about sealing disk encryption keys to a verified boot chain, which sharply reduces offline tampering and data extraction risk compared with a machine that will boot any modified loader and release secrets anyway.

    For lost-or-stolen laptop risk, evaluate Secure Boot together with full disk encryption and key sealing. Judging Secure Boot as a standalone annoyance misses the main security benefit.

      Attribution:
    • bri3d #1

In plain english

db ↩
The Secure Boot signature database that lists certificates or hashes the firmware is allowed to trust for booting.
EFI ↩
Extensible Firmware Interface, often used to describe boot files and partitions that UEFI firmware loads before the operating system starts.
efivar ↩
UEFI firmware variable storage, the small non-volatile area where boot settings and Secure Boot databases are stored.
fwupd ↩
An open source Linux service and tool for distributing firmware updates to devices.
KEK ↩
Key Exchange Key, a Secure Boot database key used to authorize updates to other Secure Boot trust lists.
libvirt ↩
A common Linux toolkit and API for managing virtual machines and related virtualization features.
mokutil ↩
A Linux command-line tool for inspecting and managing Machine Owner Keys and Secure Boot state.
OEM ↩
Original Equipment Manufacturer, a company that builds and ships hardware systems such as laptops or motherboards.
Secure Boot ↩
A UEFI firmware feature that only allows approved boot software to run, using cryptographic signatures.
shim ↩
A small bootloader used by Linux distributions that is signed by Microsoft so Linux can boot on PCs that trust Microsoft's default UEFI keys.
UEFI ↩
Unified Extensible Firmware Interface, the modern firmware standard that replaces the old PC BIOS and starts the operating system.
VM ↩
Virtual machine, a software-emulated computer that runs its own operating system inside another system.

Reference links

Practical guidance

Background explainers

Related tools and examples