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