症状：你看到 Windows VM 的 Secure Boot 证书更新提醒，或发现 EFI 磁盘仍标记旧证书，但不确定现在是否会影响启动。
判断框｜适合：你负责 Proxmox 上启用 Secure Boot 的 Windows VM，应先逐台核对系统版本、EFI 状态和 BitLocker 恢复密钥，再按对应版本的 Proxmox 官方流程试点、分批更新并验收；不适合：把这项工作当成 Proxmox 宿主机的 Secure Boot 更新。旧证书到期不会自动令 Windows VM 立刻停机，但可能影响后续启动组件的安全保护。
负责 Proxmox 宿主机与 Windows VM 更新的系统管理员，可以按本文流程安排核验和变更。
维护多个客户环境的 MSP，可以据此设计试点批次和验收记录。
管理启用 Secure Boot 或 BitLocker 的 Windows VM 的企业 IT，应先确认恢复密钥能实际取用。
最后更新于 2026 年 11 月 3 日；证书影响核对自 Microsoft 证书到期说明、Windows 客户端更新说明、Windows Server 排查文档及 Proxmox VE 虚拟机文档。
旧证书到期 vs 立即停机：Windows VM 还会启动吗？
会，旧证书到期本身不等于虚拟机必然无法启动。 Microsoft 说明，未更新相关 2011 年证书的设备仍可能启动并继续接收常规 Windows 更新；但后续启动组件、Secure Boot 数据库和撤销列表的保护可能无法按预期更新，启动链安全状态会逐步落后。
“2011 年证书到期”也不是所有证书在同一天统一失效。Microsoft 列出的证书包含 2026 年 6 月和 2026 年 10 月等不同到期日，具体日期取决于证书种类；应按证书更新要求处理，而不是把某一天当作所有 VM 的统一停机期限。
| 你核对的对象 | 表示什么 | 不能据此认定什么 |
|---|---|---|
| Proxmox 的 EFI 磁盘 | 虚拟 UEFI 是否登记了可用于验证启动程序的证书 | 不能单独证明 Windows 来宾已完成后续证书部署 |
| Windows 来宾的注册表与系统事件 | 来宾报告的证书更新阶段和结果 | 单一事件不能替代启动、Secure Boot 与 BitLocker 验收 |
| Proxmox 宿主机的 Secure Boot | 物理服务器启动 Proxmox 时使用的启动链配置 | 不能代表 Windows VM 的 Secure Boot 证书状态 |
本文讨论的是Windows 来宾 VM 的 Secure Boot 证书，不是 Proxmox 宿主机自身的启动配置。Proxmox 的虚拟机文档说明，EFI 磁盘用于保存虚拟 UEFI 状态；宿主机上的 Secure Boot 是另一套配置对象。
Proxmox Windows VM Secure Boot 证书更新：虚拟 EFI 登记 vs 来宾更新
Proxmox 的 EFI 磁盘保存虚拟 UEFI 状态和启动项。当前 Proxmox 虚拟机文档说明，配置标记 ms-cert=2023k 表示 2023 证书已登记；较早创建的 EFI 磁盘可能需要执行登记操作，而部分标记如 ms-cert=2023 或 ms-cert=2023w 可能表示登记不完整。
因此，Proxmox EFI 磁盘显示证书已登记，并不等于 Windows 来宾的更新流程已经全部完成。反过来，只看到 Windows 收到常规更新，也不能证明虚拟 UEFI 已经包含所需证书。把两边状态分开记录，才不会在一个界面看到“成功”后就把整批 VM 标记为完成。
Proxmox 文档列有适用于相应版本的 EFI 证书登记方式；你的界面和命令是否可用，必须以安装版本对应的官方文档为准。
更新前要准备什么：先有恢复条件，再安排停机
如果恢复密钥不可取用、备份不能验证，或你尚未确认 VM 的 UEFI 设置，不要开始批量变更。Secure Boot 配置变化可能改变 BitLocker 用来验证启动过程的测量值；Microsoft 文档指出，PCR 与启动配置变化可能触发恢复提示，详见 BitLocker 预启动恢复说明。
按以下顺序准备：
- 建立 VM 清单。 记录 VM ID、Windows 来宾版本、是否启用 Secure Boot、EFI 磁盘是否存在、当前 Proxmox 版本，以及 BitLocker 是否启用。先把无法确认的条目标成“待核实”，不要猜测。
- 核对 EFI 磁盘配置。 在 Proxmox 节点上读取 VM 配置，先做只读检查：
bash
pveversion -v
qm config <VMID> | grep '^efidisk0:'
示例输出：
text
efidisk0: local-lvm:vm-120-disk-0,efitype=4m,ms-cert=2023k,pre-enrolled-keys=1,size=4M
这是示意输出，不是本站实测，也不代表你的 VM 实际配置。若输出没有 ms-cert=2023k，或出现其他标记，应对照当前版本的官方说明判断；不要只凭“有 EFI Disk”就认定证书状态正确。
3. 确认 BitLocker 恢复密钥。 依据你所在组织的密钥保管流程，从实际存储位置取回密钥，并确认负责本次维护的人有权限访问。不要把密钥留在 VM 注释、共享工单或不受控的变更记录里。
4. 检查保护状态并规划暂停。 对启用 BitLocker 的卷，先按 Proxmox 官方文档和 Microsoft 操作指南确认保护方式。Proxmox 文档给出的暂停命令形式如下，卷盘符须按你的实际配置替换：
powershell
manage-bde -protectors -disable C:
有多个受 BitLocker 保护的卷时，应逐卷检查。该操作是暂停保护，不是解密；具体暂停与恢复行为及适用命令，应核对 Microsoft BitLocker 操作指南和 manage-bde 保护器命令说明。即便已暂停，恢复密钥仍须在手边。
5. 准备可恢复的来宾备份。 确认 VM 数据备份可用，并按团队流程验证恢复点；宿主机配置备份不能代替 Windows 来宾的恢复方案。将变更负责人、窗口、验收条件和停止条件写入记录。
先试点 vs 直接批量：按目标版本执行登记
选择一台业务影响较低、且备份可恢复的 VM 作为试点。先核对已安装的 Proxmox 版本，再查该版本对应的虚拟机文档；当前文档列出了 EFI 磁盘的证书登记流程，包括图形界面操作和命令行方式。不要把其他版本的界面截图、社区命令或宿主机 Secure Boot 命令当成你当前版本的操作依据。
在官方文档明确适用的版本中，命令行示例为：
qm enroll-efi-keys <VMID>
Proxmox 文档说明，该命令要求 VM 处于关机状态；图形界面登记的入口和可用性也应按目标版本文档确认。若你的安装版本没有此命令、界面入口不一致，或操作提示与当前官方文档不符，停止扩展，不要套用未经核验的指令。
试点阶段保留变更前的 qm config <VMID> 输出、变更任务结果和 Windows 来宾状态；登记后再启动试点 VM，留意 Proxmox 任务日志和启动结果。不要承诺可以在线完成、无需重启，也不要假定不同来宾版本的行为完全相同。只有试点通过下文的双侧验收，才进入下一批。
更新后怎么确认结果：宿主标记 vs Windows 状态
在 Proxmox 侧，再次读取 EFI 磁盘配置，确认是否显示 ms-cert=2023k；若仍是其他标记，或 VM 启动任务提示状态异常，先保留记录并查对应版本文档，不要重复登记或立即关闭 Secure Boot。
在 Windows 来宾内，使用管理员 PowerShell 检查 Microsoft 文档列出的状态：
Get-ItemProperty `
-Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' |
Select-Object UEFICA2023Status
示意结果：
UEFICA2023Status
----------------
Updated
Windows Server 排查文档将 UEFICA2023Status = Updated 作为更新状态指示，并列出系统日志中的相关事件：1808 表示成功，1801 表示未完成，1800 表示需要重启，1803 表示缺少 KEK，1795 表示固件错误。若状态值缺失、出现错误值，或仍有未处理的相关事件，不要仅凭一次启动就关闭工单。
| 验收维度 | 通过条件 | 未通过时的处理 |
|---|---|---|
| Proxmox EFI 磁盘 | 配置标记与该 PVE 版本文档要求一致，任务日志没有未处理异常 | 保留配置与任务日志，暂停该 VM 后续批次 |
| Windows 来宾 | 来宾状态显示更新完成，系统事件没有未解决的失败或待重启状态 | 按来宾版本的 Microsoft 文档继续排查 |
| 启动与 Secure Boot | VM 可正常重启，来宾内 Secure Boot 状态符合组织要求 | 不把“能够启动”单独作为证书更新成功 |
| BitLocker | 无未处理恢复提示，保护状态符合组织策略 | 先通过组织密钥流程恢复，再确认保护已恢复 |
若 VM 曾提示恢复，确认恢复密钥使用后，再核对 BitLocker 是否已经按策略恢复保护；Microsoft 的恢复流程说明建议对恢复事件追查原因，避免反复进入恢复。不要把证书更新状态和数据恢复能力混为一谈。
异常 VM vs 已验收 VM：分开排期，避免反复重试
试点通过后，按业务重要性分批推进。每批明确停机窗口、执行人、BitLocker 恢复密钥保管人、成功条件和回退条件；一旦出现启动异常、恢复密钥不可用、EFI 标记与官方流程不符等情况，就把该 VM 移入例外清单，停止同类批次操作，先查清原因。
如果任务其实是从 VMware 迁移虚拟机，而不是更新来宾证书，可先参考这份虚拟化平台迁移评估说明，不要把迁移步骤与证书轮换混成同一次变更。
完成后，把通过的命令、适用的 Proxmox 版本、Windows 来宾状态检查、BitLocker 处理方式及例外情况写进团队变更记录。Proxmox 或 Microsoft 文档更新、来宾系统版本变化后，先复核流程，再把记录用于其他环境。
共享虚拟化 vs 独享 AMD 物理机：资源边界也要纳入维护计划
若你当前在共享 VPS 或公有云实例里运行 Proxmox，底层 EFI 状态、虚拟化权限或实例控制能力可能受服务方案限制；共享算力也可能带来邻居负载干扰，带宽和流量费用则要看具体计费规则。若你需要长期自主管理宿主机、维护多台 VM 并安排可控的变更窗口，独享 AMD 物理机通常更适合作为资源池；但它不会替你更新来宾证书、保存 BitLocker 密钥或保证 VM 恢复。
OSFP Cloud 当前产品页列出可安装 Proxmox VE 8 / 9 的 AMD EPYC 7543P 物理机选项，提供 32 核 / 64 线程、128GB 或 256GB 内存和直连 NVMe；机房位于日本东京。页面说明计费周期包括月付、季付、半年付和年付，按月租乘周期月数计算；Linux 使用 SSH，选择 Windows Server 后使用 RDP。以上是宿主环境信息，不代表对任一 Windows VM 证书更新的兼容承诺或恢复保证。查看 OSFP Cloud 可装系统与物理机配置；查看计费周期计算方式
如果现有环境难以取得 EFI 磁盘控制权，或多台 VM 需要稳定、独享的长期资源，可以先核对 OSFP Cloud 的 Proxmox 可装系统和机器配置，再按实际 VM 数量与维护窗口制定分批更新计划；证书轮换与 BitLocker 恢复仍应由你的运维流程负责。