UEFI 2011 certificates expire in June 2026!

tcabernoch

tcabernoch

Well-Known Member
Proxmox Subscriber
Apr 27, 2024
502
190
53
Portland, OR
www.gnetsys.net
I've read quite a bit about the UEFI cert expiration, and I still don't know exactly what my way forward is.
Only one of my clusters is running PVE 9.x. Until earlier today, that was 9.1.6.
Now its running 9.2 and giving me some very helpful advice.

WARN: EFI disk without 'ms-cert=2023k' option, suggesting that not all UEFI 2023 certificates from Microsoft are enrolled yet.
The UEFI 2011 certificates expire in June 2026! The new certificates are required for secure boot update for Windows and common Linux distributions.
Use 'Disk Action > Enroll Updated Certificates' in the UI or, while the VM is
shut down, run 'qm enroll-efi-keys 1009' to enroll the new certificates.

The Disk Action mentioned there was not present before 9.2.

1779585052188.png

The long and confusing threads I've reviewed had a LOT of info, much of it contradictory or debated.
I read there's stuff you have to do inside of windows, possibly in conjunction with multiple reboots.
The MS article didn't help much.

I take it the first thing I need to do is update all of my clusters to 9.2.
I'm sorry if this sounds dumb with all of the info out there, but I don't see a clear set of directions.
After I "Use 'Disk Action > Enroll Updated Certificates' in the UI", what happens next?
Do I need to do stuff inside windows too? Is there a KB or help doc somewhere?

And then ... I know support on 8.4 expires in August.
I did not expect a dealbreaker like this, and I've put it off. (Gimme a break, my boss hates patching.)
Ok, I need to upgrade all my hosts. Now.
But, its unlikely I'll be able to do that in time.
I'm still going to be running 8.x hosts when "UEFI 2011 certificates expire in June 2026!"

