Secure Boot – Microsoft UEFI CA 2023 Certificate Not Included in EFI Disk

[janus57]

Hi,

It's pretty strange, because the old 2011 CA is still enrolled too. Not sure why Windows would see the presence of the newer cert as problematic, I have no access to internals there. Maybe it's an overly cautious change detection or something.

From my understanding a modification of UEFI certificate can (and will ?) trigger bitlocker because it's a security modification.

As far as i can see, some OEM (like HP -> https://support.hp.com/us-en/document/ish_13070353-13070429-16) has rollout documentation for this change and say that if you update the certificate manually : Before calling the BIOS action, BitLocker (or any third-party disk encryption software) must be suspended to avoid triggering BitLocker recovery.

Best regards,

 

[t.lamprecht]

Knowing the enrollment won't happen automatically, can someone explain what exactly I need to to update these keys, so Windows guests become ready ?

Freshly created guests will be already ready from the get-go, as the default OVMF EFI Vars template was updated to ship these keys last week with pve-edk2-firmware version 4.2025.05-1.

For existing VMs the procedure is:

1. If the VM uses Bitlocker execute the following command in a powershell to disarm it for the next boot:
   manage-bde -protectors -disable <drive>
   Where <drive> is replaced with e.g. C:
2. Shutdown the VM.
3. Open a root shell on the node with the respective VM (e.g., the one available from the PVE web UI or SSH) and run:
   qm enroll-efi-keys <VMID>
   Replace <VMID> with the respective VMID.
4. Start the VM again.

We have some proof of concept work here to make this easier in the future, exposing this through the user interface and avoiding the need to touch the root shell, but as we are in process of cutting a release we chose to go for the least invasive route for now.

 

[lucius_the]

Thank you for providing exact steps.
I tried this on a couple of VM-s and it worked fine (some already had the updated keys, some didn't, and this command worked for them).

This is an example of a Windows 11 VM:

efidisk0: enrolling Microsoft UEFI CA 2023
INFO: reading raw edk2 varstore from /var/run/qemu-server/qsd-vm-132-efi-enroll-efidisk0-enroll.fuse
INFO: var store range: 0x64 -> 0x40000
INFO: add db cert /usr/lib/python3/dist-packages/virt/firmware/certs/MicrosoftCorporationUEFICA2011.pem
INFO: certificate already present, skipping
INFO: add db cert /usr/lib/python3/dist-packages/virt/firmware/certs/MicrosoftUEFICA2023.pem
INFO: writing raw edk2 varstore to /var/run/qemu-server/qsd-vm-132-efi-enroll-efidisk0-enroll.fuse
successfully updated efidisk

However, inside the guests I'm still getting the Event:

Secure Boot CA/keys need to be updated. This device signature information is included here.
DeviceAttributes: BaseBoardManufacturer:;FirmwareManufacturer:Proxmox distribution of EDK II;FirmwareVersion:4.2025.05-2;OEMModelNumber:Standard PC (Q35 + ICH9, 2009);OEMModelBaseBoard:;OEMModelSystemFamily:;OEMManufacturerName:QEMU;OEMModelSKU:;OSArchitecture:amd64;
BucketId: e4d984ebd26ba50cc7642eeceba9258336bd302c7c0a4db90e1796d59b242c28
BucketConfidenceLevel:
UpdateType: 0
HResult: The operation completed successfully.

I guess there's something to be done in the OS as well. There's a task inside Windows that needs to be completed, but I tried running that task (Task Scheduler -> Microsoft -> Windows -> PI, then there is a task named "Secure-Boot-Update". But running it fails, with a status code 3221225477, meaning STATUS_ACCESS_VIOLATION, meaning the task crashed.

When looking at the result of [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI -Name db).Bytes) -match 'Windows UEFI CA 2023'
in an elevated powershell, I get TRUE. Meaning the OS sees the new certificates in the firmware.

That's on Windows 11. Not working in my case.

On a Windows Server 2002 VM, that same powershell command is returning FALSE, meaning the OS doesn't even see the new certificates in firmware.
Now for that particular VM, the EFI vars were updated automatically, yesterday, when I installed the previews PVE updates, that contained the automatic deployment of new certs. For a Windows 11 VM I did the update manually with "qm enroll-efi-keys".

Question: was the update in PVE 9.0.17 / qemu-server 9.0.29 different from this freshly released one ?

EDIT/UPDATE:
- Windows 2022 VM actually sees the new certificate after a reboot. So it's just this Windows task where I'm stuck.
- I forgot to mention, this needs to be done inside the OS before trying to run the task: reg add "HKLM\SYSTEM\CurrentControlSet\Control\Secureboot" /v AvailableUpdates /t REG_DWORD /d 0x5944 /f

ANOTHER EDIT/UPDATE:
- after the update the Windows Server 2002 VM got this in the event viewer: Event ID 1044: Secure Boot DB update to install Microsoft Option ROM UEFI CA 2023 certificate applied successfully

So I guess it works, for WIndows Server at least. But not for my Windows 11 VMs for some reason.

 

[lucius_the]

Update to my last post, got it working for Windows 11 (I think).
Seems like it's a two step process. Before running the Secore-Boot-Update task I needed to switch the AvailableUpdates to "0x100" and then the task run.

Here if it helps anyone (powershell as admin):
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x100 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

Finally worked - the task run - and Event viewer showed the certs were recognized.

But the "bootmgfw.efi" is still signed with the old certificate, though. I guess I'll have to wait for some windows update to update the boot manager, or read more on this as the deadline gets closer. This is some PITA.

UPDATE: ok - another reboot and now the "bootmgfw.efi" is finally singed with the new Microsoft UEFI 2023 certificate. The VM just needed another reboot. Hope this helps others.

 

[lucius_the]

Well, I'll just post another update since I already spent many hours on this. Might help maybe.
The procedure (to get windows fullly up to date and have Event ID 1801 cleared) there are actually many steps, both on the UEFI side and inside Windows.

The first part (UEFI) is solved by Proxmox. We just need to qm enroll-efi-keys <vmid>.
The second part (inside Windows) consists of many more actions. These are all the steps Windows should execute in order to consider it all completed:

1. 0x0040 – add Windows UEFI CA 2023 to DB
2. 0x0800 – add Microsoft Option ROM UEFI CA 2023 to DB
3. 0x1000 – add Microsoft UEFI CA 2023 to DB
4. 0x0004 – update KEK to Microsoft Corporation KEK 2K CA 2023
5. 0x0100 – install Windows UEFI CA 2023–signed bootmgr
6. 0x4000 – “only apply new 2023 CAs if 2011 CAs are present”

The hex value shown at the start of each is the value that the Secure-Boot-Update task in Windows expects to see in AvailableUpdates under reg key HKLM\SYSTEM\CurrentControlSet\Control\Secureboot.
In case when you want to go step by step, you need to update this reg key with the value noted above and run Secure-Boot-Update task, one by one, in that order.
If you don't want to go step by step you can put value 0x5944 in AvailableUpdates and then Windows will do all those steps on its own (or after several restarts).

What works for me are steps: 1, 2 and 5. And that gets my Windows VMs booted with a newly signed boot manager. That's good.
But the Event ID 1801 persists in the VM. And that is because Windows is not regarding that as complete. Because some of these steps above fail to execute. I would guess that the new EFI package might still be missing some of the above certificates. There's lots of them.

Perhaps someone from Proxmox might chime in and see if anything can be done to get us all to, what Microsoft envisions as, "fully updated" state.

(edited for typos)