仍在遇到 Windows 11 Secure Boot 证书错误?Microsoft 和 OEM 也没能解决这些问题 Microsoft 于 7 月 15 日举办了 OEM Secure Boot Office Hours 活动,召集来自 Microsoft 的工程师以及 Acer、Asus、Cisco、Clevo、Dell、Fsas/Fujitsu、Honor、HP、Lenovo、LG、Surface 和 Xiaomi 的代表,现场回答 IT 管理员关于 Windows 11 Secure Boot 2023 证书部署的提问。
Windows Latest 已经发布了一篇详细文章,涵盖了该场次中出现的所有修复方法和技术解答,从 AvailableUpdates 注册表键到企业设备组中的置信度评分如何运作。
不过,并不是所有问题都得到了解决。同一场 Office Hours 讨论串中,有不少管理员在描述 Microsoft 和 OEM 无法解释的 Secure Boot 证书错误,或者官方文档说应该可行但在他们的硬件上却失效的修复方法。

早在 3 月,Windows Latest 的 Ed Tittel 就写过他如何设法让一小批 10 到 15 台 PC 符合 CA-2023 证书要求的经历,而他发现这更像是整个行业的问题,而不是 Microsoft 的问题。
他测试中的 ASUS 主板有时会拒绝应用吊销列表,除非临时关闭 Secure Boot。MSI 主板在某些型号上会忽略更新,却在界面里显示 Secure Boot 已启用。ASRock 几乎每台系统都需要手动重置密钥并重新注册,而且相关文档几乎没有,甚至基本不存在。Dell、HP 和 Lenovo 设备整体表现更好一些,但也并非没有问题(这与本文后面看到的情况形成鲜明对比),同样存在分批推送和需要多次重启的 BIOS 更新。
MSI MAG B550 台式机上运行 Check_UEFI-CA2023.ps1 的输出Tittel 的 ASRock B550 Extreme4 台式机陷入一种状态:每次重启都会弹出一个与 Secure Boot 更新相关的虚假 CPU 变更警告。最终,他放弃了从固件层面修复,改为直接更换主板。
这已经是四个月前的事了……
如果你的 Windows 11 PC 或设备群卡在 Secure Boot 证书错误、BitLocker 恢复循环,或 KEK 无法更新,这份来自 OEM Secure Boot Office Hours 活动的未解决问题汇总,应该能帮你判断你遇到的是 Microsoft 已知的问题,还是尚未被任何人报告的新问题。
多位管理员描述了 Microsoft 或相关 OEM 无法完全解释的问题,或者官方文档中本应有效的修复方法在他们的 PC 上失效的情况。

OEM Secure Boot Office Hours 活动中最令人担忧的评论来自 epoch71,他管理着 7000 多台从 G7 到当前机型的 HP EliteBook 和 ZBook。在测试中,通过 AvailableUpdates 注册表键强制安装证书会触发 BitLocker 恢复。按照 HP 的公开指南,手动切换该美国 PC 厂商支持文章中列出的四个 Secure Boot BIOS 设置,同样也会触发这一情况。
Windows Latest 在 5 月报道过,HP 首次承认 2026 年 4 月的一批 BIOS 更新可能会破坏 BitLocker 用来封存密钥的 PCR7 测量值,从而在证书交接完成之前,每次重启都弹出恢复提示。

HP 的 Juergen_Bayer 起初建议 epoch71 确认已安装最新 BIOS,并保持新的、与证书相关的 BIOS 设置不变,让 Windows Update 自行处理证书新增。
epoch71 反驳说,他的设备群早已运行通过 HP Image Assistant 提供的最新 BIOS,但 BitLocker 恢复仍然会触发,而且并没有添加任何 HP 明确警告不要更改的证书设置。
当他在运行 BIOS V75 01.12.01 的 EliteBook 640 G10 上通过注册表键强制证书更新时,每次都会进入恢复模式。回退到旧版 BIOS V75 01.11.00 后问题消失了,但在成千上万台已部署设备上回滚 BIOS 版本,并不是大多数 IT 团队能在不造成明显干扰的情况下做到的。到会话结束时,HP 和 Microsoft 都没有给出后续答复。
一位名为 Shapalapa 的用户在 AMA 中详细批评了 HP 的部署方式。他在一台 EliteBook 840 G6 上描述自己长时间卡在 Under Observation – More Data Needed,直到安装 01.35.01 BIOS 后才继续推进;随后又回到 epoch71 所描述的同一 BitLocker 恢复循环,直到他们发现有三个特定的 BIOS 开关默认被禁用,需要手动启用,问题才得以解决。

