Tianjin RARESOFT TECHNOLOGY

IT新闻

聚合微软、Windows、企业 IT、云服务与 AI 应用等方向的最新动态,帮助企业及时了解平台变化、功能更新与潜在风险。

微软回应Windows 11安全启动截止日期临近须知事项

2026.06.08
Microsoft answers your questions as Secure Boot is set to expire any dayMicrosoft answers your questions as Secure Boot is set to expire any day

随着原始微软Secure Boot KEK证书将于2026年6月24日到期,微软于6月4日举办了第二次直播“问微软任何问题”环节,解答IT管理员和企业客户持续涌入的大量疑问。

讨论小组成员包括Arden White(Windows维护与交付首席安全工程师)、Kevin Sullivan(Windows生态系统及商业参与负责人)、Richard Powell(工程团队)、Scott Shell(企业与安全,Secure Boot架构与设计)、及来自Intune产品组的Jason Sandys。

Windows 11 now shows Secure Boot certificate status in the Windows Security app with clear alerts

如果你错过了第一次AMA的报道,微软已透露如果忽视Secure Boot截止日期,Windows 11 PC会发生什么。这次会议深入探讨了第一次未解答的具体问题,尤其是围绕企业部署、虚拟机、PXE启动场景、暂时暂停设备组以及IT管理员在接下来的几天内应采取的措施。

以下是我们详细整理的微软Secure Boot AMA环节全部内容。

6月24日不是Secure Boot的硬停止,但当天变化至关重要

最紧迫的问题是,6月24日微软公司KEK CA 2011证书到期日,是否为注册表手动部署方法停止工作的硬性截止日期。Scott Shell的回答是否定的。

When is Secure Boot Certificate expiring

6月24日特指KEK密钥的过期时间。DB密钥是另一个证书,直到10月才过期。更关键的是,所有已签名的更新包,包括DB更新、注册表项和计划任务机制,将继续如以前一样工作。Shell确认“注册表项和更新没有终止日期。”

6月24日后的变化是微软无法签署新的DBX更新,这种更新用于撤销列入黑名单的受损或恶意引导加载程序。如果设备没有安装新的KEK,它可能会错过未来的某些撤销更新,这意味着随着微软发现并修复新的引导程序漏洞,设备安全性会逐渐降低,但在25日不会突然无法启动。

DB密钥直到10月才过期,微软预计在此期间会用该密钥签署更多启动管理程序。

6月更新将使绝大多数主流设备达到高信心等级

会议中令人鼓舞的一点是6月补丁星期二更新对设备覆盖率的影响。团队确认,更新后微软拥有诊断数据的绝大多数系统将被归为高信心等级。不是全部,但大部分。

Certificate Deployment via Controlled Feature Rollout

Kevin Sullivan补充道,微软所说的设备分组并非仅按制造商和型号分类,信心评估深入到固件版本和固件日期。因此,外观相同的主流PC如果固件版本不同,可能会被划分到不同分组,这意味着IT管理员不能假设某型号中的一个设备是高信心,则该型号所有设备都是。

中旬更新的Intune监控报告是了解设备状态的推荐工具。Intune团队的Jason指出报告会显示设备是否属于高信心分组,是否已应用更新,以及哪些设备仍需手动干预。报告及配套PowerShell修复脚本均可用,二者通过不同途径完成相同任务。

“暂时暂停”在Secure Boot中的含义及对应处理方法

不少企业客户反映设备卡在“暂时暂停”组中,临近截止日期让人担忧。团队解释这状态通常指设备需要OEM固件更新。

其机制是微软部署系统有时检测到固件层的兼容性问题,应用证书存在风险。为避免失败,系统暂停部署。OEM需发布固件更新解决问题。更新固件后,设备将进入新分组,因为固件版本变更,新组合拥有自己的分类。

Scott Shell强调,追踪此情况要注意:设备更新固件后进入新分组,旧分组不会改变。查看上月导出的表格查旧分组是否转移会错误判断。旧分组因该固件版本而保持暂停状态。设备只是移至可能正被监控或处于高信心的新组。只有查看Intune实时数据或GitHub CSV报告才能准确反映设备现状。

aka.ms/GetSecureBoot页面列出了大多数主要厂商的OEM固件支持页面,建议先查这类页面,再对暂停设备尝试手动覆盖操作。

背景是,今年早些时候Windows Latest报道部分PC因固件不兼容而导致2023年Secure Boot更新失败,问题比预期更广泛。随后OEM承认,为赶Secure Boot截止日期匆忙发布的固件导致Windows 11设备出现BitLocker循环和蓝屏死机,造成系统损坏。这正是微软分阶段部署设立的原因,暂时暂停状态是警告,不能在未固件更新前强制执行。

已经自行部署的不要等到高信心

本次会议中针对等待设备达到高信心等级而推迟手动部署的管理员们,一条最明确的建议是不要再等了。

Secure Boot deployment

设备处于高信心组,Intune会自动处理,无需管理员操作。但对于非高信心设备,如白牌机、不常见OEM配置、老旧服务器或微软遥测数据有限的设备,建议通过注册表值或对应Intune设置目录策略强制执行更新。

团队描述的Intune环境工作流程是:拉取监控报告,识别尚未应用更新的设备,挑选每种型号或固件版本的代表设备,推送策略,确认状态成功后扩大部署。Scott Shell建议优先选择处于激活和可访问状态的设备,避免选择远程员工使用难以联系的机器,也不要选择可能断电一周无遥测回传的设备。

