安全启动证书更新：面向 IT 专业人员和组织的指导

安全启动证书过期

证书颁发机构 (CA) 的配置（也称为证书），由 Microsoft 作为安全启动基础结构的一部分提供，自Windows 8和Windows Server 2012以来一直保持不变。 这些证书存储在签名数据库 (DB) 和密钥交换密钥 (KEK) 固件变量中。 Microsoft在原始设备制造商 (OEM) 生态系统中提供了相同的三个证书，以包含在设备的固件中。 这些证书支持 Windows 中的安全启动，也供第三方作系统 (OS) 使用。 以下证书由 Microsoft 提供：

• Microsoft Corporation KEK CA 2011

• Microsoft Windows 生产 PCA 2011

• Microsoft Corporation UEFI CA 2011

有何变化？

当前Microsoft安全启动证书 (Microsoft Corporation KEK CA 2011、Microsoft Windows Production PCA 2011、Microsoft Corporation UEFI CA 2011) 将于 2026 年 6 月开始过期，并将于 2026 年 10 月到期。 

将推出新的 2023 证书，以保持安全启动的安全性和连续性。 设备必须在 2011 证书过期之前更新到 2023 证书，否则它们将不符合安全要求并面临风险。  

自 2012 年以来制造的 Windows 设备可能具有过期的证书版本，这些版本必须更新。 

术语

证书

验证整个队列中的安全启动状态：是否已启用安全启动？ 

自 2012 年以来制造的大多数设备都支持安全启动，并且随附启用了安全启动。 若要验证设备是否已启用安全启动，请执行下列作之一： 

• GUI 方法： 转到“开始> 设置”> 隐私 & 安全 > Windows 安全中心 > 设备安全性”。 在“设备安全性”下，“安全启动”部分应指示“安全启动”处于打开状态。

• 命令行方法： 在 PowerShell 中提升的命令提示符下，键入 Confirm-SecureBootUEFI，然后按 Enter。 命令应返回 True，指示安全启动处于打开状态。

在设备群的大规模部署中，IT 专业人员使用的管理软件需要为安全启动启用提供检查。 

例如，在Microsoft Intune托管设备上检查安全启动状态的方法是创建和部署Intune自定义符合性脚本。 Microsoft Intune使用适用于 Linux 和 Windows 设备的自定义符合性设置中介绍了Intune符合性设置。  

如果未启用安全启动，则可以跳过下面的更新步骤，因为它们不适用。

如何部署更新

有多种方法可针对设备进行安全启动证书更新。 部署详细信息（包括设置和事件）将在本文档的后面部分讨论。 当你以设备为目标进行更新时，会在设备上进行设置，以指示设备应开始应用新证书的过程。 计划任务每 12 小时在设备上运行一次，并检测到设备已针对更新。 任务用途的概述如下：

1. Windows UEFI CA 2023 应用于数据库。

2. 如果设备在 DB 中具有 Microsoft Corporation UEFI CA 2011，则任务会将Microsoft选项 ROM UEFI CA 2023 和 Microsoft UEFI CA 2023 应用于数据库。

3. 然后，该任务将添加 Microsoft Corporation KEK 2K CA 2023。

4. 最后，计划任务将 Windows 启动管理器更新为 Windows UEFI CA 2023 签名的启动管理器。 Windows 将检测到需要重启，然后才能应用启动管理器。 启动管理器更新将延迟，直到重启自然发生 (例如，当每月更新) 应用时，Windows 将再次尝试应用启动管理器更新。

在计划任务移动到下一步之前，必须成功完成上述每个步骤。 在此过程中，可以使用事件日志和其他状态来帮助监视部署。 下面提供了有关监视和事件日志的更多详细信息。  

通过更新安全启动证书，可以将来更新到 2023 启动管理器，这更加安全。 启动管理器上的特定更新将在将来的版本中提供。

部署步骤 

• 准备：清单和测试设备。

• 固件注意事项

• 监视：验证监视工作并基线你的车队。

