Windows 11 2023年安全启动更新在部分电脑上失败，暴露出更广泛的固件问题

为实现此目的，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更新和OEM的UEFI更新逐步推送。

Secure Boot为何重要？

Secure Boot旨在阻止rootkit、bootkit及其他预操作系统的恶意软件。如果攻击者能够破坏启动链，他们就能躲避操作系统的检测，长期保持隐蔽和持续存在。他们会不断重返系统，因为这类攻击在操作系统之外独立运行。Secure Boot能够阻止这些行为。

理论上，Secure Boot是一个简洁优雅的解决方案。实际中，其生态系统分散、杂乱、充满边缘情况。

不过，Secure Boot现在比以往任何时候都更加重要且判断明显。一方面，它有效时表现良好。另一方面，一旦出现问题，修复就可能复杂、令人头疼且耗时。

导致CA-2023的Secure Boot漏洞

2023年初，微软宣布存在重大安全隐患，旧版Windows引导管理器二进制文件被攻破，可能被绕过Secure Boot保护。为应对该问题，公司发布了名为CA-2023吊销的DBX更新，将易受攻击的引导加载程序加入禁止名单，同时提供了新的、签名的引导加载程序和匹配的证书，免受此类攻击。

为何必须这样做？

攻击者发现了利用老旧引导加载程序来禁用Secure Boot保护的方法。吊销这些二进制文件对于维护生态系统完整性至关重要。

为何会导致系统出问题？

许多OEM存在：

• 固件过时
• DB/DBX处理不一致
• 更新流程破损
• 非标准的Secure Boot实现
• 密钥集不完整或错误
• 固件静默忽略DBX更新
• 固件在应用DBX更新时使系统变砖

换言之，该吊销揭露了多年的技术债务。很多情况下，只是尝试更新就足以影响PC。最好情况是PC可能无法通过“电源 > 重启”选项执行重启；最糟则可能无法启动，甚至无法进入UEFI。糟糕极了！

CA-2023后的结果

数以百万计系统出现以下情况之一：

• 启用Secure Boot但未实际执行吊销
• 因更新失败而禁用Secure Boot
• 处于“用户模式”且密钥不匹配
• 应用DBX更新后无法启动
• 固件完全拒绝应用CA-2023更新

这并非微软独有的问题，而是整个生态系统的失败。显然，这使得出现相关问题的用户陷入苦恼。就我而言，一台基于ASRock B550 Extreme4和Ryzen 5的PC几乎遭遇了上述所有问题。最终我只能更换主板来解决。

“Secure Boot链”如何工作？

遗憾的是，流程中各步骤都可能出错，这也使得该方案较脆弱，偶尔会卡顿或失败。若出现以下情况可能导致失败：

• 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-2023证书，CA-2011证书可能仍被使用或未被取代。

微星(MSI)

• 部分（非全部）微星主板因以下问题臭名昭著：
• DBX处理不一致
• 固件静默忽略更新
• Secure Boot模式与用户界面标签不符
• 系统意外恢复出厂密钥

华擎(ASRock)

华擎主板常需手动干预，例如：

• 清除密钥
• 恢复出厂默认设置
• 重新注册微软密钥
• 手动应用DBX更新

官方文档匮乏，用户多数摸不着头脑。我自己有两块声称相同的B550 Extreme4主板。一个能通过人工和微软Windows更新获取更新，另一个却始终无法使固件数据库内容与操作系统等待的更新（不仅Windows更新还手动）匹配。实际上，这导致了之前章节提到的“CPU变更”提示连番出现。

戴尔、惠普、联想（及其他OEM）

企业及消费级PC和笔记本厂商（如宏碁、华硕、Dynabook等）表现总体更好，但仍存在：

• 分批推出更新
• BIOS/UEFI更新时间不一致
• 一些系统需要多次重启以应用DBX变更

我浏览微软论坛、TenForums、ElevenForum和TechPowerUp等论坛，发现了成百上千关于Secure Boot问题的求助贴。许多问题来自笔记本，更多来自DIY桌面或精品组装PC，后者用顶级商用配件为高端买家组装定制电脑（详见下一节）。

定制PC

同一厂商主板表现可能因以下因素不同：

• 实际安装的芯片组
• 固件分支版本
• 发布年份
• OEM版本或零售版本

总的来看，缺乏标准化十分明显。用户遇到的Secure Boot问题种类繁多，一些通过Windows更新或手动调整得以解决，另一些顽固地拒绝修复。我个人尝尽各种问题，近期好转，仍有失败。

Secure Boot更新失败时用户该怎么做

Secure Boot可能以各种方式失败。Windows更新可能显示成功，但DBX（吊销列表）未实际变更。固件可能报Secure Boot“已启用”，但未生效（此时PowerShell的confirm-SecureBootUEFI命令会返回false）。

系统可能启动但不合规（后文Garlin脚本环节有更多细节）。引导加载程序可能与DB条目不匹配，更新后系统可能启动困难甚至无法启动（正如我ASRock B550 Extreme4系统所经历）。因此，有许多可能的原因及对应修复方案，下面一一道来。

密钥不匹配（PK/KEK/DB/DBX）

若PK或KEK过期，固件可能拒绝将数据库更新纳入有效凭证（DB）或吊销列表（DBX）。此时可尝试：

• 重置为出厂或默认密钥（UEFI中当Secure Boot处于自定义模式时通常可选）
• 重新注册微软密钥（通常需重新应用微软更新，包含卸载及重装操作，可能使用DISM，Windows更新提供有限时间的回滚）

固件忽略DB或DBX更新