Intune的Jason Sandys提到,“如果微软已经将设备放入高信心数据库,就由系统处理。但存在个别白牌机及其他无遥测的情况,需要你手动强制更新。”

Intune overview of Secure Boot status

微软也鼓励管理员注意,在非高信心数据库设备上手动部署有助于微软收集成功更新的遥测,回馈信心系统,帮助其他拥有相同罕见设备的组织。

关闭Secure Boot?你无法更新证书,且以后开启风险大

有人管理Azure虚拟桌面、Azure虚拟机及Intune终端,询问Secure Boot关闭的设备会怎样。Scott Shell给出明确答复。

当Secure Boot被禁用时,微软无法更新证书。固件不允许,操作系统层面微软也无能为力。这些设备已固有易受Secure Boot旨在防范的攻击类别影响,证书过期不会改变这一点。

更棘手的问题是后续开启Secure Boot会怎样。Shell解释称,设备Secure Boot关闭时,微软仍会将启动管理器更新到2023年签署版本,可正常运行。但在UEFI中启用Secure Boot时,Secure Boot所执行的证书集必须与启动管理器签名一致。如果固件信任数据库只含2011证书,而安装的启动管理器签署为2023证书,设备将无法启动。

Secure Boot certificates status monitor

为恢复启动,须手动将2023证书安装入固件,具体文档见aka.ms/GetSecureBoot。Shell建议计划首次启用或重新启用Secure Boot者先仔细测试,因为失败结果是设备无法启动,需现场操作修复。

对启用了安全启动或可信启动的Azure第二代虚拟机,微软已默认更新至2023证书集,默认状态更佳。一代虚拟机为BIOS时代设备,完全不支持Secure Boot。

是什么决定设备能进入高信心Secure Boot证书组

有人问为什么旧型号比据称主流的新型号更快获得高信心等级。解释反直觉但合理,理解信心系统运作后即可明白。

Secure Boot certificate status in Windows 11

旧型号设备数量较少。少量设备池更容易快速达到高信心所需的统计要求。新型号设备数量庞大,部署广泛,微软需要足够多成功更新的遥测数据,才能有统计信心确认部署在该型号所有固件版本中安全可靠,因此耗时更久。

好消息是,6月更新预计将大幅扩大多个常见新型号的高信心组。团队相信六月补丁星期二发布后会显著增加设备数量。

PXE启动环境需要谨慎排序

会议中技术较精确的问题之一来自管理PXE启动基础设施的人士。问题是,对于仅含2011证书的机器,只要此证书未被列入DBX撤销列表,PXE启动是否仍然可用?

Scott Shell称之为“完美问题”。回答是肯定的。只要2011证书未在DBX中,只有2011证书的设备将继续启动由该证书签名的PXE镜像。证书截止日期不影响对已签名内容的信任度,关键是签名时间戳。

PXE环境的实际建议是,在环境中所有需PXE启动的设备都已具备2023证书前,不要将PXE启动加载程序更新为2023签名版本。若先更新了加载程序,仍仅信任2011证书的设备将无法从PXE启动。

Kevin Sullivan提醒注意,新设备已开始由部分OEM仅预装2023证书,没有两套证书。这些设备无法启动仅含2011签名的PXE介质。若你用旧版PXE启动加载程序为新硬件镜像,可能已经遇到此问题。过渡时期内,准备两根U盘,分别签名为2011和2023,可能是最务实的做法。

Windows 10及更旧系统使用相同更新机制

有人问ESU支持的Windows 10与Windows 11的Secure Boot更新行为是否有差异。答案是否定的。处理证书更新的底层代码在两者中完全相同。运行于Windows 11的同一任务也运行于Windows 10,甚至Windows Server 2012及2012 R2。

老旧服务器的唯一变化是,许多服务器默认未启用Secure Boot,或使用不报告遥测数据的配置。这意味着它们较少被归类为高信心组,不是因为操作系统差异,而是微软可用数据有限。针对这些设备,推荐使用手动注册表键配置路径。

事件日志与注册表键是最佳诊断工具

会议期间,团队多次强调事件日志条目是了解特定设备状态的最可靠方式。相关事件源为TPM-WMI事件日志,应关注编号如下:

  • 1801表明设备正在被追踪,更新所需,但需要更多数据。
  • 1802指示固件层面具体问题,通常是设备处于暂时暂停状态的原因。
  • 1803表示因无PK签名的KEK负载而应用KEK失败。

对于平台密钥被设为无效或未签名值的虚拟机,1803事件可以帮助识别KEK无法更新,需与虚拟机管理程序供应商合作修正PK配置后再试。

如果仅KEK更新失败,但2023年的DB证书已存在,设备仍可处于可接受状态。团队建议确认KEK和DB证书均为2023版本。如果2023年DB证书有效,设备仍安全运行,但直到KEK更新后,才会接收未来的DBX撤销更新。

关于会议中提到的所有内容,微软中心资源为aka.ms/GetSecureBoot,包含完整说明、诊断脚本、OEM固件链接,以及面向家庭用户和企业IT的详细文档。Secure Boot的Intune监控报告链接在会议期间已分享。随五月更新发布的脚本存放在System32文件夹,同一页面提供文档。

鉴于惠普固件问题和更广泛的Secure Boot故障已展示出事态的迅速恶化,微软提出“先测试一台”建议,是在KEK不再能签署未来安全撤销前,安全更新大规模部署的最佳路径。微软还重申,在WinHEC 2026宣布的驱动质量计划是其更全面承诺的一部分,旨在防止未来此类生态系统范围的中断,但目前Secure Boot截止日期依然紧迫。