Secure Boot 旧证书 6 月 24 日到期：别急着怕开不了机，更该查启动防线有没有换钥

6 月 24 日这个日期，容易被误读成一场“电脑开不了机”的倒计时。

真正该看的不是这个。微软用于 Secure Boot 信任链的三项旧签名证书将在这天到期。它们是 2011 年版本，接替它们的是 2023 年版本。证书换代以后，问题不在于机器会不会集体趴窝，而在于启动链这层防线有没有跟上。

对普通 Windows 10/11 用户，这大多会藏在系统更新里。对启用 Secure Boot 的 Linux 用户，尤其是管双系统、服务器或一批终端的人，麻烦会更具体：发行版的 shim 有没有更新，固件更新要不要等，老机器能不能顺利完成迁移。

到期不等于失效，真正变化在启动信任链

Secure Boot 做的事很窄，也很关键。

设备启动时，它会校验固件、引导程序等启动链组件的数字签名。签名可信，才继续往下加载操作系统。它不是万能杀毒软件，也挡不住所有恶意软件。它主要防的是抢在系统之前运行的代码，比如 UEFI bootkit。

所以，6 月 24 日之后，未更新设备通常仍能运行。更现实的风险是：它对新 UEFI 启动威胁的保护不完整。攻击发生在操作系统加载之前，等系统起来后再查杀，往往已经晚了一步。

这次变化可以这样看：

Linux 里的 shim 很小，但位置很靠前。它像 Secure Boot 和 Linux 引导加载器之间的一道桥。桥没换好，后面的路再平也会被卡住。

这里有一个现实约束：Secure Boot 不是微软单方面按下按钮就完成。它牵涉硬件厂商、微软、Linux 发行版和用户设备状态。任何一环慢，最后都会落到某台具体机器上。

为什么要换钥：LogoFail 之后，旧信任根不能一直背债

这次换钥的背景里，绕不开 2023 年披露的 LogoFail。

LogoFail 利用的是 UEFI 启动阶段解析厂商 Logo 图片时的漏洞。它可能绕过 Secure Boot，把恶意代码放到更底层的位置。这里的麻烦不在“Logo 图片”听起来有多离谱，而在攻击发生得太早。

启动越早，清理越难。

过去的 LoJax、MosaicRegressor、MoonBounce 等 UEFI 恶意软件已经说明一件事：攻击者愿意把战线推进到固件层。传统病毒进系统以后作恶，很多时候还能靠重装、回滚、查杀处理。UEFI 层的问题更隐蔽，恢复成本也更高。

但也别把这次更新神化。

证书刷新不能说明 LogoFail 被彻底消除，也不能保证以后没有新的 UEFI 攻击。它更像是把一把用了十多年的旧钥匙退出流通，降低攻击者继续借旧证书、旧策略扩大利用面的机会。

我更在意的是这个判断：安全更新不只发生在操作系统里，也发生在操作系统启动之前。很多人平时只盯 Windows 补丁、内核版本、杀毒软件状态，却忽略了启动链本身也会老化。

现在该做什么：普通用户确认状态，管理员排迁移顺序

Windows 10/11 用户不用把这件事当成手工大工程。

更合适的动作是两步：保持系统更新；再打开“Windows 安全中心 > 设备安全性 > Secure Boot”查看状态。也可以在支持的设备上用 PowerShell 查看 Secure Boot 是否启用，但这只能说明功能状态，不能替代系统更新本身。

如果你的电脑长期没打补丁，或者是很老的企业镜像，别只看“能开机”。先补齐系统更新，再复查 Secure Boot 状态。这个动作成本不高，但能避免把旧信任链一直留在机器里。

Linux 用户要更耐心一点。

启用 Secure Boot 的 Linux 设备，重点看发行版是否推送新的 shim。这里不要只盯内核版本。shim 是启动链前段组件，发行版、安全公告、包管理器里的更新信息都要看。

对企业管理员，真正要做的是排顺序，而不是等到 6 月 24 日当天临时救火：

这里最容易出错的是固件更新节奏。主板 UEFI 固件本身也受启动信任链影响。能等的话，尽量在证书替换完成后再刷固件；不能等，也要先在少量机器上验证，再推到全网。

这件事最后要观察的，不是 6 月 24 日那天有没有大面积宕机。更关键的变量有三个：Windows 设备是否按时拿到更新，Linux 发行版 shim 推送是否顺利，老旧设备在密钥迁移和固件更新时有没有兼容问题。

回到开头，6 月 24 日不是“电脑失效日”。它更像一次底层信任链的换轨。没换，不一定马上出事；一直不换，等于把防线留在十多年前。