Microsoft 轮换 Windows Secure Boot 密钥用 Fleet 排查设备群的到期风险与修复方案【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet2011 年微软签发给所有 Windows PC 的三张 Secure Boot 根证书将在 2026 年 6 月起陆续到期。设备不会因此无法开机但会悄悄失去接收新签名启动组件、dbx 吊销列表与 Defender 反启动套件更新的能力。本文基于 Fleet 设备管理平台的自定义 osquery 扩展secureboot_cert_update讲清楚哪些证书在到期、微软如何分批滚动更新、哪些设备会永久卡住以及如何用一条分组查询看清整个设备群的现状再通过 Intune、注册表或 CSP 配置描述文件把更新推下去。为什么这件事会悄悄发生按微软的官方口径受影响的设备在证书到期后一切照常系统正常启动、Windows 仍能安装绝大多数更新日常应用、联网、浏览体验没有任何变化因此管理员几乎不会收到任何警报。真正失去的是接收新签名更新的能力新的签名启动更新boot updates新版启动管理器boot manager针对易受攻击启动组件的dbx 吊销列表新的Defender 反启动套件anti-bootkit列表。这些能力是 Secure Boot 信任链的内容供给。链条断掉后安全缺口会随着时间推移在后台不断加大而设备端没有明显的报错可看。这正是它需要管理员主动排查、而不是等警报的原因。什么在到期2011 证书家族与 2023 替换家族Secure Boot 在 Windows PC 上的信任链由三张微软约在 2011 年签发的证书锚定它们各自负责链条中的一段签名职责到期时间也不尽相同证书职责到期时间Microsoft Corporation KEK CA 2011密钥交换密钥KEK负责对固件允许签名库db与吊销签名库dbx的更新签名2026 年 6 月 24 日Microsoft Corporation UEFI CA 2011为第三方 UEFI 组件签名包括 Linux 的 shim 引导程序2026 年 6 月 27 日Windows Production PCA 2011为 Windows 启动管理器本身签名2026 年 10 月 19 日替换它们的是一个全新的2023 证书家族KEK CA 2023、Windows UEFI CA 2023 与 Microsoft UEFI CA 2023。微软自2026 年 1 月 13 日的累积更新开始通过 Windows Update 向设备推送这批新证书。滚动更新机制为什么大量设备会原地等待微软并没有为所有设备同时开启轮换。理解这一点是判断设备没动静到底是正常还是异常的前提每台设备向 Windows Update 遥测上报一个BucketId——由其固件与硬件身份哈希得到的桶标识当某个桶中足够多的设备已经干净地完成更新该桶内所有匹配设备会被提升为高置信度并自动收到更新在此之前设备会无限期停留在Confidence: Under Observation - More Data Needed观察中 - 需要更多数据状态没有错误、没有进度、也没有任何明显信号告诉你有更新在等。对主流硬件而言桶通常很快被提升但对小众或廉价硬件这个等待可能非常漫长。也就是说大批设备处于悬空状态是正常现象但不代表它们会自行前进。三种会永久卡死的失败模式除了等待之外还有三类问题会让设备在滚动中彻底卡住自动流程无法自行解决管理员必须逐一识别Secure Boot 被关闭滚动更新无法在 Secure Boot 关闭的设备上运行。除非管理员在 UEFI 固件中重新开启 Secure Boot否则设备不会产生任何进展。OEM 从未提供 PK 签名的 KEK 更新部分固件厂商没有在固件中预留 Windows 写入新 KEK 2023 所需的插槽。设备会抛出Event 1803然后等待一个可能永远不会到来的 OEM 固件更新。已知固件问题阻断更新微软会以KI_数字代码标识这类问题并在受影响固件版本上阻断推送。设备会抛出Event 1802。对托管设备群而言以上任何一种都不会自行恢复。你需要把它们找出来、数出来然后决定是应用手动覆盖manual override还是去找 OEM 要固件。在 Fleet 中落地secureboot_cert_update扩展把这一切搬进 Fleet 的途径是一个自定义 osquery 扩展secureboot_cert_update。它每台设备产出一行数据其中的派生状态字段state替你完成了大部分分类工作。扩展表结构扩展的核心列如下完整 schema 见扩展仓库 READMEstate -- Updated, InProgress, RebootPending, -- WaitingOnRollout, SecureBootDisabled, -- BlockedOEMMissingKEK, BlockedKnownIssue, -- BlockedFirmwareError, ServicingBroken, -- OptedOut, Unknown state_reason -- Short human-readable explanation needs_action -- 1 if an admin should look at this device action -- none, wait, reboot, enable_secure_boot, -- apply_manual_override, oem_firmware_required, -- investigate days_until_cert_expiry其中几个字段值得单独说明state由扩展根据底层信号派生出的设备当前阶段从Updated已完成到WaitingOnRollout等待滚动再到各种Blocked*与OptedOut是排查的第一筛选维度needs_action布尔标记为1表示管理员应当处理这台设备是后续 triage 查询的过滤条件action与状态配套的建议动作包括reboot重启、enable_secure_boot开启安全启动、apply_manual_override应用手动覆盖、oem_firmware_required需要 OEM 固件等days_until_cert_expiry距证书到期的剩余天数可用来评估紧迫性。在派生状态之下扩展还保留了原始信号列包括uefica2023_status、available_updates、bucket_id、confidence、known_issue_id等。当派生状态不足以说明问题时可以直接用这些原始字段做取证forensics级的下钻。扩展是如何被 Fleet 加载的Orbit 的自动加载机制扩展能被查询依赖 Fleet 代理Orbit把扩展二进制交给 osquery 加载。在 orbit/cmd/orbit/orbit.go 中可以看到这条加载链Orbit 在启动时检查其根目录root-dir下的extensions.load文件若文件存在且大小大于 0则向 osquery 追加--extensions_autoload extensions.load 路径标志若文件为空扩展被卸载的场景或不存在则静默跳过仅记录 debug 日志。也就是说部署扩展的落地动作本质上是把扩展二进制放到指定路径并把该路径追加进extensions.load然后重启 Orbit。Fleet 官方有一篇完整的系列指南讲解如何把扩展打包成安装包并配合 post-install 脚本自动完成这三步见 Deploying custom osquery extensions in Fleet 与配套的 step-by-step 指南。该指南覆盖 macOS / Windows / Linux 三种平台的打包方式其中 Windows 使用 WiX 工具集生成 MSI并在 post-install 脚本中将扩展路径写入C:\Program Files\Orbit\extensions.load后重启Fleet osquery服务。值得先跑的几条查询第一条设备群健康总览。SELECT state, COUNT(*) AS hosts FROM secureboot_cert_update GROUP BY state ORDER BY hosts DESC;一条分组查询即可看到全局。多数环境下你会得到一大块Updated一条很长的WaitingOnRollout尾巴以及一小批needs_action 1的状态。第二条针对需要处理的设备做 triage。SELECT hostname, state, state_reason, action, oem_manufacturer_name, oem_model_number, firmware_version FROM secureboot_cert_update WHERE needs_action 1 ORDER BY state, oem_manufacturer_name;这条查询按状态和 OEM 厂商排序把需要动手的设备一次列全同时给出厂商、型号与固件版本便于分桶处理。关于桶的实用技巧一个bucket_id背后往往跟着几十台硬件相同的设备它们会一起移动。先在桶内一台设备上验证手动覆盖manual override有效再向整个桶推广可以显著降低批量操作风险。怎么修三种推送方式对比微软提供了多种处理升级的方式从最省事到最可控依次是1. Microsoft Intune启用 Secure Boot 证书更新设置通过 Intune 的Enable Secure Boot Certificate Updates设置即可下发该设置还附带若干附加选项对应注册表中的其他策略值。这是无需接触设备、由现有 MDM 通道完成的做法。2. 直接改注册表在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot下将AvailableUpdatesDWORD 设置为0x5944十进制 22852然后观察UEFICA2023Status与UEFICA2023Error确认设备开始推进。这两项状态在扩展表中也会同步暴露因此可以在 Fleet 里统一观察而不是逐台去读注册表。3. CSP 配置描述文件推荐对托管设备群来说最干净的方式是 CSP。Fleet 仓库中就内置了一个可直接使用的示例描述文件docs/solutions/windows/configuration-profiles/secureboot-update.xml内容如下Replace Item Meta Format xmlnssyncml:metinfint/Format /Meta Target LocURI./Device/Vendor/MSFT/Policy/Config/SecureBoot/EnableSecurebootCertificateUpdates/LocURI /Target Data22852/Data /Item /Replace这个描述文件做了三件事值得逐层拆解目标 URI./Device/Vendor/MSFT/Policy/Config/SecureBoot/EnableSecurebootCertificateUpdates即 Windows 设备策略 CSPConfiguration Service Provider中的 SecureBoot 节点——所有配置都以设备为作用域下发数值 22852正是0x5944的十进制形式写入后落在注册表的AvailableUpdatesPolicy键上执行链路下一次Microsoft\Windows\PI\Secure-Boot-Update计划任务运行大约每 12 小时一次时Windows 会把策略值复制到活动的AvailableUpdates然后按阶段依次应用更新。也就是说CSP 方案把改注册表这件手工操作变成了可集中管理、可审计、可回滚的配置下发且与 Intune 走同一套 MDM 通道是托管设备群的最优解。部署节奏建议如果此前从未关注过 Secure Boot 证书到期问题现在正是动手的时机。建议按以下顺序推进先部署扩展按 Deploying custom osquery extensions in Fleet 系列指南将secureboot_cert_update打包并部署到设备群。若希望检测缺失即自动安装可以用一条查询检查扩展二进制或扩展注册名是否已存在然后通过 Fleet 的策略自动化绑定软件安装让缺失的宿主自动补齐跑健康总览执行上面的分组查询先看全局状态分布数清Blocked*与OptedOut的数量按桶分批处理从needs_action 1的设备开始先在一台设备上验证手动覆盖或 OEM 固件方案再推广到整个bucket_id。顺带一提Secure Boot 状态本身也是合规基线的一部分Fleet 仓库的 CIS 基线查询集中就包含与 Secure Boot 相关的策略例如 Win 11 CIS - Allow Secure Boot for integrity validation要求为 BitLocker 系统盘启用 Secure Boot 作为平台完整性提供者以及虚拟化安全VBS平台安全级别策略。在排查证书轮换的同时这些基线查询可以作为 Secure Boot 整体健康度的补充视图。结语证书轮换是分批、静默、且存在多种卡死路径的过程靠人工逐台读注册表和事件日志根本追不上。把secureboot_cert_update扩展部署进 Fleet 之后你可以用一条GROUP BY state的查询在几分钟内看清整个设备群的位置哪些已完成、哪些还在等桶、哪些需要开机、哪些需要找 OEM再配合仓库自带的 CSP 描述文件把更新推下去。现在排查总比六月到期后手忙脚乱要稳妥。【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考