What can I expect to happen to guests of these remaining unpatched 8.x systems?
Will they still boot? (I think that answer is yes. They just won't do "secure boot update", whatever that means.)

If I cannot manage to clear and patch these remaining 8.x hosts, is there an alternate path?
Some workaround?

Ya, I screwed myself here, but now I'm screwed, and I need some answers.
Thanks.
- t
 
Last edited:
Before we talk about this update, here’s some information that might be worth knowing
First, regarding the behavior of the boot loader during Secure Boot, the system can only boot using that boot loader if the certificate in `db` is signed.

The certificates in `db` and `dbx` are signed by `kek`, the certificate in `kek` is signed by `pk`, and `pk` can only be updated using the certificate in `kek`.

In the future, if new vulnerabilities related to the boot process are discovered, Microsoft will update the certificates in the `db` and `dbx` files on the UEFI, as well as the boot loader.

To perform this operation, you must update the boot loader signed by the certificates in `db`, `kek`, and `db`.

That is the process being carried out in this update.


A brief explanation of the consequences of not updating
If the certificate on `db` is from 2011, the certificate used to sign the bootloader must also be from 2011.

*If `db` contains both the 2011 and 2023 certificates, the system will be able to boot from a bootloader signed by either certificate.
*The system will refuse to boot the OS from a bootloader signed by a certificate not included in `db` or by a certificate included in `dbx`.

In a Microsoft OS update, if `kek` is enabled, `db` is updated to include a 2023 certificate, and the bootloader is replaced with one signed by the 2023 certificate on `db`.

Even if the bootloader cannot be updated eventually, the system will not become unbootable. It simply means that the system will no longer receive patches for the aforementioned new boot-related vulnerabilities.

This does not mean that the system will become unbootable.

* Unless you take forced measures such as adding the 2011 certificate to `dbx`, an OS equipped with the pre-existing bootloader signed with the 2011 certificate will not become unbootable.


About Updates
In Proxmox, running this command on a virtual machine with an EFI disk that does not have the 2023k flag will add the necessary certificates to `kek` and `db`.

*Even if they have already been added by other means, warnings will continue to appear on EFI disks that do not have the 2023k flag. This behavior was implemented because it was determined that checking for new certificates at every boot is wasteful.
*To perform this operation, you must run the command while the OS is shut down.

However, as mentioned above, this process alone does not ensure that the OS is using the new bootloader signed with the 2023 certificate for db.

Therefore, the update process must be performed separately on Windows.

*The bootloader is replaced during the OS reboot process on the virtual machine.

While the OS has a feature to attempt this process automatically, for it to run automatically, the device must be registered as trusted in Microsoft’s database. Devices that are not registered require additional steps on the OS.
 
Last edited:
  • Like
Reactions: tcabernoch
The information you can find with Microsoft primarily, since it’s their keys:

Your systems will still be able to boot. However, devices without the updated 2023 certificates will stop receiving new Boot Manager security patches and could face compatibility issues with newly signed OS bootloaders (like Linux "shim" updates or specific OS updates). Hence the expiration primarily affects the ability to trust new updated boot binaries, not the ability to boot with already trusted ones.

You can always manually update the UEFI with the new signed keys, just like you can choose not to use the Microsoft keys at all, although it’s probably easier to just upgrade to a current version.

Shut down the VM, and do the qm command
For Windows specifically, start the Windows VM and log in.
Run this command to tell Windows that the 2023 certificate block is available:
powershell
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "AvailableUpdates" -Value 0x5944
Run the hidden system task that compiles and injects the new keys into the VM's active UEFI environment:

Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
Reboot and run the scheduled task (may need to be 2 times) until you get the new certificate enrolled.

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
 
  • Like
Reactions: tcabernoch
Thank you both.

I've not seen the remediation process for UEFI Linux guests mentioned anywhere. Does anyone have experience with that?

The PowerShell command doesn't work on all systems. I tried it on one VM that did alert for expiring cert, and PS didn't recognize the command. Have other people run into this?

I have some upgrades going. I'll have a 9.2 bridgehead in each cluster soon.

I hope to test the Windows UEFI cert update later today.

----------------------------

Heh. This was my 500th forum post. I'm "Prolific"!
 
Last edited:
What command? Both of them are standard, registry edits and scheduled taks runs. You can find them elsewhere in case there is a typo.

You do need an updated/supported Windows 10/Server 2019 or higher.

The Linux systems don’t have a problem, just make sure it’s updated (Ubuntu 22+, RHEL8+), as they are signed with updated keys if you use Secure Boot at all.
 
Ah. I ran the PS thing on a VM that did NOT have UEFI. So ya. It choked.
It works fine everywhere else I tried it.

PS C:\Users\tcabernoch> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2
023'
Get-SecureBootUEFI : Cmdlet not supported on this platform: 0xC0000002
At line:1 char:42
+ ... System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) ...
+ ~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotImplemented: (Microsoft.Secur...BootUefiCommand:GetSecureBootUefiCommand) [Get-Secure
BootUEFI], PlatformNotSupportedException
+ FullyQualifiedErrorId : GetFWVarFailed,Microsoft.SecureBoot.Commands.GetSecureBootUefiCommand


We only have a few Linux VMs w UEFI. Mostly virtual appliances.

I spent the whole day getting hosts evacuated and upgraded. Ran into other issues and it all just took time.
Didn't get to try the UEFI cert fix.
i might put in an extra day tomorrow and give it a shot.

Thx for the feedback folks.

- t
 
As for Linux, I suppose shim is replaced using apt or something similar, but judging from other threads, I’m a bit concerned about whether it will work properly.

Linux
Code: 
mokutil --sb-state
mokutil --db | grep -A13 "\[key"
mokutil --dbx | grep -A13 "\[key"
mokutil --kek | grep -A13 "\[key"

Windows
Code: 
Confirm-SecureBootUEFI
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes)
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).bytes)

Linux
Code: 
apt install pesign

find / `pwd` -maxdepth 10 | grep efi

pesign -S -i <Path to the EFI file>

Windows
Code: 
mountvol S: /s

Get-PfxCertificate -FilePath "S:\EFI\Microsoft\Boot\bootmgfw.efi" | Format-List Issuer,Subject,NotBefore,NotAfter

mountvol S: /d

Since Windows has been in the works since 2023, it has been thoroughly reviewed, and after more than three years, a proper procedure was “finally” established in March 2026.

Linux doesn't seem to be the same. If missing the deadline won't cause any problems, I think it's better to proceed cautiously rather than rush things and end up failing just because of the deadline.
 
Last edited:
You must log in or register to reply here.
Top Bottom
Back