Dear maintainer,

Due to expiring Secure Boot certificates in June 2026 [0] versions of
ovmf before 2025.11 will soon refuse to boot if Secure Boot is
enabled. So this affects virtual machines on Trixie (and older) hosts.

You can list the available Secure Boot keys by running the following
command (from the `mokutil` package) inside the virtual machine:

     mokutil --kek --short

This is the output I get from a Secure Boot enabled virtual machine
booted with ovmf 2025.02-8+deb13u1, showing that the new key from 2023
is missing:

     cdcf075ae4 Debian UEFI Secure Boot (PK/KEK key)
     31590bfd89 Microsoft Corporation KEK CA 2011

Here is the output with ovmf 2025.11-5, showing that the new key is
present:

     cdcf075ae4 Debian UEFI Secure Boot (PK/KEK key)
     31590bfd89 Microsoft Corporation KEK CA 2011
     459ab6fb5e Microsoft Corporation KEK 2K CA 2023

To fix this situation the updated keys [1] need to be backported to
Trixie's ovmf. Furthermore, users need to switch to the
OVMF_CODE_4M.secboot.fd boot loader; the commonly used OVMF.fd and
OVMF_CODE_4M.fd boot loaders contain the old key so they currently
support Secure Boot, but they will not after the 2011 keys expire in
June. Lastly, after switching boot loader you need to reset NVRAM.
For libvirt the VIR_DOMAIN_START_RESET_NVRAM flag [2, 3] does just
that, and is set when you start your domain with `virsh` like this:

     virsh start $DOMAIN --reset-nvram

Cheers!

[0]
https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e
[1] https://github.com/tianocore/edk2/pull/11661
[2] https://libvirt.org/kbase/secureboot.html#changing-an-existing-vm
[3]
https://libvirt.org/html/libvirt-libvirt-domain.html#VIR_DOMAIN_START_RESET_NVRAM

Hi Anonym,

Anonym wrote:

I followed your link for reference [0] and it looks like systems should still
be able to boot, at least. From the link:

but it sounds like something I would definitely want to fix anyway. Without the
2023 cert, my Windows 11 guest also shows a warning and refers me to the link
you shared as reference [0].

I found it's also possible to install the 2023 key using the
python3-virt-firmware package.  On a Debian 13 host with a Windows 11 guest, I
shut down the guest, used the command:

    virt-fw-vars --inplace myVARS.fd --enroll-redhat --microsoft-kek all

and booted the guest back up. It took a while but the warning in Windows
eventually cleared.

The location of myVARS.fd is probably in /var/lib/libvirt/qemu/nvram/ and can be
found in the <nvram> tag of the guest's domain.xml under the <os> tag.  I also
made a copy of myVARS.fd beforehand just in case.

I also tested this on a Debian 13 guest and used mokutil --kek --short as you
did, and found that the key was not present before I ran the command, and that
it was present afterwards.  I didn't need to run
virsh start $DOMAIN --reset-nvram , although I was already using
OVMF_CODE_4M.ms.fd which is a symlink to OVMF_CODE_4M.secboot.fd.

I hope this helps!

Jared Epp

Following up with test results and a patch for trixie.

On the question earlier in this bug: VMs with only the 2011 keys keep
booting the binaries they already have. What fails is the first binary
signed only with the 2023 CA. As the Debian wiki explains
(https://wiki.debian.org/SecureBoot/CAChanges), the next shim update can
only be signed with the current Microsoft UEFI CA.

Status as of 2026-10-12: trixie's ovmf 2025.02-8+deb13u1 (and bookworm's
2022.11-6+deb12u2) still ship OVMF_VARS_4M.ms.fd with only the 2011
Microsoft keys:

    PK   Debian UEFI Secure Boot (PK/KEK key)
    KEK  Debian UEFI Secure Boot (PK/KEK key), Microsoft Corporation KEK CA 2011
    db   Microsoft Windows Production PCA 2011, Microsoft Corporation UEFI CA 2011

forky/sid (2026.08+ds-2), Ubuntu 22.04 to 26.04, Fedora 43, AlmaLinux 9/10
and openSUSE Leap 16.0 all include the 2023 KEK and db certificates.

