Hi Anonym,
Anonym wrote:
> 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.
I followed your link for reference [0] and it looks like systems should still
be able to boot, at least. From the link:
> Devices that haven’t received the newer 2023 certificates will continue to
> start and operate normally, and standard Windows updates will continue to
> install. However, these devices will no longer be able to receive new security
> protections for the early boot process, including...
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
