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

[powersupport]

Hi ,


We are currently preparing our Windows Server VMs for Microsoft's Secure Boot certificate updates. According to Microsoft’s announcement (ref: https://support.microsoft.com/en-us...-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e), the existing Microsoft UEFI CA 2011 certificate will expire in 2026, and a new certificate (Windows UEFI CA 2023) must be enrolled to ensure Secure Boot continues working beyond that point.


We are using Proxmox VE and creating Windows VMs with Secure Boot enabled and EFI disks with pre-enrolled keys (per the documentation at https://pve.proxmox.com/pve-docs/chapter-qm.html#qm_bios_and_uefi), using:


qm set <vmid> --efidisk0 local-lvm:vm-<vmid>-disk-1,efitype=4m,pre-enroll-keys=1


After testing a Windows Server 2022 VM, we found that the Windows UEFI CA 2023 certificate is not present in the Secure Boot db.


We confirmed this using PowerShell:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
→ returns False


We would like to ask:

1. Will the Proxmox EFI disk be updated to include the Microsoft Windows UEFI CA 2023 certificate in future releases?
2. If yes, is there an ETA or specific Proxmox VE version where this will be added?
3. If no, what is the recommended manual method to enroll this certificate in the EFI environment of a Windows VM created via Proxmox?
   
   • Is there an officially supported method to inject this certificate into the db or dbx in the EFI environment?
   • Are there tools or EFI shell utilities that Proxmox recommends using for this purpose (e.g. KeyTool.efi or similar)?

We want to ensure that all future VMs — especially Windows-based Secure Boot VMs — can boot securely after the certificate expiration in 2026, and ideally automate this process during VM provisioning if possible.


Thanks

 

[janus57]

Hi,

Your post pick my interest, so I came across this blog post : https://techcommunity.microsoft.com...g/updating-microsoft-secure-boot-keys/4055324 which include a fairly simple solution, the only thing is you need to enable the "required diagnostic data" at least.

Another source : https://support.microsoft.com/en-au...abase-db-a68a3eae-292b-4224-9490-299e303b450b

Fun Fact BTW : on my personal computer the command return "false" also.

BUT, if I see this guide, it's not sufficient : https://support.microsoft.com/en-au...23-24932-88b8f034-20b7-4a45-80cb-c6049b0f9967

So here is the solution :

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x140 /f

Then you need to reboot, then wait 10-15 minutes and reboot again.

Tested on 2 freshly installed Windows Server STD 2022 & 2025 (iso from Microsoft updated in September 2025 - Win_Server_STD_CORE_2025_24H2.11_64Bit & Win_Server_STD_CORE_2022_2108.49_64Bit), now the command return "True".

Now i can see the value of "WindowsUEFICA2023Capable" (in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing) at 2.

Best regards,

 

[powersupport]

Hi,

Thank you for sharing the information and detailed steps — that’s really helpful!


However, my main concern is on the Proxmox side, specifically regarding whether the new Microsoft Secure Boot certificate (referenced in Microsoft’s update notice) will be included in the Proxmox EFI Disk when using the pre-enroll-keys option.


From my testing, even with the latest Proxmox version, the EFI Disk doesn’t seem to contain the updated certificate yet.


So I’d like to confirm with the Proxmox team — will the new Microsoft Secure Boot certificate be added to the EFI Disk in a future release, or will it require manual enrollment by users?


Thank you again for your input!

 

[uzumo]

Making such changes would prevent older operating systems from even booting up, so if Proxmox were to change that, most people would be in trouble.

Systems with an outdated boot manager will not boot at all.
*Nearly all Windows ISOs are boot managers that use outdated certificates. In such an environment, you must create an updated ISO and use it.

In such situations, it is impossible to install the OS using nearly all ISO files distributed by Microsoft.

This should be handled on each Windows Guest.

https://support.microsoft.com/en-au...23-24932-88b8f034-20b7-4a45-80cb-c6049b0f9967

After Mitigation 1 and Mitigation 2 are applied to your devices, you can update any bootable media that you use in your environment. Updating the bootable media means applying the PCA2023 signed boot manager to the media. ...Otherwise, devices with the mitigations applied will not start from boot media that uses the older Windows boot manager and 2011 CA.

*I cannot imagine a scenario where only Mitigation 1 is necessary.
Mitigation measures 2 through 4 are mandatory, and measures 2 and 4 are not operations performed within Proxmox. Furthermore, Mitigation Measure 3 (the rejection of the 2011 CA (Registration with DBX)) has the aforementioned effects.

 

[gfngfn256]

Fun Fact BTW : on my personal computer the command return "false" also.

Did you do anything about it on your PC itself?


I did the same test on my PC & it also returned 'false'. I then checked the following:

PS C:\WINDOWS\system32> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft Windows Production PCA 2011'
True

which seems to confirm, that my secure-booted certificate will expire in Oct 2026 as per this document.

Should I be concerned?

 

[janus57]

Hi,

Did you do anything about it on your PC itself?

Just upgraded the bios to see, but no same result.

Should I be concerned?

Yes and no : your PC can still boot but you will have bigger trouble :

Every Windows system with Secure Boot enabled includes the same three certificates in support of third-party hardware and Windows ecosystem. Unless prepared, physical devices and VMs will:

• Lose the ability to install Secure Boot security updates after June 2026.
• Not trust third-party software signed with new certificates after June 2026.
• Not receive security fixes for Windows Boot Manager by October 2026.

Sources : https://techcommunity.microsoft.com...boot-certificates-expire-in-june-2026/4426856 & https://borncity.com/win/2025/06/30/microsofts-uefi-secure-boot-certificate-expires-in-june-2026/

My understanding of the situation is that for physical machine, the certificate should be pushed by a BIOS update provided by the manufacturer.
If the manufacturer does nothing then it's possible to force the update within Windows directly (which I tested on proxmox VM and work).

And the new Windows ISO will not boot anymore with the old CA (it's already the case with the W11 25h2 i think - not tested).

For reference : https://bugzilla.proxmox.com/show_bug.cgi?id=6985

Best regards,

 

[gfngfn256]

Just upgraded the bios to see, but no same result.

My understanding of the situation is that for physical machine, the certificate should be pushed by a BIOS update provided by the manufacturer.

Based on the various MS support / kb-announcements sites I quickly browsed - one would have thought that regular PCs that have "normal" Windows Updates (& are not managed by some enterprise/IT infrastructure should automatically be updated by the regular Windows Updates. It would however appear that this is not the case.

it's already the case with the W11 25h2 i think

This should/must be physically tested. (You may need to adjust your bug-report accordingly).

Even if this works, a problem may still exist (as the OP has pointed out) concerning existing Windows VM's, although I'm not sure physical PCs are any different (as above) - so possibly not a PVE issue.

 

[janus57]

Hi,

one would have thought that regular PCs that have "normal" Windows Updates (& are not managed by some enterprise/IT infrastructure should automatically be updated by the regular Windows Updates. It would however appear that this is not the case.

From my understanding it's a failsafe from Microsoft, but Microsoft still push to get an update from the OEM inside their KB/announcement as far as I understand.

Important: Check with your OEMs on the latest available OEM firmware. Apply any available firmware updates to your Windows systems before applying the new certificates. In the Secure Boot flow, firmware updates from OEMs are the foundation for Windows Secure Boot updates to apply correctly.

Even if this works, a problem may still exist (as the OP has pointed out) concerning existing Windows VM's, although I'm not sure physical PCs are any different (as above) - so possibly not a PVE issue.

For me it's not an issue with existing VM, it will update with Windows update as pointed and will be working "normally".

The issue will be with "new" VMs (after the expiration) and after the resign of Windows ISO.

Other references : https://github.com/tianocore/edk2/issues/11281

Note : In the post from June 26, 2025 we can see

Microsoft and partner OEMs will be rolling out certificates to add trust for the new DB and KEK certificates in the coming months.

So basically Microsoft starts working with OEM 1 year before the expiration (which I think is a bit short).

Best regards,

 

[gfngfn256]

So, are our PCs already updated by the MS ('failsafe') update? Is the above test we both did (searching for the string 'Windows UEFI CA 2023') indicative?

How many MBs out there, that won't be getting BIOS updates, probably more than will!
This sounds like another Y2K waiting to explode.....

BTW Support.microsoft.com is currently down! Maybe their CAs have already expired!

 

[janus57]

Hi,

So, are our PCs already updated by the MS ('failsafe') update?

Not without the manual operation of editing the registry to force it (for the moment Microsoft wait for OEM I presume).

Is the above test we both did (searching for the string 'Windows UEFI CA 2023') indicative?

Yes, if it's return false you have not the new UEFI CA currently installed on the computer.

How many MBs out there, that won't be getting BIOS updates, probably more than will!
This sounds like another Y2K waiting to explode.....

The computer still working if secure boot is disabled so yeah it's bothering for personal usage.
For professional usage, if the big company (HP/DELL/Lenovo etc..) don't provide BIOS update, lots of people will be mad.

BTW Support.microsoft.com is currently down! Maybe their CAs have already expired!

Almost, they fucked up the DNS entry (and TLS certificate before that).

Best regards,

 

[alexhaydock]

I think to cover some of what's been discussed in the thread as I understand it:

Proxmox's EFI Vars `pre-enroll-keys` option uses EnrollDefaultKeys.efi from the upstream edk2 package: https://github.com/tianocore/edk2/tree/master/OvmfPkg/EnrollDefaultKeys. Currently this package only has the 2011 keys enrolled.

The Win11 25H2 ISO isn't signed with the 2023 keys, so will still boot fine using an EFI Vars store which contains only the 2011 keys.

After install, a Win11 25H2 VM will get updated to use a bootloader that is signed with the 2023 key so will not boot on an EFI Vars store with only the 2011 keys enrolled. I haven't bisected exactly where this gets introduced, but I imagine it's done as part of KB5036210, or in a similar update.

This isn't normally an issue for manual installations since the ISO will boot using the 2011 key, and KB5036210 will enrol the new 2023 keys in the EFI Vars store, meaning the OS will continue to boot just fine.

The problem comes if you're building images for deployment, where you produce a fully updated Win 11 25H2 image (or presumably Server 2025), and the EFI Vars store isn't preserved at the point of deployment. At this point you deploy to a new VM, with just the 2011 key enrolled, but your bootloader is signed with the 2023 key. So the VM doesn't boot.

I've landed a commit in the edk2 upstream today which adds the 2023 keys to the EnrollDefaultKeys flow, meaning future versions of the edk2 package will have these keys and everything will work as expected for fully updated Win 11/2025 VMs.

The flow from here might be a bit complex though.

As I see it:

1. The `edk2` package release a new version. Probably late November given their historic release cadence.
2. Debian picks up this `edk2` package release. This is unlikely to happen in Trixie from what I can tell given historic evidence, but it's possible it might make it into `trixie-backports`.
3. Proxmox benefits from this updated `edk2` package from Trixie.

Since Debian might be unlikely to push this change to Trixie stable, Proxmox might have to either take the backported patch from `trixie-backports` (if it lands there), or backport themselves directly from upstream. I think this is a significant enough issue that it warrants Proxmox stepping in to handle the backporting if needed though.

There's some alternative flows though:

• Proxmox could adopt the more flexible and newer approach used by Fedora for their `edk2-ovmf` package, which uses `virt-firmware` to build qcow2 4M images with the Microsoft keys enrolled: https://gitlab.com/kraxel/virt-firmware
• Proxmox could fully embrace the QEMU 10 modern approach, where instead of providing EFI Vars using an image that's attached as an emulated pflash disk (and requires SMM mode), QEMU can pass the vars direct to a VM as a dedicated `uefi-vars-x64` device that uses a JSON file on the host as a backing store (https://www.qemu.org/docs/master/devel/uefi-vars.html). Personally I'd love this approach most as it'd provide a much easier pathway to produce images using custom Secure Boot chains. This would allow for some neat features if it was exposed to the API, such as using declarative tooling to deploy custom signed images alongside the verification chain to sign it. That'd be quite a significant engineering effort I think, so maybe a PVE 10 thing.

Hopefully we can find a way forward on this one though now that there's something landed upstream, since this is also blocking my Windows 11/2025 build and deploy pipelines.