Listen to this Post
Introduction:
The original Microsoft UEFI Secure Boot certificates, issued in 2011, are set to expire in June 2026. For Windows virtual machines running on Proxmox VE, this isn’t just a routine update—it’s an existential threat to boot integrity. If your EFI disks lack the newly enrolled 2023 certificates, your VMs will eventually reject bootloaders signed with the new keys, leading to boot failures, broken update chains, and potential BitLocker recovery nightmares.
Learning Objectives:
- Understand the technical implications of the Microsoft UEFI CA 2011 expiration and the 2023 certificate replacement.
- Master the step-by-step process to enroll updated Secure Boot certificates on Proxmox VE 9.x hosts via CLI, UI, and API.
- Learn how to verify successful enrollment inside Windows and Linux guests using PowerShell and
mokutil. - Implement BitLocker safeguard procedures to prevent recovery key prompts during the certificate update.
- Automate certificate enrollment across multiple VMs using Proxmox CLI scripting.
1. Understanding the Secure Boot Certificate Expiration
Secure Boot relies on a database of trusted certificates stored on the EFI system partition. When a VM boots, the UEFI firmware checks the bootloader’s digital signature against these enrolled certificates. The original Microsoft certificates—the Microsoft UEFI CA 2011 and Windows UEFI CA 2011—expire in June and October 2026, respectively. Microsoft issued replacement certificates in 2023.
If your Proxmox EFI disk only contains the 2011 certificates, any bootloader signed with the 2023 certificates will be rejected by the firmware. This means future Windows updates, security patches, and even new bootloaders will fail to load. The Proxmox team has already promoted warnings about missing 2023 certificates to `log_warn` level, making it impossible to ignore.
Proxmox Version Check:
pveversion --verbose | grep pve-edk2-firmware
If your `pve-edk2-firmware` package is at least 4.2025.05-1, newly created EFI disks automatically contain both certificate sets. Older EFI disks require manual enrollment.
2. Pre-Update Preparation: BitLocker Safeguards
For Windows VMs with BitLocker enabled, enrolling new certificates modifies the UEFI variables, which changes the Platform Configuration Register 7 (PCR7) measurement. This triggers BitLocker recovery mode unless you temporarily disable protectors.
Inside the Windows VM (PowerShell as Administrator):
List all BitLocker volumes manage-bde -status Disable protectors for C: drive (repeat for each encrypted volume) manage-bde -protectors -disable C:
This command suspends BitLocker protection until the next reboot. After the certificate enrollment and a successful boot, re-enable protectors:
manage-bde -protectors -enable C:
Critical Warning: If you skip this step, your VM will prompt for the 48-digit recovery key on next boot. Ensure you have recovery keys backed up before proceeding.
3. Enrolling Updated Certificates via Proxmox UI
The simplest method for single VMs is the Proxmox web interface.
Step-by-Step GUI Process:
1. Navigate to your VM’s Hardware view.
2. Select the EFI Disk (usually `efidisk0`).
3. Click the Disk Action dropdown menu.
4. Select Enroll Updated Certificates.
This action sets the `ms-cert=2023w` marker on the EFI disk and enrolls both Microsoft UEFI CA 2023 and Windows UEFI CA 2023 certificates.
Prerequisite: The VM must be shut down (not running) for this operation to succeed. The UI will disable the option if the VM is running or if the EFI disk doesn’t have pre-enrolled keys.
After enrollment, perform a full shutdown-start cycle (not just a reboot) for the changes to take effect in the UEFI firmware.
4. Enrolling Updated Certificates via Proxmox CLI (qm)
For automation or headless environments, the `qm` command-line tool provides the same functionality.
Command Syntax:
qm enroll-efi-keys <VMID>
Example:
qm enroll-efi-keys 101
Behavior Notes:
- The command fails if the VM is running.
- It fails if the VM has no EFI disk.
- It does nothing for VMs without pre-enrolled keys.
- It updates to `ms-cert=2023w` if the current marker is
ms-cert=2023. - The command works reliably for stopped VMs.
Bulk Automation Script:
!/bin/bash
Enroll certificates for all Windows VMs with EFI disks
for vmid in $(qm list | awk '{print $1}' | grep -E '^[0-9]+$'); do
if qm config $vmid | grep -q 'efidisk0'; then
echo "Enrolling certificates for VM $vmid"
qm stop $vmid 2>/dev/null Ensure VM is stopped
qm enroll-efi-keys $vmid
qm start $vmid
fi
done
5. Enrolling Updated Certificates via Proxmox API
For integration with orchestration tools, the Proxmox API endpoint allows programmatic enrollment.
API Endpoint:
POST /nodes/{node}/qemu/{vmid}/config
Payload:
{
"efidisk0": "local-lvm:vm-101-disk-0,size=4M,pre-enrolled-keys=1,ms-cert=2023w"
}
cURL Example:
curl -X POST "https://proxmox-host:8006/api2/json/nodes/pve/qemu/101/config" \
-H "Authorization: PVEAPIToken=user@realm!token=xxxxxxxx" \
-H "Content-Type: application/json" \
-d '{"efidisk0":"local-lvm:vm-101-disk-0,size=4M,pre-enrolled-keys=1,ms-cert=2023w"}'
Important: The API call sets the marker but may not enroll certificates unless the `pve-manager` dependency is satisfied. Always verify enrollment inside the guest after the API call.
6. Verifying Certificate Enrollment Inside the Guest
After completing the enrollment and performing a full shutdown-start cycle, verify that the new certificates are present.
For Windows VMs (PowerShell as Administrator):
Check for Microsoft UEFI CA 2023 [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft UEFI CA 2023' Check for Windows UEFI CA 2023 [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
These commands return `True` if the respective certificate is enrolled.
For Linux VMs (with `mokutil` installed):
sudo mokutil --all --list-enrolled | grep -E '(Microsoft|Windows) UEFI CA 2023'
This lists all enrolled certificates and filters for the 2023 entries.
Alternative Verification via Registry (Windows):
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -1ame "AvailableUpdates"
A value of `0x40` indicates the Secure Boot DBX update is pending.
7. Troubleshooting Common Issues
Issue 1: “EFI disk without ‘ms-cert=2023k’ option” Warning
This warning appears when starting a VM that lacks the 2023 certificates. Follow the enrollment steps above. The warning is now a `log_warn` in Proxmox 9.2+ to ensure visibility.
Issue 2: BitLocker Recovery Prompt After Enrollment
If you forgot to disable BitLocker protectors, you’ll need the 48-digit recovery key. Boot the VM, enter the key, then run:
manage-bde -protectors -enable C:
Issue 3: Enrollment Fails for Running VMs
The `qm enroll-efi-keys` command explicitly requires the VM to be shut down. Stop the VM first:
qm stop <VMID> qm enroll-efi-keys <VMID> qm start <VMID>
Issue 4: “No pre-enrolled keys set” Error
This occurs when the EFI disk was created without pre-enrolled-keys=1. You may need to recreate the EFI disk or manually set the option:
qm set <VMID> --efidisk0 <storage>:<size>,pre-enrolled-keys=1,ms-cert=2023w
What Undercode Say:
- Key Takeaway 1: The June 2026 deadline is non-1egotiable. VMs without the 2023 certificates will face boot failures when Microsoft revokes the 2011 certificates. Proactive enrollment is the only mitigation.
- Key Takeaway 2: BitLocker integration is the hidden trap. Always suspend protectors before enrollment, or be prepared to recover with the 48-digit key. Document and back up all recovery keys before starting the update.
Analysis:
Charles Crampton’s runbook addresses a critical gap in Proxmox administration—the silent certificate expiration that most teams overlook until it’s too late. The technical depth reflects real-world pain points: BitLocker interruptions, CLI automation, and verification steps. The Proxmox community has been actively patching this since early 2026, with `pve-edk2-firmware` updates and UI enhancements rolling out progressively. However, the responsibility still falls on administrators to manually enroll certificates for existing VMs. The warning messages in Proxmox 9.2+ are a step forward, but they don’t replace proactive runbooks. Organizations running hundreds of Windows VMs need orchestrated scripts—not manual clicks—to meet the deadline. The fact that Daniel Kral tested this series across Windows 11, Debian, and Proxmox VMs underscores the cross-platform impact, but Windows BitLocker remains the sharpest edge. This isn’t just a Proxmox problem; it’s a UEFI Secure Boot ecosystem issue that demands attention across all hypervisors.
Prediction:
- -1 Expect a surge in support tickets and forum posts starting May 2026 as administrators scramble to update certificates, with many discovering BitLocker recovery key gaps the hard way.
- -1 Organizations that delay will face unplanned downtime during critical Windows update cycles, potentially impacting production workloads and compliance audits.
- +1 Proxmox’s proactive warning system and UI enrollment options will reduce the blast radius compared to other hypervisors, making it a safer choice for Windows workloads.
- +1 The automation capabilities via CLI and API will enable savvy DevOps teams to roll out updates seamlessly, turning a potential crisis into a routine maintenance task.
▶️ Related Video (68% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Charlescrampton Ive – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
