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

Hi,

fiona said:
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.
Click to expand...
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,
 
lucius_the said:
Knowing the enrollment won't happen automatically, can someone explain what exactly I need to to update these keys, so Windows guests become ready ?
Click to expand...
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.
 
  • Like
Reactions: fiona, jo_strasser, lucius_the and 1 other person
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:
Code: 
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:
Code: 
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.
 
Last edited:
  • Like
Reactions: uzumo
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.
 
Last edited:
  • Like
Reactions: Gavino and t.lamprecht
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)
 
Last edited:
  • Like
Reactions: uzumo, techsolo12, Gavino and 4 others
t.lamprecht said:
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.
Click to expand...

Thanks for the info. I have a mix of nodes on PVE 8 and PVE 9. Unfortunately the ones on 8 can't be upgraded just yet due to a third-party dependency that won't support PVE v9 until about "Q1 2026". Here are two of my nodes:

# PVE v9 node
Bash: 
root@gtnas01:~# pveversion
pve-manager/9.1.1/42db4a6cf33dac83 (running kernel: 6.17.2-1-pve)
root@gtnas01:~# dpkg -l pve-edk2-firmware-ovmf | grep pve | awk '{print $3}'
4.2025.05-2


# PVE v8 node
Bash: 
root@gtpve03:~# pveversion
pve-manager/8.4.14/b502d23c55afcba1 (running kernel: 6.8.12-16-pve)
root@gtpve03:~# dpkg -l pve-edk2-firmware-ovmf | grep pve | awk '{print $3}'
4.2025.02-4~bpo12+1

Is the PVE v8 version new enough to do the "qm enroll-efi-keys <vmid>"? If not, is there are new version coming for v8 users? Thanks.


-----------------
EDIT: answering my own question here - PVE v8 is no good - the "qm enroll-efi-keys <vmid>" is an unknown command and it's not in the help output (qm help qm help enroll-efi-keys) . But on the current PVE 9.1.4 I have access to "qm enroll-efi-keys <vmid>" as per the help:

Code: 
root@gtnas01:~# qm help enroll-efi-keys
USAGE: qm enroll-efi-keys <vmid>

  Enroll important updated certificates to the EFI disk with
  pre-enrolled-keys. Currently, this is only the Microsoft UEFI CA 2023.
  Must be called while the VM is shut down.

  <vmid>     <integer> (100 - 999999999)
             The (unique) ID of the VM.
 
Last edited:
  • Like
Reactions: argumentum
Hi all,

Thank you for the detailed explanations so far — this helped a lot.

Just to double-confirm my understanding:

• It is expected that older EFI vars (created before the recent updates)
may not contain "Microsoft UEFI CA 2023".

• Newly created Windows VMs on Proxmox VE 9 with updated
pve-edk2-firmware already include the 2023 CA by default.

• Existing Windows VMs should NOT have their EFI vars modified automatically,
as this can trigger BitLocker recovery.

• For existing VMs, the supported approach is to manually update the EFI vars
using:
qm enroll-efi-keys <VMID>
(with BitLocker suspended beforehand if enabled).

• Any remaining Secure Boot updates (boot manager / KEK updates)
are handled inside Windows via Windows Update or the Secure-Boot-Update task.

If the above summary is correct, I’ll relay this guidance to our customers.

Thanks again!
 
Hi,

Thanks for confirming.

Understood — so at the moment `qm enroll-efi-keys` only applies to Windows 10/11,
and Windows Server editions are intentionally excluded for now.

We’ll rely on Windows Update inside the guest for Server VMs and wait for
official support or guidance for manual enrollment on Windows Server.

Appreciate the clarification.
 
Hi,

powersupport said:
Understood — so at the moment `qm enroll-efi-keys` only applies to Windows 10/11,
and Windows Server editions are intentionally excluded for now.
Click to expand...
From my understanding it should apply to any Windows with pre-enroll activated, including Windows Server.

Best regards,
 
Adding a new EFI disk will result in all certificates being added.
*The `qm enroll-efi-keys` command is for virtual machines created before certificates were added. Virtual machines created after applying updates to Proxmox already have certificates.

Step 1 (0x40) is not required, but the other steps (0x100, 0x80, 0x200, 0x800) are still necessary.

If the Windows 11 task isn't fixed, it will show ID 1801, so we'll wait for Microsoft to fix it.

*Windows Server 2025 has tasks that function correctly.

*As @lucius_the mentioned, this would cause an access violation, so ID 1801 remains because it doesn't transition to Upgraded. In reality, the steps can be executed, so the update is complete and there is no issue.

I believe the qm enroll-efi-keys command not working properly is a matter of the virtual machine configuration.

If the OS Type in Option is not set to Microsoft Windows 11/2022/2025, an error will occur as per specification.

If you have changed it and added the certificate, the following will occur.

linux 6.x -2.6 Kernel
Code: 
qm enroll-efi-keys 804
skipping - OS type is neither Windows 10 nor Windows 11