部分PC或笔记本的UEFI只在满足特定条件下才应用DB或DBX更新。可能需要先禁用Secure Boot。通常需关闭兼容支持模块CSM（开启CSM即启用BIOS与UEFI双模式，现代PC通常只支持UEFI，旧机型可能兼容）。有时还需清除Secure Boot密钥（另一选项）才能生效。可能需反复试验，幸运的话能找到其他用户的解决经验。

引导加载程序过时

旧版Windows安装媒体或修复盘可能包含不兼容Secure Boot的老旧引导加载程序。该不匹配在2026年微软深度吊销CA-2011后会愈加明显。DBX可能阻止这些老版引导。解决方法较简单，因为引导加载程序不直接操作固件（UEFI）。可尝试：

• 运行Windows更新，可能自动替换旧引导加载程序
• 使用bcdboot工具重建引导文件
• 确认EFI分区健康，如有损坏则修复或重建

固件缺陷或怪异

特别是旧PC，建议先升级（刷新）UEFI固件再启用Secure Boot。对于非常旧的机型，2023年及以后更新可能根本不存在。针对需多次重启、特定固件版本或手动导入DB/DBX的情况，可以尝试：

• 升级到最新稳定固件版本（仅在别无选择时考虑测试版，避免带来新的不稳定因素）
• 若有，使用厂商提供的更新包或胶囊文件直接应用Secure Boot数据库变更（比如我的微星MAG Tomahawk在刷新包含Secure Boot与CA-2023元素的UEFI后才能正确运行）
• 固件更新后，再执行Windows更新；别先更新软件再升级固件，因为新软件配合旧固件容易出问题，我在ASRock B550 Extreme4机型上就犯过这错误

总之，只要用户按固件更新到Windows更新的顺序逐步进行，并仅在必要时介入手动UEFI操作，便大大降低卡坑风险。

脚本如何帮助解决Secure Boot更新问题

CA-2023推广期间，社区驱动的工具与诊断方法成为亮点。特别是Eleven论坛VIP及高手Garlin发布了超过50页的讨论帖，提供了一套功能强大的PowerShell脚本，并伴随极具帮助的支持和讨论。这些脚本能：

• 枚举Secure Boot密钥
• 验证DB/DBX条目
• 检测不匹配项
• 识别过时引导加载程序
• 确认执行状态
• 生成详细报告

对于很多用户来说，Garlin的脚本是首次清晰洞察固件真实状态的窗口。下面图1展示了我新装配微星MAG Tomahawk B550桌面机上运行脚本Check_UEFI-CA2023.ps1的结果：

仔细看截图，PC安装了CA 2011及CA 2023的密钥交换密钥(KEK)，DB中包含UEFI CA 2011、Windows PCA 2011及三种CA 2023证书。DBX证书列表为空（往下看你会发现CA 2011尚未被吊销，届时相关条目将移至此处）。

EFI文件显示引导管理器允许UEFI CA 2023，注册表亦如此，且应用了最新的Secure Boot代码完整性策略。微软利用该策略阻止虚拟化基础安全（VBS，在脚本整体输出第二条提及）相关的易受攻击或回滚敏感的引导关键二进制文件。

最后，脚本显示较旧的CA-2011证书还未吊销。这是有意为之，我正等待微软通过Windows更新在2026年下半年承诺的吊销操作。让我们拭目以待……

为何这些脚本重要

厂商很少公布PC完整的Secure Boot状态，Windows只显示部分信息。固件用户界面不统一，往往同一事物有不同命名。Garlin的脚本揭示了Secure Boot内部的运行细节，并提示可能需要采取何种措施以完成更新和维护。

Secure Boot无法应用更新时怎么办

以下是实用的逐步恢复流程：

步骤1：验证当前状态

用PowerShell或Garlin脚本检查：

• PK
• KEK
• DB
• DBX
• 执行状态
• 引导加载程序版本

步骤2：更新固件

安装最新BIOS/UEFI更新。

步骤3：重置密钥到出厂默认

禁用Secure Boot，设置模式为自定义，然后重置或安装出厂默认密钥（不同UEFI术语不同）。通常这能解决密钥不匹配问题。

步骤4：重新启用Secure Boot

确保关闭CSM（UEFI更新时往往会开启，必须关闭才能启用Secure Boot）。

步骤5：应用DBX更新

通过Windows更新或厂商胶囊更新应用。查看主板/系统厂商支持页面寻求UEFI及相关更新。这是我微星MAG Tomahawk B550主板问题得以解决的关键。

步骤6：重建引导文件（如有需要）

使用内置命令bcdboot C:\Windows /f UEFI重建启动文件。有时需用修复或救援盘启动Windows恢复环境(WinRE)操作。这是保证启动正常和绕过Secure Boot策略阻断的安全途径。

步骤7：重新验证状态

确认DBX包含CA 2023条目。此时可运行Garlin的Check_UEFI-CA2023.ps1脚本。（提示：如果在文件属性中勾选解除阻止（Unblock）选项，可直接在PowerShell执行脚本，无需更改执行策略。见下图）

我认为Secure Boot生态需要改革

CA 2023的逐步推广和近期赶上符合Secure Boot规范的努力虽有意义，但也暴露了众多系统性问题。一是固件厂商缺乏统一实现和命名标准，导致IT专业人员和安装者必须辛苦将各家拼凑起来。更糟糕的是，文档常缺乏针对故障的应对方案。

当前更新流程脆弱，一旦做错（如未先将Secure Boot切换到自定义模式就尝试重新安装默认密钥），容易导致过程卡死，影响正常启动。我一台ASRock桌面机两周内都无法正常重启，只能彻底断电冷启动进入UEFI或完成启动流程。同期，我Lenovo多台旧系统、Dell迷你机以及华硕骁龙笔记本均无此类问题。

这让我意识到，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依然能运行。但你也许像我一样，最终决定更换问题硬件，而非无休止地战斗且无确定结果。这由你决断！