Windows 11 2023年安全启动更新在部分电脑上失败，暴露更广泛固件问题
CA 2023吊销更新将一个幕后安全功能变成了PC用户和硬件厂商的巨大难题。 自2011年以来，Secure Boot一直是PC生态系统的一部分，但2023年至2025年它终于成为焦点，而这种关注并非微软、OEM或固件厂商所期望的。曾经是一个低调的幕后安全功能，突然登上了头条报道。事实上，随着CA-2023证书的推出，它暴露了整个PC行业在固件实现、证书处理和更新流程上的长期不一致。简而言之，情况既不美观也不愉快。
对Windows用户来说，结果是一堆令人困惑的问题，包括启动警告、启动链中断，以及供应商指导的前后不一。普遍的感觉是，旨在提升信任和可靠性的Secure Boot反而成了不确定和混乱的源头。
本文将解析什么是Secure Boot、其工作原理、为何CA-2023重要、厂商如何跌跌撞撞，以及当Secure Boot更新失败时用户能做什么。途中，我会解释所有缩略语，逐步讲解信任链，并基于实际排错经验提供实用建议。我刚完成了一段艰辛甚至可称史诗般的旅程，使我管理的10至15台PC全部符合Secure Boot标准并运行CA 2023启动证书。这场经历让我学到了超乎想象的东西。
跳转
切换什么是Secure Boot及其重要性
Secure Boot是由统一可扩展固件接口（UEFI）定义的功能，UEFI是英特尔对传统BIOS的现代替代方案。其目的是确保系统启动时只有受信任且已签名的引导加载程序和操作系统组件能够运行。
Windows安全仪表盘显示Secure Boot已启用为此，Secure Boot依赖固件中存储的一组加密密钥。这些密钥定义了信任、允许和明确禁止的内容。
关键组件如下：
平台密钥（PK）
平台密钥确定系统所有者。控制PK的人控制Secure Boot配置。通常OEM在出厂时安装自己的PK。
密钥交换密钥（KEK）
密钥交换密钥授权对Secure Boot数据库的更新。微软、OEM，有时还有企业管理员维护KEK。有效的KEK是允许第三方对UEFI中的证书和数据库进行更新的通行证。
允许签名数据库（DB）
该数据库包含受信任的引导加载程序和操作系统组件的哈希值和证书。如果某个签名存在于DB中，固件允许其运行。
禁止签名数据库（DBX）
这是“吊销列表”。任何在DBX中的内容都被明确阻止——即使它曾经是受信任的。DBX更新是业内吊销受损引导加载程序的方式。最初的CA-2011开启了整个Secure Boot流程；微软计划在2026年晚些时候吊销它。CA-2023将取代它，并通过Windows Update和OEM UEFI更新逐步推送。
Secure Boot为何重要？
Secure Boot旨在阻止rootkit、bootkit及其他预操作系统的恶意软件。如果攻击者能攻破启动链，他们就能躲避操作系统检测，持续隐匿并长期存在。他们会不断卷土重来，因为他们运行在操作系统之外，独立于操作系统。Secure Boot正是为阻挡这种行为而设计。
理论上，Secure Boot是一个简洁优雅的解决方案。但实际上，Secure Boot生态复杂、分散，充满各种边缘案例。
不过，Secure Boot如今变得尤为重要且更为“二元”。优点是它工作时表现良好；缺点是出现问题时，排查既麻烦又耗时。
引发CA-2023的Secure Boot漏洞
2023年初，微软宣布发现一个重大安全隐患，较旧的Windows Boot Manager二进制文件被攻破，有可能绕过Secure Boot。为解决这一问题，微软发布了名为CA-2023吊销的DBX更新，将易受攻击的引导加载程序加入禁止列表，并提供了一个新的签名引导加载程序及匹配的证书，从而免疫此类攻击。
为什么必须这样做？
攻击者发现了利用旧版引导加载程序禁用Secure Boot保护的方法。吊销这些二进制文件对维护生态完整性至关重要。
为什么这会导致系统出问题？
许多OEM存在：
- 固件过期
- DB/DBX处理不一致
- 更新流程中断
- 非标准的Secure Boot实现
- 密钥集不完整或错误
- 固件静默忽略DBX更新
- 固件在应用DBX更新时导致系统变砖
换言之，这次吊销暴露了多年的技术债务。许多情况下，仅尝试更新就足以影响PC。最好的状况是受影响的PC无法正常重新启动（开始菜单中的电源>重启）；最坏则可能无法开机，甚至无法进入UEFI。非常糟糕！
CA-2023之后的结果
数百万系统处于以下状态之一：
- Secure Boot启用但未实际执行吊销
- 更新失败导致Secure Boot禁用
- Secure Boot卡在“用户模式”，密钥不匹配
- 应用DBX更新后无法启动
- 固件完全拒绝应用CA-2023更新
这不是微软单方面的问题，而是整个生态系统的失败。显然，这让遇到这些问题的用户苦不堪言。就我而言，我一台基于ASRock B550 Extreme4、搭载Ryzen 5的PC出现了几乎所有这些故障，最终只得更换主板才能解决。
“Secure Boot链”如何工作？
要理解CA-2023为何引发如此多麻烦，了解信任链的逐步过程很有帮助。步骤1：固件验证PKPK有效时，系统知道平台归属。步骤2：固件验证KEK这些密钥授权DB和DBX的更新。步骤3：固件加载DB和DBX它们定义了允许和禁止的内容。步骤4：固件验证引导加载程序若引导加载程序签名匹配DB条目且不在DBX中，则允许运行。步骤5：引导加载程序验证操作系统组件Windows Boot Manager检查winload.efi、驱动等早期启动组件的签名。步骤6：操作系统在信任状态下启动一切正常，Windows即可正常加载。但很多步骤都存在出错的可能，这使得该流程脆弱且偶尔出现卡顿甚至失败。以下情况都可能导致失败：
- DB缺少必需的签名
- KEK过期
- PK错误
- 固件处理更新异常
- 引导加载程序版本不匹配（Windows在C:\Windows目录下有副本，而EFI分区使用另一个版本）
若遇此类情况，Secure Boot可能失败或回退，也可能悄无声息地不执行安全策略。例如，我遇到过每次启动都会弹出“CPU变更”提示，要求确认或回滚TPM安全设置的假警告。截图如下：
这是ASRock B550 Extreme4 UEFI的已知问题，即使Secure Boot发生变化或更新也会报告处理器变更。实际上，我连续两周每次启动都要在此处输入“N”才能进入Windows桌面，导致启动时间增加2到3分钟，非常烦人。
不同主板厂商常见的Secure Boot问题
CA-2023推出揭示了各厂商固件纪律的巨大差异。一些台式机和笔记本顺利完成更新；另一些则从小问题到系统无法启动的严重故障皆有。以下简述主要厂商表现。
华硕（ASUS）
部分华硕主板拒绝在Secure Boot启用时应用DBX更新，要求先临时禁用Secure Boot，颇为矛盾。另一部分主板更新后留下“半吊销”状态，即存在CA-2011证书时，CA-2023证书或许已在，但无法发挥作用。
微星（MSI）
- 部分（非全部）微星主板以以下问题臭名昭著：
- DBX处理不一致
- 固件静默忽略更新
- Secure Boot模式与界面标签不符
- 系统意外回退为出厂密钥
华擎（ASRock）
华擎主板常需要手动操作，例如：
- 清除密钥
- 恢复出厂默认设置
- 重新注册微软密钥
- 手动应用DBX更新
其文档简陋，用户常常摸索。我拥有两块号称相同型号（B550 Extreme4）的主板，其中一块靠手动及微软Windows Update更新搞定问题，而另一块无法将待处理的更新（含WU和手动应用）与固件数据库内容协调一致，表现出上文提及的“CPU变更”系列提示。
戴尔、惠普、联想（及其他OEM）
面向企业和消费者的PC及笔记本厂商（包括宏碁、华硕、Dynabook等）表现总体较好，但仍存在：
- 分批推送更新
- BIOS/UEFI更新时机不一致
- 部分系统需多次重启才能应用DBX更改
在answers.microsoft.com、TenForums.com、ElevenForum.com及TechPowerUp.com等论坛，大量求助贴显示众多笔记本和台式机用户，尤其是DIY或高端定制组装PC用户，面临Secure Boot问题。
自组PC
同厂商不同主板因：
- 芯片组不同
- 固件分支不同
- 发布年份不同
- OEM与零售版本不同
表现可能差异巨大。总的来说，缺乏标准化显而易见。遇到的Secure Boot问题多种多样，有的最终通过Windows更新或手动修复，有的顽固难改。我本人经历了失败与成功交替的过程。
Secure Boot更新失败时用户能做什么
通过系统信息（msinfo32）工具快速确认Windows是否识别Secure Boot处于激活状态。Secure Boot故障形式多样。Windows更新可能报告成功，但DBX（吊销列表）未改变。固件显示Secure Boot“已启用”，但实际无执行（PowerShell的confirm-SecureBootUEFI命令会报告false）。
系统可能启动但未通过合规性检测（详见后文Garlin脚本部分）。引导加载程序可能与DB条目不匹配，或更新后系统启动受阻（如我这台ASRock B550 Extreme4所遇）。问题复杂，可尝试多种修复方法。以下列举常见原因及对应解决建议。
密钥不匹配（PK/KEK/DB/DBX）
若PK或KEK过期，固件可能拒绝数据库更新。可尝试以下措施：
- 恢复出厂或默认密钥（通常在UEFI Custom模式下提供此选项）
- 重新注册微软密钥（通常需重新应用微软更新，即卸载后重装，可能通过DISM，Windows Update支持限时回滚）
固件忽视DB或DBX更新
部分PC和笔记本的UEFI只有满足特定条件才应用DB或DBX更新。可能需要先禁用Secure Boot，关闭兼容支持模块（CSM，允许BIOS与UEFI双启动，现代PC多为UEFI专用），有时还需清除Secure Boot密钥。多次试验和参考他人经验有助突破难点。
过时的引导加载程序
旧版Windows安装盘或修复盘含有已不兼容Secure Boot的引导程序，2026年微软加大吊销CA-2011力度后情况更糟。DBX可能阻止此类程序。修复方法较简单，因为引导程序不与固件直接交互：
- 运行Windows Update替换旧版引导加载程序
- 使用bcdboot工具重建启动文件
- 确保EFI分区健康，如损坏需重建
固件漏洞或怪异表现
特别是老旧PC，启动Secure Boot前更新（刷写）UEFI固件是好主意。但部分老机型2023年后已无可用更新。须知某些系统需多次重启、特定固件版本或手动导入DB/DBX，以下方法有帮助：
- 升级至最新稳定固件版本（非万不得已勿用测试版，避免换成不稳定因素）
- 在有供应商更新时，使用官方固件包应用Secure Boot数据库更改（例如我MSI MAG Tomahawk未刷含Secure Boot和CA-2023元素的固件前无法正常工作）
- 固件更新完成后，再执行Windows Update更新，避免新版更新遇到旧固件造成问题（我ASRock B550 Extreme4深有体会）
总之，从固件更新到Windows更新，优先使用自动处理，必要时才动手操作UEFI，能大幅降低卡壳风险。
脚本如何帮助解决Secure Boot更新问题
CA-2023推送期间，社区驱动的工具和诊断发展尤为引人注目。尤其是Eleven Forum的VIP和达人用户Garlin，发起了一个超过50页的主题，其中包含有用的PowerShell脚本，并持续提供支持和讨论。他的脚本功能包括：
- 枚举Secure Boot密钥
- 验证DB/DBX条目
- 检测不匹配项
- 识别过时引导加载程序
- 验证执行状态
- 生成详细报告
对很多用户来说，Garlin的脚本是首次清晰看到固件实际状态的窗口。以下图为例，展示了我刚重建的MSI MAG Tomahawk B550台式机运行Check_UEFI-CA2023.ps1脚本的输出：
MSI MAG B550台式机上Check_UEFI-CA2023.ps1脚本输出细看截图可见，该PC已安装CA 2011和CA 2023的密钥交换密钥（KEKs），DB证书包含UEFI CA 2011、Windows PCA 2011及三种CA 2023。DBX证书列表为空（下方可见CA 2011尚未吊销，届时相应条目将转至此处）。
EFI文件显示引导管理器允许UEFI CA 2023，注册表也支持，最新的Secure Boot代码完整性策略已生效。微软利用这项策略阻断易受攻击或回滚风险的关键启动二进制文件，特别是虚拟化基础安全（VBS，脚本输出第二项提及）。
最后，脚本输出显示旧版CA-2011证书尚未吊销。我特意等待微软通过Windows Update（承诺2026年下半年实施）如何处理此事，我们拭目以待……
为何这些脚本重要
厂商很少揭示PC完整的Secure Boot状态，Windows只能显示部分信息。固件UI参差不齐，同一功能往往名不副实。Garlin的脚本让我们了解Secure Boot内部状态，并指示可能需要采取的行动，以完成更新和赶上进度的过程。
Secure Boot无法应用更新时的解决措施
以下是实用的分步骤恢复流程。
步骤1：核实当前状态
使用PowerShell或Garlin的脚本检查：
- PK
- KEK
- DB
- DBX
- 执行状态
- 引导加载程序版本
步骤2：更新固件
安装最新的BIOS/UEFI更新。
步骤3：重置密钥为出厂默认
禁用Secure Boot，设置模式为自定义（Custom），然后重置或安装出厂默认密钥（不同UEFI称呼不同）。此步骤通常能清除不匹配问题。
步骤4：重新启用Secure Boot
确保禁用CSM（UEFI更新后常被自动启用，需关闭才能启用Secure Boot）。
步骤5：应用DBX更新
使用Windows Update或厂商固件包，查看系统/主板厂商支持页面寻找UEFI相关更新。例如，这步对我MSI MAG Tomahawk B550的修复至关重要。
步骤6：重建启动文件（如必要）
可使用内置命令bcdboot C:\Windows /f UEFI重建启动文件。有时需通过修复或救援盘进入Windows恢复环境（WinRE）执行此操作。这种方法更安全，能解决启动问题及Secure Boot策略阻断。
步骤7：复核状态
确认DBX含有CA 2023条目。此时非常适合运行Garlin的Check_UEFI-CA2023.ps1脚本。（注意：右键点击脚本属性窗口，勾选“解除阻止”选项，即可在PowerShell中运行，无需修改执行策略。截图如下）
第三方PowerShell脚本默认被阻止，勾选“解除阻止”即可运行。我认为，Secure Boot生态需要改革
CA 2023的逐步推送及近期令系统符合Secure Boot标准的努力虽然值得关注，但也暴露出诸多系统性问题。其一，固件厂商缺乏统一实现和标准术语，结果IT专业人士和安装人员需费力调试。其二，文档往往欠缺，且未能妥善应对问题修复方案。
目前更新流程脆弱，一次失误（如未先将Secure Boot设为自定义模式再尝试重装默认密钥）就可能导致更新卡住，影响正常启动。我这台ASRock台式机甚至无法正常重启，只能冷启动进入UEFI或完成启动循环，长达两周之久，直到换主板才恢复正常。同时我观察到OEM和主板厂商在Secure Boot实现质量上参差不齐，这期间我用的联想系统（部分2018年起）、戴尔迷你PC和华硕骁龙笔记本均无此类问题。
我从中学到：Secure Boot的强度取决于最薄弱环节。一些设备显然存在弱点，导致普通更新成了斗争，甚至需要换系统或主板等激烈措施。
微软、OEM与用户必须做的事
各方都需采取行动改善Secure Boot当前混乱局面。微软应加强认证标准，提升诊断能力和工具完善度（Garlin脚本虽简单，但已初具指导意义，微软完全有能力开发更完善的官方工具）。
OEM厂商应大力推动固件行为标准化，统一术语，对DB更新进行更全面测试，并在UEFI界面提供更透明更详实的Secure Boot状态和数据信息。自动回滚工具的引入也将帮助撤销错误配置。
用户则要严肃对待安全，及时更新固件，除非安装、配置或更新需要，尽量开启并维护Secure Boot。定期验证Secure Boot数据库的当前与正确性，确保EFI分区健康并保持最新。
当各方共同努力，Secure Boot才能发挥保护系统免遭启动和根级攻击的作用。这至关重要，值得投入。
Secure Boot依然重要，但需改进
Secure Boot依旧是Windows安全模型中的关键防线，但CA 2023事件暴露出生态脆弱、标准不一，亟待现代化。好消息是行业在学习，固件厂商在改进，微软在收紧要求，社区工具亦在弥补空白。然而教训明确：信任不是一劳永逸，必须持续维护、验证并适时修复，Secure Boot亦然。
我的建议是，当遇到Secure Boot问题时，要关注解决所花时间。若半天能搞定尚属可接受；若超时太久，就应考虑替代方案、变通或更换设备。在思考期间可以临时关闭Secure Boot，Windows仍可正常运行。但就像我一样，可能最终选择更换出现故障和卡顿的硬件，而非不断徒劳挣扎。权衡取舍，因人而异！