Microsoft Windows 11/2022/2025
Code: 
qm enroll-efi-keys 804
skipping - no pre-enrolled keys or already got ms-cert=2023 marker

Changes to AvailableUpdates and task execution will result in a value of 0, indicating the changes have been applied.

Therefore, the updates are complete.

When UEFICA2023Status changes from NotStarted to InProgress and then to Upgraded, error 1801 will no longer appear.

In Windows 11, after an access violation, the status reverts from InProgress back to NotStarted. Consequently, it does not reach Upgraded, and error ID 1801 remains.

* Even if you manually change the UEFICA2023Status, it will revert back, so you have no choice but to wait for a fix.

Code: 
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot /v AvailableUpdates
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing /v UEFICA2023Status

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x40 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

# 0x40 is likely unnecessary since it is updated by qm enroll-efi-keys.

timeout /t 5

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot /v AvailableUpdates
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing /v UEFICA2023Status
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing /v UEFICA2023Error
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing /v UEFICA2023ErrorEvent

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"

timeout /t 5

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot /v AvailableUpdates
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing /v UEFICA2023Status
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing /v UEFICA2023Error
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing /v UEFICA2023ErrorEvent

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x80 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

timeout /t 5

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot /v AvailableUpdates
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing /v UEFICA2023Status
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing /v UEFICA2023Error
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing /v UEFICA2023ErrorEvent

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x200 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

timeout /t 5

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot /v AvailableUpdates
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing /v UEFICA2023Status
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing /v UEFICA2023Error
reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing /v UEFICA2023ErrorEvent

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x800 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
 
Last edited:
Hi,

Thanks for the clarification.

So to confirm:
• New VMs already include Microsoft UEFI CA 2023
• qm enroll-efi-keys is only for older VMs
• Windows Server is supported when OS Type and EFI config are correct
• No further action required unless dealing with legacy VMs

I’ll relay this to customers.
 
It is too abbreviated to be considered acceptable.

It cannot be written with any further abbreviation than this.

・Cannot run unless Secure Boot is enabled (requires an EFI disk with pre-enrolled-key=1).
　* Devices using BIOS instead of EFI are also excluded due to Secure Boot requirements.

・To use qm enroll-efi-keys, the OS type must be Microsoft Windows 11/2022/2025.

・Before performing additional operations on the Microsoft UEFI CA 2023, you must export the Secure Boot key.

manage-bde -protectors -get %systemdrive%

<https://support.microsoft.com/en-us...23-24932-41a975df-beb2-40c1-99a3-b3ff139f832d>

・Windows VMs created after installing Qemu-Server 9.0.30 or later include the Microsoft UEFI CA 2023.

<https://github.com/proxmox/qemu-server/commit/2f3d599f4c1a692b6b59e34f6a39287c83669b88>
<https://github.com/proxmox/qemu-server/commit/c6aa7a849801d66e6b1e34eb0fb6a075dbc219b6>

Certificates in the EFI Disk Database After Applying Qemu-Server 9.0.30

Code: 
PS C:\Users\admin> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)
Microsoft Root Certificate Authority 2010
Microsoft Windows Production PCA 2011
* Used to verify the signature of the old boot manager

Microsoft Root Certificate Authority 2010
Windows UEFI CA 2023
* Used to verify the signature of the new boot manager

Microsoft Corporation Third Party Marketplace Root
Microsoft Corporation UEFI CA 2011
Microsoft RSA Devices Root CA 2021
Microsoft UEFI CA 2023

・Windows VMs created before updating to Qemu-Server 9.0.30 require the addition of Microsoft UEFI CA 2023.
* To prevent potential boot failure issues, export the Secure Boot key beforehand as described in Microsoft's documentation.
* Since I don't have any environments that don't already include it, I cannot verify the certificates in the database for Qemu-Server versions prior to this one.
* I don't know if `qm enroll-efi-keys` is necessary. I believe `0x40` does the same thing.

・It is unclear whether updates occur automatically. Devices deemed by Microsoft to be capable of safely applying Secure Boot certificate updates will receive automatic updates. The criteria for this determination are unknown.
If updates do not occur automatically, updates 0x100, 0x80, 0x200, and 0x800 are required.

・If updates are not applied and the date exceeds June 2026, security updates for Secure Boot and Windows Boot Manager will no longer be applied.

・The commands required for updating do not function properly on some operating systems. Windows 11 has an issue with the task \Microsoft\Windows\PI\Secure-Boot-Update and does not achieve the Upgraded state.
　Windows Server 2025 does not have this issue.

・If you plan to update, you must also prepare installation media containing a new boot manager, considering the possibility that WinRE may not function.

・Since past backups are expected to be unusable, you will need to create a backup after the update.
 
Last edited:
You must log in or register to reply here.
Top Bottom