Test (QEMU/KVM, trixie OVMF_CODE_4M.secboot.fd, unmodified trixie
genericcloud image). We made a genuine 2023-only shim by removing the 2011
signature from trixie's dual-signed shimx64.efi.signed (shim-signed
1.51~1+deb13u1). The Authenticode hash does not cover the certificate
table, so Microsoft's 2023 signature stays valid. A 2011-only cut is the
control:

    varstore                         shim signed by    result
    trixie .ms template              2011 only         boots, SecureBoot=1 (control)
    trixie .ms template              2023 only         BdsDxe: failed to load Boot0001 ...: Access Denied
    template + 2023 certs (below)    2023 only         boots, SecureBoot=1

In an existing Debian guest, shim-signed's preinst should refuse a shim
whose signers are not in db and keep the old one (we read this from the
script and did not run it). Fresh installs from 2023-only media fail as
above. `virsh start --reset-nvram` does not help on trixie, because it
copies the same 2011-only template.

Patch for trixie: Ubuntu's
OvmfPkg-Expand-EnrollDefaultKeys-with-Microsoft-2023-keys.patch
(LP: #2146560; the same file is in noble 2024.02-2ubuntu0.9 and questing
2025.02-8ubuntu3.2, which shares trixie's upstream base) applies cleanly
on top of the 2025.02-8+deb13u1 series without changes:

https://git.launchpad.net/ubuntu/+source/edk2/plain/debian/patches/OvmfPkg-Expand-EnrollDefaultKeys-with-Microsoft-2023-keys.patch?h=import/2025.02-8ubuntu3.2
    sha256 a0edc3c91100c278ffd9c68fcba0777474c83df26446688bfe2e3dd27355b4fb

The rest of the debdiff is one line appended to debian/patches/series:

    OvmfPkg-Expand-EnrollDefaultKeys-with-Microsoft-2023-keys.patch

and a changelog entry:

    edk2 (2025.02-8+deb13u2) trixie; urgency=medium

      * Add the Microsoft 2023 KEK and db certificates to EnrollDefaultKeys,
        so the pre-enrolled .ms varstores include them (Closes: #1134793).
        Patch taken from Ubuntu (LP: #2146560).

With it, `debian/rules build-ovmf` in a debian:13 container (about 7
minutes) produces an OVMF_VARS_4M.ms.fd with:

    PK   Debian UEFI Secure Boot (PK/KEK key)
    KEK  Debian UEFI Secure Boot (PK/KEK key), Microsoft Corporation KEK CA 2011,
         Microsoft Corporation KEK 2K CA 2023
    db   Microsoft Windows Production PCA 2011, Microsoft Corporation UEFI CA 2011,
         Microsoft UEFI CA 2023, Microsoft Option ROM UEFI CA 2023,
         Windows UEFI CA 2023

With the rebuilt OVMF_CODE_4M.secboot.fd and this template, the same image
boots both the 2023-only and the 2011-only shim with SecureBoot=1. We only
built the x86 OVMF target.

Existing VMs: the workaround earlier in this bug
(`virt-fw-vars --enroll-redhat --microsoft-kek all`) works, but it also
replaces the VM's PK and Debian KEK with Red Hat's "Red Hat Secure Boot
(PK/KEK key 1)". To keep the Debian PK and add only the 2023 certificates
with trixie's own python3-virt-firmware 24.11 (shut the VM down and back
up its NVRAM file first):

    C=/usr/lib/python3/dist-packages/virt/firmware/certs
    MS=77fa9abd-0359-4d32-bd60-28f4e78f784b
    virt-fw-vars --inplace /var/lib/libvirt/qemu/nvram/VM_VARS.fd \
      --add-kek $MS $C/MicrosoftCorporationKEK2KCA2023.pem \
      --add-db  $MS $C/WindowsUEFICA2023.pem \
      --add-db  $MS $C/MicrosoftUEFICA2023.pem

Tested: the guest then sees KEK = Debian PK/KEK key + KEK CA 2011 + KEK 2K
CA 2023, db = both 2011 CAs + Windows UEFI CA 2023 + Microsoft UEFI CA
2023, and boots a 2023-only shim with SecureBoot=1. 24.11 does not bundle
the Microsoft Option ROM UEFI CA 2023, which only matters for passthrough
devices with 2023-signed option ROMs.

Not tested: Windows guests, AAVMF/arm64, bookworm builds.

This report was prepared by CyberNative AI LLC using AI agents; the builds
and boots above were run as described.