Linux and Secure Boot certificate expiration

Original Article ↗ Hacker News Discussion ↗

Impact of the 2011 Microsoft key expiration

  • Many Linux Secure Boot chains rely (knowingly or not) on a Microsoft third‑party key from 2011 that expires in Sept 2024.
  • If firmware isn’t updated to trust the new 2023 key, new shims/bootloaders may no longer boot, even if the OS itself is updated.
  • Some firmware doesn’t even check expiry, so behavior is hardware‑dependent and unclear.
  • Existing installs may keep working until something in the chain changes (e.g., new shim), which could surprise users months later.
  • Windows bootloaders are also affected by 2026 expirations, so this isn’t only a Linux problem.

Microsoft as CA and power/control concerns

  • Many comments criticize the fact that Linux boot depends on Microsoft’s PKI at all; this is seen as structurally anti‑competitive and a “single point of failure.”
  • Others argue Microsoft’s CA role was inevitable because nearly all x86 PCs are sold as Windows‑capable and no Linux player stepped up early with a competing PKI.
  • There is speculation about legal/regulatory remedies (e.g., EU‑run attestation or mandated multi‑vendor trust), but also fear such intervention could worsen lock‑in.

Security value vs. user freedom

  • Pro‑Secure‑Boot side:
    • Designed to block bootkits/MBR rootkits and support a chain of trust into disk encryption (e.g., TPM‑sealed keys).
    • Helpful in enterprise/server environments and for making FDE transparent for ordinary users.
  • Critical side:
    • For most personal threat models, boot‑level attacks are rare compared to user‑space malware.
    • The real, common “attack” is restricting what OS you can run; phones, consoles and some PCs already demonstrate this.
    • Anything that can lock you out of your own hardware is viewed as a bigger problem than the threats it mitigates.

Linux Secure Boot in practice

  • On mainstream distros (Ubuntu, Fedora, recent Debian), Secure Boot generally “just works” on the happy path, including with some NVIDIA drivers via signed DKMS modules or vendor packages.
  • Off the golden path (Arch, custom kernels, VMware/VirtualBox, out‑of‑tree modules), users report manual key enrollment, MOK dialogs, and recurring signing chores.
  • Tools like sbctl, UKI, and distro hooks can fully automate signing, but UX remains confusing, especially around MOK vs UEFI KEK/db.

Firmware/UEFI design and vendor failures

  • Many see UEFI (and Secure Boot) as over‑complex and poorly implemented; firmware is often buggy, unmaintained, and inconsistent.
  • Some hardware loads GPU or option ROM blobs signed with Microsoft keys before letting you enter firmware setup; replacing keys can brick access to the setup screen itself.
  • Others defend UEFI as standardizing what vendors were already doing and enabling cleaner dual‑booting vs BIOS.

Certificate expiry semantics

  • Multiple commenters question the point of 10–15‑year expirations: they don’t meaningfully mitigate key theft and instead threaten long‑lived hardware.
  • Suggested alternatives:
    • Treat expiry as a warning, not a hard failure.
    • Validate signatures “as of firmware build time.”
    • Use timestamping/DBX for revocation while avoiding hard global time dependencies.
  • Others argue expiry helps bound CRL/DBX growth and crypto deprecation, but acknowledge the ecosystem didn’t plan for vendor neglect.

User keys, alternatives, and mitigations

  • Several argue that “real” Secure Boot means enrolling your own keys and optionally dropping Microsoft’s, which many report doing successfully (often via sbctl).
  • Caveats: certain laptops (notably some Lenovo models) reportedly break video/firmware UI if Microsoft/Lenovo keys are removed.
  • Common fallback strategies:
    • Disable Secure Boot entirely.
    • Keep Secure Boot but rely on distro shims and hope vendors ship firmware updates.
    • In desperation, play clock‑games (set RTC back before expiry) – acknowledged as hacky and fragile.

Broader systemic worries

  • Thread connects Secure Boot to larger trends: Intel ME/AMD PSP backdoors, trusted computing as a tool for DRM and surveillance, planned obsolescence, and the risk of losing the ability to run old systems on old hardware.
  • Underlying tension: security engineering vs. user sovereignty. Many see current Secure Boot governance (especially with Microsoft as de facto root) as biased toward the latter’s erosion.