• 部署：以更新为目标设备，从小子集开始，并根据成功的测试进行扩展。

• 修正：使用日志和供应商支持调查并解决任何问题。

准备 

清点硬件和固件。 基于系统制造商、系统型号、BIOS 版本/日期、BaseBoard 产品版本等生成具有代表性的设备示例，并在广泛部署之前在这些设备上测试更新。  这些参数在系统信息 (MSINFO32) 中通常可用。 使用包含的示例 PowerShell 命令检查安全启动更新状态，并清点整个组织中的设备。

注意：如果启用了安全启动状态，则这些命令适用。 

注意：其中许多命令都需要管理员权限才能工作。

安全启动清单数据收集脚本示例

复制并粘贴此示例脚本，并根据需要修改环境：示例安全启动清单数据收集脚本。

如果启用了安全启动，则第一步是检查是否存在最近更新或正在更新安全启动证书的挂起事件。 特别感兴趣的是1801年和1808年的最新事件。 

安全启动 DB 和 DBX 变量更新事件中详细介绍了这些事件。 另请检查监视和部署部分，了解事件如何显示挂起的更新状态。  

以下示例 PowerShell 命令可以捕获挂起事件 1801 和 1808 的最新状态： 

下一步是清点整个组织中的设备。 使用 PowerShell 命令收集以下详细信息，以生成具有代表性的示例： 

固件注意事项

将新的安全启动证书部署到设备群要求设备固件在完成更新时发挥作用。 虽然Microsoft预期大多数设备固件将按预期执行，但部署新证书之前需要仔细测试。

检查硬件清单，并根据以下唯一条件生成具有代表性的小型设备示例，例如： 

• Manufacturer

• 型号

• 固件版本

• OEM 基板版本等