他们还指出了 HP 文档设备列表的变化。HP 支持页面最初把 2018 年及更新的设备列为受支持机型,包括 ZBook 14u G5 和 ProBook 650 G4 等型号;后来在 HP 确认该硬件上的 NVRAM 容量无法容纳新证书后,这些条目又悄悄被移除了。在他们看来,HP 为停产设备提供的手动更新包,并不能替代真正的 BIOS 修复。HP 和 Microsoft 都没有对此回复。
salmankhan1 最初的问题是:设备虽然有 2023 证书、Secure Boot 标志已启用、TPM 也正常工作,但却报告 Secure Boot Status = Unknown。这个问题只得到了一部分答案。
Microsoft 的 Prabhakar 建议运行 Get-SecureBootRolloutStatus.ps1 来获得更全面的情况,但没有指出为什么在其他前提都满足的设备上,状态报告仍然错误的根本原因。
Checker-KP 描述了大约 700 台 HP EliteBook G9 和 G10 设备:把注册表键设为 0x5944 后,DB 证书更新成功,但 KEK 就是无法更新,每次重启后都会反复回到 Not Started。
HP 的 Duane_Gatlin 和 Juergen_Bayer 都给出了排查步骤,包括在注册表中尝试 0x4 来明确强制 KEK 更新,并确认两种型号可用的最新 BIOS 版本。
但当 Checker-KP 按照建议把一台测试机更新到最新 BIOS 后,KEK 仍然没有更新。讨论在没有确认修复方案的情况下就此结束,Checker-KP 也只能怀疑自己的这些设备是否属于受 Microsoft 对某些固件分组实施的已知问题阻断 影响的机型之一。Windows Latest 本月早些时候已详细报道过这一点:Microsoft 开始针对特定设备与固件组合暂停推送,而不是让一个已知有问题的更新继续安装。
一位用户名为 pbormet 的 IT 管理员表示,在 Dell 设备群上更新证书总体进展不错,但有一个例外:Optiplex 5000 机型在执行命令时拒绝更新注册表键。活动期间没有 Dell 代表回应。
Shapalapa 向 HP 提问,为什么这次证书过渡对 HP 客户尤其困难,涉及同样的 NVRAM 容量问题和 BitLocker 循环,HP 方面也没有回复。

在所有出席的 OEM 里,HP 和 Dell 用户报告的 Secure Boot 体验最糟,这与我们自 3 月以来记录的情况一致。我们最初关于 Secure Boot 2023 背后更广泛固件问题的报道指出,PC 行业内不一致的固件实现方式(而不是某一家厂商的失误)才是把一次常规证书变更变成 UEFI 压力测试的原因。
Windows Latest 在 6 月发布的 OEM 对比指南发现,Dell 采取了最保守的做法,自 2024 年底起在新硬件上同时预装 2011 和 2023 两套证书。相比之下,HP 的部署现在已经在三个月内引发了两轮 BitLocker 抱怨,分别出现在 4 月和这次 7 月的 Office Hours 会话中,而且第二轮出现在原本应已修复问题的 BIOS 版本上。

Windows Latest 还追踪了 HP 和 Dell 的固件问题如何蔓延为更广泛的 Windows 11 稳定性投诉,并且后来发现,在 2026 年 6 月 Patch Tuesday 更新中遭遇 BitLocker 恢复提示和启动失败的 PC 里,也有 HP 设备。
如果你是仍在处理这次部署的 IT 管理员,我们建议最稳妥的做法是先在具有代表性的硬件上试点,再大范围推送;在更改任何注册表键或 BIOS 设置之前,先确认 BitLocker 恢复密钥已备份;如果设备卡在与其证书状态不一致的状态上,请先从 %systemroot%\SecureBoot\ExampleRolloutScripts 运行 Detect-SecureBootCertUpdateStatus.ps1,再判断是否真的出了问题。
这篇讨论串里未解决的案例并不是什么你很难遇到的边缘情况。BitLocker 恢复循环、卡住的 KEK 更新,以及与设备证书状态不一致的 Secure Boot 状态读数,如今已经在 HP、Dell 以及混合型企业设备群中出现,涉及较旧硬件和今年发布的 BIOS 版本。
如果你在自己的 PC 或设备群上也看到了这些情况,那你面对的是一组有据可查的问题,只是从感受上看是否令人安心,就见仁见智了。
总之,这篇讨论串真正该让你记住的是:要把 BIOS 更新和 Secure Boot 证书部署看作当前两个相互重叠、但彼此独立的风险。设备通过了证书检查,并不代表其背后的 BIOS 就一定可以安全更新;而新 BIOS 也不代表证书更新就一定能顺利完成,epoch71 和 Checker-KP 都已经亲身验证了这一点。
在大规模操作这两者之前,先备份 BitLocker 恢复密钥,并查看你所用 OEM 的具体公告,而不要只依赖 Microsoft 的通用指导。

Windows Latest 的 OEM Secure Boot 指南是查看厂商已发布内容的最佳位置;如果你还没有确认设备群当前所处状态,Windows Latest 关于验证 Secure Boot 状态以及 PC 错过更新后该怎么做的指南,会逐步带你完成检查。
对于同一场 Office Hours 会话中 Microsoft 和 OEM 确认过的修复,包括应使用的正确注册表键、固件更新如何影响置信度评分,以及错过截止日期的设备会发生什么,配套的 Windows Latest 文章都已完整涵盖。
最后,如果你的设备受到已知固件阻断影响,Microsoft 已确认会对特定设备和固件组合暂停推送;这也许就能解释为什么你的 PC 会被故意延后更新,而公司和 OEM 正在设法修复问题。