文章讨论了Linux与Secure Boot证书过期的问题，指出证书过期可能导致系统无法启动，并探讨了可能的解决方案和影响。

Linux与Secure Boot证书过期问题

标题: Linux与Secure Boot证书过期
来源: LWN.net
发布时间: 2025年7月19日 13:51:41 GMT

Linux与Secure Boot证书过期
作者: Jake Edge
2025年7月16日

启用了Secure Boot的Linux用户，无论是否知情，都依赖于微软的一个密钥，该密钥将于2025年9月到期。此后，微软将不再使用该密钥签署Linux发行版用于Secure Boot内核启动的第一阶段UEFI引导加载程序（shim）。尽管自2023年起已有替代密钥可用，但许多系统可能尚未安装该密钥，甚至可能需要硬件厂商发布固件更新，而这种情况未必会发生。虽然大多数系统不会因此无法启动，但发行版和用户可能需要额外的工作来应对这一问题。

Mateus Rodrigues Costa于7月8日在Fedora开发邮件列表中提出了这一问题。他注意到“本月Windows 11累积更新”附带了一个警告，提到Secure Boot证书将从2026年6月开始陆续到期。这些证书与用于shim的证书不同，后者将在更早的时间到期。无论如何，证书过期问题是Linux社区需要面对的挑战。

情况相当复杂。Daniel P. Berrangé指出，Linux Vendor Firmware Service (LVFS)网站上的一个页面描述了这一问题。LVFS是fwupd等工具的所在地，这些工具用于从Linux更新系统固件。LVFS和fwupd曾在2020年的一篇LWN文章中被详细介绍。

问题的多个方面需要关注。为了通过Secure Boot启动Linux内核，UEFI引导过程要求第一阶段引导加载程序使用未过期的固件数据库中的密钥进行签名。这些密钥包含在证书中，证书还包含其他信息，如过期日期和签名。证书过期主要应在Secure Boot系统上安装新发行版时成为问题；安装的shim将具有发行版特定的密钥，并可以作为运行其他程序（如GRUB）的信任根。

目前，shim使用2011年的微软密钥进行签名，该密钥将于9月11日到期。此后，安装介质将无法启动，除非它使用2023年微软为第三方提供的UEFI密钥签名的更新版shim（这与Windows更新中提到的特定密钥不同）。任何已安装的发行版都应具有使用其自身密钥签名的引导加载程序，该程序将继续启动。

然而，许多系统的固件数据库中缺少微软的新密钥，有些系统同时拥有新旧密钥，而有些系统可能只有新密钥，目前根本无法通过Secure Boot启动Linux安装介质。厂商可以提供固件更新以添加新密钥，安装介质也可以使用由其签名的shim创建，但这些更新必须安装在系统上。这就是LVFS和fwupd的用武之地。

LVFS是各种厂商固件更新的存储库，fwupd和其他工具可以使用这些更新将所需的部分安装到固件中。Berrangé指出，旧版本的fwupd无法解决所有问题，“但最近的版本已增强，能够处理Linux用户需要看到的更新，这应该能减轻最严重的影响”。然而，可能仍会有些波折：“用户应该‘意识到’可能出现的问题，但希望最严重的‘担忧’部分由操作系统厂商和维护者处理。”

LVFS的创建者和维护者Richard Hughes同意这一观点，并指出有多种方式可以让用户的系统获得更新的Secure Boot功能。厂商可能会提供完整的固件更新，这将（假设）添加新的数据库，包括新的微软密钥。另一种途径是“密钥交换密钥”（KEK）更新，这是由微软密钥签名的厂商特定密钥；fwupd可以使用它来更新数据库中的新密钥。但有一些注意事项：

KEK更新的成功率约为98%，数据库更新的成功率约为99%——但即使1%乘以数百万用户，也意味着相当多的部署失败——例如“无法写入efivarfs”的问题。对某些用户来说，重启并将BIOS恢复为出厂默认设置可以解决问题——这会触发可用efivar空间的“碎片整理”，从而有足够的连续空间来部署更新。BIOS越旧，遇到此问题的可能性越大。

Hughes指的是一个已知的关于新EFI变量空间的问题。

对于厂商不提供更新的系统，禁用Secure Boot可能是允许新安装的唯一选择。在短短几个月内，所有现有的安装镜像和介质将无法通过Secure Boot安装——对于只有新密钥的系统来说，这可能已经成为现实。Secure Boot安装变得更加复杂。

除此之外，厂商更新中可能出现错误或问题。Hughes指出，至少有一家制造商丢失了其平台密钥（PK）的私钥部分，这是硬件制造时烧录的厂商特定密钥。这意味着硬件中的平台密钥需要更改，这是未知领域，并且“从认证角度来看是一个糟糕的想法”。此外，正如Gerd Hoffman指出的那样，KEK更新过程也是新的：“KEK更新以前从未发生过，因此BIOS厂商可能会搞砸，导致KEK更新无法工作。”

该线程中有多个关于各种硬件型号上Secure Boot证书的报告，以及KEK和数据库更新的报告。一个不完全清楚的问题是，固件实现是否会真正强制执行2011年密钥的过期日期。基于该密钥的功能性信任链的工作系统可能会继续使用由该密钥签名的shim，即使在9月之后。然而，任何shim更新（例如出于安全问题）将无法使用旧密钥签名——微软不会使用过期的密钥签署任何内容。这可能会导致某种“解决方案”，正如Adam Williamson所说：

理论上，我们是否也可以选择为这种情况提供旧的shim？如果整个链都是旧的，它应该可以工作，对吧？当然，我们还需要一些启发式方法来确定我们是否在使用旧的MS证书，并安装旧的shim……

他表示，这可能并不真正有意义，用户应该直接禁用Secure Boot。Hoffman同意所有这些观点，但指出了shim更新的问题：“继续运行已知安全漏洞的shim使得启用Secure Boot变得毫无意义。”

总的来说，Linux社区似乎在这种情况下尽了最大努力——就像在涉及主要关心Windows的厂商硬件时经常发生的那样。鉴于Secure Boot信任根密钥（平台密钥和签名密钥）都在厂商（微软和硬件制造商）的控制之下，保持更新始终会有些困难。由于Linux和发行版明确支持旧硬件，而其他厂商早已转向最新的硬件，这显然会导致一些紧张。人们只能希望这一过程尽可能顺利。

评论

Press X to doubt
2025年7月16日 18:31 UTC (Wed) by bluca (订阅者, #118303) [链接] (4 回复)

一个不完全清楚的问题是，固件实现是否会真正强制执行2011年密钥的过期日期。

根据我多年来的观察，我怀疑大多数固件实际上不会检查这一点。

Press X to doubt
2025年7月16日 19:39 UTC (Wed) by kraxel (订阅者, #49444) [链接] (2 回复)

tianocore edk2为pkcs7签名验证设置了NOCHECKTIME。

https://github.com/tianocore/edk2/blob/master/CryptoPkg/L...

Press X to doubt
2025年7月17日 15:32 UTC (Thu) by pjones (订阅者, #31722) [链接] (1 回复)

你说得对，但这也是因为检查Secure Boot中证书的验证窗口既无助于保证安全性，也不合理，原因有二。

一是它并不能保证任何安全性——通常要防范的威胁是受

评论1（评分：无，作者：kvemkon）指出该内容为重复发布，并提供了之前讨论的链接。主要观点是认为该内容已经在其他平台上讨论过，无需再次发布。

关键引用： - "Dupe: https://news.ycombinator.com/item?id=44601045" - "重复发布：https://news.ycombinator.com/item?id=44601045"