在广泛部署到设备群中的设备之前，建议在制造商、型号、固件版本) 等因素定义 (代表性示例设备上测试证书更新，以确保成功处理更新。 针对每个唯一类别测试的示例设备数的建议指导为 4 个或更多。

这有助于在部署过程中建立信心，并有助于避免对更广泛的机群产生意外影响。 

在某些情况下，可能需要更新固件才能成功更新安全启动证书。 在这些情况下，我们建议与设备 OEM 联系，以查看更新的固件是否可用。

虚拟化环境中的 Windows

对于在虚拟环境中运行的 Windows，有两种方法可用于将新证书添加到安全启动固件变量：  

• 虚拟环境的创建者 (AWS、Azure、Hyper-V、VMware 等 ) 可以提供环境的更新，并在虚拟化固件中包含新证书。 这将适用于新的虚拟化设备。

• 对于在 VM 中长期运行的 Windows，如果虚拟化固件支持安全启动更新，则可以像任何其他设备一样通过 Windows 应用更新。

监视和部署 

我们建议在部署之前开始设备监视，以确保监视正常工作，并且你提前了解了队列的状态。 下面讨论了监视选项。 

Microsoft提供多种方法来部署和监视安全启动证书更新。

自动部署帮助 

Microsoft提供两种部署帮助。 这些辅助功能在帮助将新证书部署到队列时可能很有用。 这两种辅助都需要诊断数据。

• 使用置信度存储桶进行累积更新的选项： Microsoft可能会根据迄今为止共享的诊断数据自动在每月更新中包含高置信度设备组，使无法共享诊断数据的系统和组织受益。 此步骤不需要启用诊断数据。

  • 对于可以共享诊断数据的组织和系统，它使Microsoft设备能够成功部署证书的可见性和信心。 有关启用诊断数据的详细信息，请参阅： 在组织中配置 Windows 诊断数据。 我们将为每个唯一设备 (创建“存储桶”，这些设备由制造商、主板版本、固件制造商、固件版本和其他) 数据点等属性定义。 对于每个存储桶，我们正在监视多个设备的成功证据。 看到足够成功的更新且没有失败后，我们会将存储桶视为“高置信度”，并将这些数据包含在每月累积更新中。 当每月更新应用于高置信度存储桶中的设备时，Windows 会自动将证书应用于固件中的 UEFI 安全启动变量。

  • 高置信度存储桶包括正确处理更新的设备。 当然，并非所有设备都会提供诊断数据，这可能会限制Microsoft设备正确处理更新的能力的信心。

  • 默认情况下，对于高置信度设备启用此辅助功能，可以使用特定于设备的设置禁用。 将来的 Windows 版本中将共享详细信息。

• 受控功能推出 (CFR) ：  如果启用了诊断数据，请选择设备进行Microsoft托管部署。

  • 受控功能推出 (CFR) 可用于组织队列中的客户端设备。 这要求设备向Microsoft发送所需的诊断数据，并发出设备选择加入以允许设备上的 CFR 的信号。 下面介绍了有关如何选择加入的详细信息。

  • Microsoft将在诊断数据可用且设备参与受控功能推出 (CFR) 的 Windows 设备上管理这些新证书的更新过程。 虽然 CFR 可能有助于部署新证书，但组织将无法依赖 CFR 来修正其队列 ， 它需要遵循本文档关于 自动协助未涵盖的部署方法部分中概述的步骤。

  • 局限性： CFR 可能在你的环境中不起作用有几个原因。 例如：

    • 没有可用的诊断数据，或者诊断数据不能作为 CFR 部署的一部分使用。

    • 设备不在受支持的客户端版本的 Windows 11 上，并且Windows 10具有扩展安全更新 (ESU) 。

自动助手未涵盖的部署方法

选择适合你的环境的方法。 避免在同一设备上混合使用方法： 

• 注册表项：控制部署和监视结果。
  有多个注册表项可用于控制证书部署的行为和监视结果。 此外，还有两个选择加入和退出上述部署帮助的关键。 有关注册表项的详细信息，请参阅用于安全启动的注册表项汇报 - 具有 IT 托管更新的 Windows 设备。

• 组策略 对象 (GPO) ：管理设置;通过注册表和事件日志进行监视。
  Microsoft将在将来的更新中使用 组策略 支持管理安全启动更新。 请注意，由于组策略用于设置，因此需要使用其他方法（包括监视注册表项和事件日志条目）监视设备状态。

• WinCS (Windows 配置系统) CLI：对已加入域的客户端使用命令行工具。
  域管理员也可以使用 Windows OS 更新中包含的 Windows 配置系统 (WinCS) 跨已加入域的 Windows 客户端和服务器部署安全启动更新。 它包含一系列命令行实用工具， (传统可执行文件和 PowerShell 模块，) 查询安全启动配置并将其应用于本地计算机。 有关详细信息，请参阅适用于安全启动的 Windows 配置系统 (WinCS) API。

• Microsoft Intune/Configuration Manager： 部署 PowerShell 脚本。 将来的更新中将提供配置服务提供程序 (CSP) ，以允许使用 Intune 进行部署。

监视事件日志

提供了两个新事件来帮助部署安全启动证书更新。 安全启动 DB 和 DBX 变量更新事件中详细介绍了这些事件： 

• 事件 ID：1801
  此事件是一个错误事件，指示更新的证书尚未应用于设备。 此事件提供一些特定于设备的详细信息，包括设备属性，这将有助于关联仍需要更新的设备。

• 事件 ID：1808
  此事件是一个信息性事件，指示设备已将所需的新安全启动证书应用于设备的固件。

部署策略 

若要将风险降到最低，请分阶段部署安全启动更新，而不是一次性部署所有更新。 从一小部分设备开始，验证结果，然后扩展到其他组。 我们建议你从设备的子集开始，并在你对这些部署充满信心时，添加其他设备子集。 可以使用多个因素来确定子集的内容，包括示例设备和组织结构上的测试结果等。 

由你决定部署哪些设备。 此处列出了一些可能的策略。 

• 大型设备群： 首先依赖于上面所述的辅助功能，用于你管理的最常见设备。 同时，关注组织管理的不太常见的设备。 测试小型示例设备，如果测试成功，则部署到相同类型的其余设备。 如果测试产生问题，请调查问题的原因并确定修正步骤。 你可能还希望考虑在机群中具有更高价值的设备类，并开始测试和部署，以确保这些设备已尽早更新保护。

• 小机队，品种繁多： 如果你管理的机群包含大量计算机，其中测试单个设备是令人禁忌的，请考虑严重依赖上述两种辅助功能，尤其是对于可能成为市场上常见设备的设备。 最初专注于对日常作至关重要的设备，然后进行测试，然后进行部署。 继续向下移动高优先级设备列表，在监视车队的同时进行测试和部署，以确认辅助正在帮助其余设备。

注意 

• 请注意较旧的设备，尤其是制造商不再支持的设备。 虽然固件应正确执行更新作，但有些可能不执行。 如果固件无法正常工作，并且设备不再受支持，请考虑更换设备以确保整个队列的安全启动保护。

• 过去 1-2 年制造的新设备可能已经安装了更新的证书，但可能没有将 Windows UEFI CA 2023 签名的启动管理器应用于系统。 应用此启动管理器是部署每个设备的关键最后一步。

• 选择设备进行更新后，可能需要一段时间才能完成更新。 估计 48 小时，以及要应用的证书的一个或多个重启时间。

常见问题和建议

本指南详细介绍了安全启动证书更新过程的工作原理，并提供了一些步骤来排查在部署到设备期间遇到的问题。 将根据需要添加此部分的汇报。

安全启动证书部署支持 

为了支持安全启动证书更新，Windows 维护每 12 小时运行一次的计划任务。 任务在 AvailableUpdates 注册表项中查找需要处理的位。 下表显示了部署证书时使用的内容。 “顺序”列指示位的处理顺序。

每个位都按上表中给出的顺序由计划事件处理。

通过位的进度应如下所示： 

1. 开始：0x5944

2. 0x0040 → 0x5904 (已成功应用 Windows UEFI CA 2023)

3. 0x0800 → 0x5104 (根据需要应用了 Microsoft 选项 ROM UEFI CA 2023)

4. 0x1000 → 0x4104 (根据需要应用了 Microsoft UEFI CA 2023)

5. 0x0004 → 0x4100 (应用Microsoft公司 KEK 2K CA 2023)

6. 0x0100 → 0x4000 (应用 Windows UEFI CA 2023 签名启动管理器)

注意

• 与 位关联的作成功完成后，将从 AvailableUpdates 键中清除该位。

• 如果其中一个作失败，则会记录事件，并在下次运行计划的任务时重试该作。

• 如果设置了位0x4000，则不会清除。 处理所有其他位后，AvailableUpdates 注册表项将设置为 0x4000。

问题 1：KEK 更新失败：设备将证书更新到安全启动 DB，但在将新的密钥 Exchange 密钥证书部署到安全启动 KEK 后没有进展。 

注意 当前发生此问题时，将记录 事件 ID： 1796 ， (请参阅安全启动 DB 和 DBX 变量更新事件) 。 稍后的版本中将提供一个新事件来指示此特定问题。 

设备上的 AvailableUpdates 注册表项设置为0x4104并且不会清除0x0004位，即使在多次重新启动且经过大量时间之后也是如此。 

问题可能在于设备没有由 OEM 的 PK 签名的 KEK。 OEM 控制设备的 PK，并负责对新的Microsoft KEK 证书进行签名，并将其返回到Microsoft，以便将其包含在每月累积更新中。 

如果遇到此错误，检查与 OEM 联系，以确认他们已按照 Windows 安全启动密钥创建和管理指南中所述的步骤进行作。  

问题 2：固件错误：应用证书更新时，证书将传递给固件，以应用于安全启动 DB 或 KEK 变量。 在某些情况下，固件将返回错误。 

发生此问题时，安全启动将记录 事件 ID：1795。 有关此事件的信息，请参阅 安全启动 DB 和 DBX 变量更新事件。 

建议与 OEM 联系，查看是否有固件更新可用于设备解决此问题。