secure-boot-cert-rotation

# secure-boot-cert-rotation Triage and fix the **Microsoft Secure Boot 2011→2023 certificate rotation** on a real, mixed fleet. Microsoft's original 2011 Secure Boot CAs expire in 2026; their 2023 replacements take over. This skill exists to stop the two failure modes operators actually hit: (1) **panic** — believing servers will stop booting on the expiry date (they won't), and (2) **applying the wrong tool** — reaching for `fwupd`/LVFS on hardware and VMs it cannot serve, instead of the firmware-native path. The work is almost never the cert write itself — it's **knowing which of three firmware surfaces a given machine has** (Dell host firmware, generic Linux host firmware, or a VM's virtual OVMF varstore), because each is updated by a different mechanism and `fwupd` only covers one of them. ## The one load-bearing fact — read this before anything else **UEFI firmware does not check a certificate's expiry date when validating Secure Boot signatures.** EDK2 sets `NO_CHECK_TIME` on PKCS#7 verification on purpose (there is no trustworthy clock at boot; enforcing `notAfter` would be a self-inflicted brick vector). Canonical, Red Hat, fwupd, and LWN all state this independently. Consequences, and the entire reason this is a *hygiene* task and not a *fire*: - **Every machine that boots today keeps booting after the expiry dates.** Nothing breaks on the deadline. - The **real** risks are forward-looking: 1. **Forward-compat** — once a distro ships a shim/bootloader signed ...