Skip to content

Get ready for upcoming UEFI CA expiration & transition

tl;dr

tl;dr: The current Microsoft UEFI CA key is expiring soon; a new one already exists. So probably the new shims will be signed by either the new key, or by both the old and new key. The latter is the expected outcome, but we don't know.

This migration will only impact computers which only run Tails.

When will this problem arrive? (i.e. when Tails ships with a shim that is only signed by the new key), we have no clue.

Can we do anything for those users? Yes, there multiple viable strategies, but none of them is great and cheap.

Facts

  • The expiration of certificates doesn't really matter: noone checks for them
  • There will be a migration to the new key: "Microsoft UEFI CA 2023"
    • This key expires in June 2038 (so in 15 years, just like the 2011 one) so we don't expect yet another transition any time soon (but there's no guarantee of course)
  • Both windows systems and modern linux systems (ie: fwupd) are able to add the new key to a system which only has the old key

How it impacts Tails

  • For most users, everything will be alright and no action is needed from our side
  • For users running Tails on hardware where they never run another operating system, problems can be expected: when the shim will be signed only with the new key, they won't have that key present on their computer (since Tails doesn't run fwupd or similar). Possible fixes:
    • Disable Secure Boot. Since they only use Tails, they don't need it. But it's hard to help users do that
    • Run a dedicated system that does the upgrade, ideally a Linux live booting from USB stick. Is there any such thing? In theory, it could exist. ie: a debian live system which can run fwupd
    • Install a common operating system (ie: Debian with GNOME) and make sure fwupd does its job
    • Include fwupd in Tails
      • Command-line instructions might be easy enough
      • Graphical frontend requires of GNOME Software. Doing this integration is not impossible (GNOME Software is decoupled from APT) but probably not trivial

TODO

  • Decide which "fix" we prefer in order to save users that only use Tails on their hardware.
  • Figure out when a shim that is only signed by the 2023 key will be released.
  • Deploy fix in good time before the above date.

Resources

Old version
  • A bunch of Microsoft keys that are critical for the Secure Boot chain will expire soon. Some on 2025-09-11 (unclear; perhaps they'll just not be used anymore), some in June 2026.
  • At some point after 2025-09-11, Microsoft will stop signing new shim with their 2011 key. They'll only sign it with their 2023 key. So:
    • For some time, Tails can keep using an older shim, signed by the 2011 key. During that period:
      • Systems that only have the new key will refuse to boot Tails with Secure Boot enabled. We don't know whether this situation exists and how common it is. In theory it's possible for new computers manufactured since 2023. In practice, that's unlikely for systems sold before 2026, but quite plausible for systems sold in 2026.
      • For systems that still have the old key, this should keep working until June 2026. At that point the 2011 key will expire, so systems that check expiration dates will refuse do boot Tails with Secure Boot enabled. While systems that don't check expiration dates will keep working. Until:
    • At some point, Tails will inherit a new UEFI Secure Boot shim from Debian (e.g. to fix security issues in shim). If we want to, we can decide to postpone this; we can't make it happen faster than what Debian sid will do. This new shim will be signed by "Microsoft UEFI CA 2023", rather than by the currently used "Microsoft Corporation UEFI CA 2011". And then:
      • Systems that have the new key will happily boot Tails with Secure Boot enabled.
      • Systems that lack the new key will refuse to boot Tails with Secure Boot enabled, iff. they check expiration dates (which is not always the case).
  • For all the aforementioned "refuses to boot Tails with Secure Boot enabled" problems: disabling Secure Boot will fix the problem. But will Windows start with Secure Boot disabled?
  • Most hardware/firmware vendors are on board with the update plan that Microsoft has been pushing since a few years.
    • Most computers that also run Windows should be OK as Windows Update takes care of the key update.
    • For Linux-only computers it depends on whether they're running fwupd + some GUI frontend or other reminder system. E.g. on a modern Debian + GNOME, by default one gets firmware updates integrated into GNOME Software, so if the user applies these recommended updates, they'll be fine. I see KDE supports this as well but I did not check if it's installed & enabled by default. Users who run other desktop environments, or don't install Recommends, or build their DIY OS by hand, are on their own. Let's call those ones "basic Linux".
    • For Tails-only computers, we don't ship fwupd so they won't get they key update (nor any firmware update, for that matter) unless the user manually updates their computer's firmware out of band, which is sometimes technically possible, sometimes not really, and in any case, probably extremely uncommon among our userbase.

To Do

  • @sajolida and @tails-team figure out how to respond to the problem:
    • Decide timing of shim update
      • For systems that have both the old and new key, this does not matter.
      • Do we want to optimize for systems that only have the old key (by postponing the shim update for as long as we can)? Or for new systems shipped after September 2025, with only the new key (by updating shim ASAP after 2025-09-11)? Either way, we probably should support systems that have the new key and verify expiration dates (by updating shim before June 2026)?
    • Can we proactively help users avoid the problem: advance warnings and encouragements to update the computer's firmware?
      • Can we cheaply check, while Tails is running, if the new key is installed?
      • Should we do this only once the new shim is out and we have decided when we switch to it, so we can give users a clear deadline and describe consequences if they miss it?
    • Should we provide instructions for Tails-only users and basic Linux users to update the firmware using fwupd on the command line?
    • Prepare ourselves for once the problem happens to users
      • Troubleshooting doc? Known issues?
Edited by anonym
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information