From: Fiona Ebner <f.ebner@proxmox.com>
To: Daniel Kral <d.kral@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH-SERIES qemu-server/manager/docs v3 0/3] improve Microsoft+Windows UEFI CA 2023 enrollment
Date: Mon, 23 Feb 2026 12:05:12 +0100 [thread overview]
Message-ID: <3ef71bc4-93cb-4eab-982d-7663083a9726@proxmox.com> (raw)
In-Reply-To: <DGMAENE5QLUV.1KC78AS2VTTP9@proxmox.com>
Am 23.02.26 um 11:59 AM schrieb Daniel Kral:
> On Wed Jan 21, 2026 at 4:44 PM CET, Fiona Ebner wrote:
>> Make it possible to enroll via the API and UI by setting the
>> ms-cert=2023w marker on the EFI disk.
>>
>> The previous Microsoft UEFI CA 2011 will expire in June 2026, and the
>> previous Windows UEFI CA 2011 will expire in October 2026, so there
>> should be a way to update that can be automated and done while guests
>> are running.
>>
>> pve-manager needs a dependency bump for qemu-server for the API call
>> to have the desired effect (or the marker will just get set without
>> actually enrolling).
>
> Tested this series with some Windows 11, Debian and Proxmox VE VMs that
> I had lying around which still did not have the new UEFI CA certs
> enrolled yet.
>
> Tested with each the Windows 11 and Linux VMs that
>
> - `qm enroll-efi-keys $vmid` fails for running VMs
> - `qm enroll-efi-keys $vmid` fails for VMs without EFI disks
> - `qm enroll-efi-keys $vmid` does nothing for VMs without pre-enrolled
> keys set
> - `qm enroll-efi-keys $vmid` does update to '2023w' if ms-cert=2023
> - `qm enroll-efi-keys $vmid` works for stopped VMs
> - Enrolling EFI keys through the CLI/API/UI works for them and are
> enrolled correctly when doing a full shutdown-start cycle
> - Enrolling EFI keys is disabled in UI if VM does not have pre-enrolled
> keys set or ms-cert=2023w, but enabled for ms-cert=2011 or
> ms-cert=2023
>
> I checked whether those were correctly enrolled inside the VM with
>
> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)
> -match 'Microsoft UEFI CA 2023'
> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)
> -match 'Windows UEFI CA 2023'
>
> for Windows VMs, and
>
> mokutil --all --list-enrolled | grep '\(Microsoft\|Windows\) UEFI CA 2023'
>
> for Linux VMs.
>
> The Windows VMs did _not_ have BitLocker configured though.
>
>
> Two small nits unrelated to the direct changes of this series:
>
> - a `qm set 101 --efidisk0 '...,pre-enrolled-keys=1,ms-cert=2023'` will
> also enroll the Windows UEFI CA 2023 certificate, should we set
> `ms-cert=2023w` afterwards then as that's the correct state? But as
> it's only a marker state that might be unnecessary.
Yes, good catch!
> - there are few spots only naming the Microsoft UEFI CA 2023 but not the
> Windows UEFI CA 2023 certificate, e.g. the output and description of
> `qm enroll-efi-keys`.
Ack.
> Otherwise, the changes look good to me, so consider this series as:
>
> Tested-by: Daniel Kral <d.kral@proxmox.com>
> Reviewed-by: Daniel Kral <d.kral@proxmox.com>
Thank you for testing! Unfortunately, it seems we need yet another
change to also enroll the 2023 KEK:
https://forum.proxmox.com/threads/secure-boot-%E2%80%93-microsoft-uefi-ca-2023-certificate-not-included-in-efi-disk.173417/page-3#post-839474
prev parent reply other threads:[~2026-02-23 11:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-21 15:44 Fiona Ebner
2026-01-21 15:44 ` [pve-devel] [PATCH qemu-server v3 1/3] vm start: check efi: always check for certificates when pre-enrolled-keys=1 Fiona Ebner
2026-01-21 15:44 ` [pve-devel] [PATCH manager v3 2/3] ui: qemu: hardware: efi: allow enrolling Microsoft+Windows UEFI CA 2023 Fiona Ebner
2026-01-21 15:44 ` [pve-devel] [PATCH docs v3 3/3] qm: bios/uefi: add secure boot certificate expiration section Fiona Ebner
2026-02-05 12:12 ` [pve-devel] [PATCH-SERIES qemu-server/manager/docs v3 0/3] improve Microsoft+Windows UEFI CA 2023 enrollment Fiona Ebner
2026-02-16 10:04 ` Fiona Ebner
2026-02-23 10:59 ` Daniel Kral
2026-02-23 11:05 ` Fiona Ebner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3ef71bc4-93cb-4eab-982d-7663083a9726@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=d.kral@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox