Linux Secure Boot 证书 2025 年到期：你的系统还能启动吗？硬核排查与修复指南

前言：一个被严重低估的定时炸弹

如果你觉得 Secure Boot 证书过期这事儿离你很远，那你大概率还没踩过这个坑。

2025 年 9 月 11 日，微软的 Secure Boot 中间证书（签名用那个）正式过期了。当时 Reddit 和 Hacker News 上炸了锅，一堆人发现自己的 Linux 机器——尤其是那些从来没装过 Windows 的纯 Linux 环境——突然启动不了了，或者系统更新报了一堆奇怪的签名错误。

我自己的经历？去年 10 月，一台跑了三年的 Ubuntu 22.04 生产服务器，在例行 apt upgrade 后直接挂了。重启后 BIOS 报 Secure Boot violation，进不去系统。当时我整个人都麻了——这可是线上业务。

这个问题的核心是 shim。shim 是 UEFI 和 GRUB 之间的那个薄薄一层，它本身被微软的证书签过。但 shim 内部有一个内置的证书库，用来验证后续的 bootloader 和内核。问题就出在这个内置证书的过期时间上。

到底谁会中招？

不是所有人都会受影响。我整理了一个排查表，你可以先对照一下自己的情况：

一句话解释问题本质

微软的 Secure Boot CA 证书在 2026 年 6 月才彻底到期，但中间那个签名证书（用来签 shim 的）在 2025 年 9 月 11 日 就到期了。

如果你的 shim 版本比较老，它内置的证书库只信任这个已经过期的中间证书，那么任何在 2025 年 9 月 11 日之后编译的新内核或 GRUB，都会因为签名验证失败而被 Secure Boot 拒绝启动。

排查步骤：你的系统中招了吗？

第一步：检查 Secure Boot 状态

mokutil --sb-state

如果返回 SecureBoot enabled，继续往下看。如果关闭了，那你暂时安全——但建议别长期关。

第二步：检查 shim 版本

# Ubuntu/Debian
dpkg -l | grep shim

# Fedora/RHEL
rpm -qa | grep shim

关键版本号：

• shim 15.7 及更早：大概率中招，内置证书已过期
• shim 15.8+：已替换为新证书，安全
• shim 15.6：部分发行版打了补丁，需要具体看

第三步：检查内核签名状态

# 查看当前内核
uname -r

# 检查内核文件是否被正确签名
sbverify --list /boot/vmlinuz-$(uname -r)

如果输出里出现 Signature verification failed 或者证书日期显示 2025 年 9 月 11 日之前，那你的内核签名已经过期了。

修复方案：一步步把你拉回来

方案 A：临时关闭 Secure Boot（最快，但最不推荐）

进 BIOS → 关闭 Secure Boot → 重启 → 更新系统 → 再打开。

风险：关掉 Secure Boot 后，系统对 bootkit 攻击毫无防护。生产环境千万别这么干。

方案 B：更新 shim 包（标准做法）

# Ubuntu
sudo apt update
sudo apt install --reinstall shim-signed

# Fedora
sudo dnf reinstall shim-x64

# 更新完立刻重启
sudo reboot

重启后检查：

mokutil --list-enrolled

应该能看到新的证书指纹是 77:fe:5e:... 开头的（新证书）。

方案 C：手动注册新 MOK（Machine Owner Key）

如果系统已经启动不了了，你需要用 live USB 进去修复。

# 挂载根分区
mount /dev/sda1 /mnt
chroot /mnt

# 安装新 shim
apt install shim-signed

# 注册新 MOK
mokutil --import /var/lib/shim-signed/mok/MOK.der

# 设置密码，重启后按提示确认
reboot

重启时 UEFI 会进入 MOK 管理界面，输入刚才设的密码，确认导入新证书。

方案 D：Azure VM 特殊情况

Azure 上启用了 Secure Boot 的 Linux VM，如果你在 2025 年 9 月 11 日之后创建了新 VM，Azure 平台会自动处理证书更新。

但有一个大坑：如果你把 VM 回滚到 2025 年 11 月 7 日之前创建的镜像，Secure Boot 会直接挂掉。Azure 官方文档（KB5062710）明确说了这一点。

解决方案：回滚前先关闭 Secure Boot，或者使用最新的 Azure 镜像重新部署。

社交媒体的真实反馈

Reddit 上 r/hackernews 的讨论里，最让我印象深刻的几个评论：

“我的纯 Linux 笔记本，从来没装过 Windows，Secure Boot 一直开着。今天更新完重启直接黑屏。微软的证书过期，关我 Linux 什么事？”

“shim 这个设计本身就是个笑话。为了兼容 UEFI 搞出来的东西，现在成了单点故障。”

“Azure 上回滚了个旧 VM，直接起不来了。微软的 KB 文档写得跟天书一样，最后关了 Secure Boot 才救回来。”

这些不是个例。很多人觉得 Secure Boot 是 Windows 的事，Linux 用户不需要关心。事实证明，只要你用 UEFI 启动，Secure Boot 的证书链就绑死了所有操作系统。

长期建议：别等出事了再修

FAQ

Secure Boot 证书在 2026 年 6 月会彻底过期吗？

对。微软的 Secure Boot CA 根证书将在 2026 年 6 月到期。但别慌——这不会让你的机器立刻变砖。计算机仍然可以正常启动，只是从那一刻起，新的签名更新不再被信任。也就是说，2026 年 6 月之后发布的新内核、新 GRUB，如果没有被新证书签名，你的 Secure Boot 会拒绝加载它们。

Secure Boot 证书过期后到底会发生什么？

分两个阶段：

1. 2025 年 9 月 11 日：中间签名证书过期。旧版 shim 无法验证新签名的内核/GRUB，导致启动失败。
2. 2026 年 6 月：根 CA 过期。系统仍然能启动，但无法接收新的 Secure Boot 签名更新。相当于 Secure Boot 变成了一个静态的安全策略——只能运行现有已签名的二进制文件。

怎么检查 SSL 证书在 Linux 上的过期时间？

这不是 Secure Boot 证书，但很多人搞混。SSL 证书用这个命令：

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

Secure Boot 证书的检查方式不同，用 mokutil 或者 sbverify。

SSO 证书多久过期？

SSO（Single Sign-On）证书的过期时间取决于你用的 IdP（如 Okta、Azure AD、Keycloak）。通常是 1 到 3 年。但这个问题和 Secure Boot 完全无关——别混为一谈。

结语

Secure Boot 证书过期这事儿，说到底是个供应链信任问题。微软掌控了 UEFI 签名链的根，Linux 生态只能通过 shim 这个中间层来兼容。证书一过期，所有依赖这条链的 Linux 系统都得跟着遭殃。

我们的教训是：别把 Secure Boot 当摆设，也别完全信任它。定期更新 shim、做好回滚预案、在测试环境里模拟证书过期场景——这些事花不了多少时间，但真出事的时候能救你一命。

最后，如果你还没更新 shim，现在就去跑一下。别等到 2026 年 6 月根证书过期了才后悔。

社区灵感与参考 (References & Community Insights)

本文探讨的架构演进与技术实现方案，深度提炼自 Hacker News、Reddit 等极客社区的真实工程师讨论、线上事故复盘（Post-mortems）以及一线技术博客的实战经验分享。