The 2026 Secure Boot Certificate Transition For Proxmox And Debian
Tech GuruQuick Answer
Treat the physical host and each virtual machine as separate Secure Boot checks. Record firmware trust and revocation state, Debian shim/SBAT, Proxmox virtual firmware, and Windows guest certificates before changing any of them. Keep console access and a tested recovery boot path. A successful host reboot does not establish that a Windows VM, its recovery media, or its next migration will boot correctly.
Evidence status: Debian's certificate-transition warning is documented. This article contains no host firmware dump, enrollment log, Windows guest boot capture, or recovery result. The exact OEM and guest procedures still need verification for the installed versions.
What To Check
Debian 13.6 release notes warn that the expired 2013 UEFI CA can affect future shim-signed updates and advise applying OEM CA, KEK, and DBX updates. That is a reason to inspect the boot chain; it is not evidence that every machine fails on the same date.
Keep four records: physical firmware trust state, the Debian boot chain, Proxmox virtual firmware, and the guest operating system. The original recovery plan also calls for Windows VM cloning, recovery boot, snapshot, and migration tests. Keep those tests separate so a failure can be tied to one changed layer.
Key Concepts In Plain Language
- Firmware DB/DBX: The firmware trust and revocation layer to inventory separately from operating-system packages.
- shim/SBAT: Parts of the Linux boot-chain review; record their installed state rather than treating a firmware update as a complete check.
- OVMF and guest state: The virtual firmware and enrolled guest certificates to inspect for each VM, independently of the host.
Technical Checklist
- Inventory physical-host firmware DB and DBX state separately from Debian shim/SBAT, Proxmox OVMF templates, and each Windows guest's enrolled certificates.
- Record whether Secure Boot is enabled, which keys sign the active boot chain, and whether a known-good console boot remains available after enrollment changes.
- Clone one representative Windows VM and test normal boot, recovery boot, snapshots, and migration with the planned virtual firmware state.
- Do not update host firmware trust, guest OVMF certificates, and guest operating-system state in one unobservable step.
Interactive Operating Model
Use the detailed runbook and acceptance checks below with this overview. No test result is implied by the diagram.
Before You Start: Safe Defaults
Have console access, current backups, recovery media, and the credentials or keys needed to use that media. Record how the host and representative guest will be recovered if the proposed boot chain is rejected. Do not assume the same rollback mechanism covers firmware databases and VM state.
- Confirm the exact installed release, edition, repository, firmware, and add-on state instead of relying on the dashboard label alone.
- Export configuration and protect application data, credentials, certificates, and encryption material separately.
- Stage on a clone, spare node, canary device, or least-critical workload whenever the platform allows it.
- Define stop conditions and console access before the maintenance window begins.
Go, Hold, Recover, Or Escalate
Hold enrollment changes if the OEM update path, virtual firmware procedure, or recovery boot is unverified. Do not combine host trust updates and guest changes merely because they share a maintenance window.
Planned Checks And Recovery
Unperformed Debian UEFI inspection: mokutil --db lists the enrolled DB certificates, and mokutil --kek shows KEK entries. Preserve the complete output before filtering it. The Debian CA transition guide uses these read-only checks; they do not modify enrollment or establish a guest's OVMF state. Debian notes that certificate expiry normally does not invalidate existing signed boot binaries, while future shim signatures and buggy firmware require care. If enrollment or signature errors are unexplained, seek vendor guidance instead of forcing a manual variable update.
Step 1: Inventory the physical boot chain
Record the host model, firmware version, Secure Boot setting, enrolled trust/revocation state, and the Debian boot packages in use. Keep the vendor instructions alongside the inventory. A package version alone is not the complete record requested by this guide.
Step 2: Inventory the virtual boot chain
For each representative Windows VM, record Proxmox and virtual firmware versions, enrolled certificates, guest state, and the current boot configuration. Select a clone whose storage and migration path match the intended deployment. Document which other guests the clone does not represent.
Step 3: Rehearse recovery before enrollment
Boot the planned recovery media on the test target and confirm that console access remains available. Keep the original host and guest records outside the machine being changed. If recovery depends on an untested boot option, stop and resolve it before modifying enrollment.
Step 4: Change and test one trust layer
Follow the verified OEM, Debian, or Proxmox procedure for the selected layer. Record the exact change and resulting boot state before proceeding to another layer. On the guest clone, test normal boot, recovery boot, snapshot recovery, and migration as separate cases; record failures rather than describing the clone as generally compatible.
Step 5: Recheck after recovery
Return the test target through the supported recovery path and verify its actual trust and boot state. Record any state that recovery did not restore. Expand only after normal boot, the required failure case, monitoring, and recovery have documented outcomes.
Validation Checklist
- Host firmware, Linux boot packages, virtual firmware, and Windows certificates have separate before/after records.
- Console access and recovery media work on the representative target without relying on the failed boot path.
- Normal boot, recovery boot, snapshot recovery, and migration each have a result, not a single combined pass label.
- Unexplained signing or recovery changes stop the rollout; alerts and the recovery handoff have a named owner.
Troubleshooting
- Host boots, guest does not: Compare the guest's virtual firmware and enrolled certificates with the tested clone, not only the host package list.
- Normal boot works, recovery media fails: Check the recovery boot chain against the planned trust state before proceeding.
- Recovery returns an unexpected state: Identify which firmware or guest state was outside the chosen restore mechanism.
Security, Privacy, Legal, And Recovery Boundaries
Security
Use official packages and release guidance, preserve signing and authentication controls, and do not expose a management plane to simplify migration.
Privacy
Configuration exports and support bundles may contain names, addresses, tokens, certificates, device identifiers, and user data; encrypt and restrict them.
Legal
Review software licenses, support entitlements, and retention obligations before copying production data into a test environment.
Recovery
A rollback is credible only when its media, configuration, keys, data, boot path, and restore order are available outside the system being changed.
Record any local exception, its owner, its expiration condition, and the evidence required to remove it.
What The Evidence Does Not Prove
No firmware enrollment or revocation change was performed for this article. A passing clone would establish only that clone's recorded boot paths, not compatibility for every OEM, Windows build, or virtual firmware combination. Exact enrollment and recovery instructions remain a prerequisite, not an implied result of the prose.
Related TechGeeks Resources
- Linux and Homelab Notes: Start Here
- Homelab Backup Strategy: NAS, Offsite Copies, and Restore Tests
- How Do You Document a Homelab So Someone Else Can Recover It?
References
Next Action
Keep the four trust-layer records and the recovery-boot result together. Schedule the next layer only when the previous change has an explained outcome.
