跳转至

根证书信任库也是软件依赖：开源生态中被忽视的证书安全盲区

Trust Stores Are Dependencies Too

文章背景与核心概要

在现代互联网安全体系中，数字证书是建立安全加密连接 (TLS/SSL) 的信任基石，而操作系统与浏览器通常负责集中动态维护并吊销存在风险的根证书。然而，近期曝光的 eMudhra 私钥生成漏洞事件揭开了开源软件供应链中一条鲜为人知的阴暗面：大量编程语言、开发工具和第三方依赖库为了方便分发，普遍在安装包内自带静态的根证书信任库 (Trust Stores) 副本，使得系统级的安全修补彻底失效。安全团队通过对近 7000 个核心开源包的深度扫描发现，这种“幽灵二进制依赖”不仅长期未随主流标准更新，甚至还暗藏着数年前就被全网封杀的失陷证书。更为严峻的是，当前通用的软件物料清单 (Software Bill of Materials, SBOM) 与漏洞扫描工具仅按版本号比对源码依赖，对此类静态硬编码资产完全“失明”，为整个数字世界的软件供应链安全敲响了警钟。

核心内容摘要

Summary

当权威数字证书机构 eMudhra 因生成算法失误导致中间证书颁发机构 (Intermediate Certificate Authorities, CAs) 的私钥可被直接逆向破解时，全球主流操作系统与浏览器在第一时间做出了响应，迅速吊销了对相关证书的信任。然而，我们赖以构建软件的各种客户端库、包管理器及编程语言运行时，往往在自身内部硬编码打包了独立的根证书信任库 (Trust Stores) 副本，使得系统的安全拦截彻底失效。一项针对近 7000 个核心开源软件包的安全审计揭示了一个令人震惊的现实：数十个广泛使用的开源包依然捆绑着早已被废弃、不再安全甚至已被攻陷的陈旧根证书。这形成了一类隐蔽的“幽灵二进制依赖 (Phantom Binary Dependencies)”，完美躲过了现有的标准漏洞扫描器与软件物料清单 (Software Bill of Materials, SBOM) 的审查雷达。

When eMudhra incorrectly generated intermediate certificate authorities (CAs)—allowing private keys to be recovered directly from the certificates—major operating systems and browsers quickly revoked trust. However, many client libraries, package managers, and programming language runtimes bundle their own static copies of root trust stores, completely bypassing system updates. A security audit of nearly 7,000 critical packages revealed that dozens ship outdated Certificate Authority (CA) bundles containing long-removed, insecure, or compromised roots, exposing an invisible class of "phantom binary dependencies" that evade standard vulnerability scanners and SBOMs.

捆绑式根证书信任库的蔓延范围

The Reach of Bundled Trust Stores

在 eMudhra 安全事件爆发后，Firefox、Chrome、Apple 和 Microsoft 于 10 月 17 日至 20 日期间，通过系统内置的信任列表自动更新机制，迅速封禁了受影响的中间证书。但安全披露公告同时指出，由于许多客户端和开发环境依赖自身内置的硬编码根证书，它们必须依赖手动发布软件更新才能修复安全风险。受此波及的工具生态包括：

Following the eMudhra incident, Firefox, Chrome, Apple, and Microsoft blocked the compromised intermediates through automatic trust list updates between October 17 and 20. However, the disclosure noted that many clients require manual software updates because they rely on embedded roots. The affected ecosystem included:

  • certifi (截至 2026.10.19 的多个版本) 与 pip (26.2.2)
  • uv (0.13.4) 与 pixi (0.82.1)
  • webpki-roots、webpki-root-certs、rustls-webpki 以及 rustup
  • Node.js、Go、Composer (ca-bundle)、Elixir (castore) 以及 Perl (Mozilla::CA)
  • cURL CA 证书包、NSS、多个 Linux 发行版以及 macOS 原生自带的 pip3
  • certifi (versions through 2026.10.19) and pip (26.2.2)
  • uv (0.13.4) and pixi (0.82.1)
  • webpki-roots, webpki-root-certs, rustls-webpki, and rustup
  • Node.js, Go, Composer (ca-bundle), Elixir (castore), and Perl (Mozilla::CA)
  • The cURL CA bundle, NSS, various Linux distributions, and macOS's native pip3

正如 Gentoo 维护者 Michał Górny 所指出的，单纯更新操作系统层面的信任库往往远远不够。Python 虚拟环境、内嵌捆绑的第三方依赖包 (例如 Python 标准库 ensurepip 中附带的 pip)、包管理器锁定文件的冻结策略、静态编译的 Rust 二进制可执行文件，以及层层嵌套的 Flatpak 沙箱运行时，都在私自保留这些证书的独立副本，必须逐一独立更新才能消除隐患。

As Gentoo maintainer Michał Górny observed, updating system-level trust stores is often insufficient. Virtual environments, vendored package dependencies (such as pip inside ensurepip), lockfile cooldown policies, statically compiled Rust binaries, and nested Flatpak runtimes all maintain isolated copies of these certificates that must be updated independently.

关键开源包中的内置证书现状

Bundles in Critical Packages

为了进一步评估在常用开发工具之外，整个软件生态中内置信任库的扩散广度，安全团队使用审计工具 git-pkgs/certs 对来自 PyPI、npm、crates.io、Go、Maven Central、Packagist、NuGet 和 RubyGems 的 6877 个核心关键开源包进行了全方位扫描。

To understand the scale of embedded trust stores beyond well-known tools, an audit using git-pkgs/certs scanned 6,877 critical packages across PyPI, npm, crates.io, Go, Maven Central, Packagist, NuGet, and RubyGems.

扫描结果显示： * 1.7% (共 116 个软件包) 包含 X.509 格式证书 (多数为测试用例夹具或代码签名证书)。 * 28 个软件包 直接打包并分发了具备完整功能的 CA 证书包 (此外，在单独抽样的 RubyGems 样本中还发现了第 29 个，即 Honeybadger)。

Out of these: * 1.7% (116 packages) contained X.509 certificates (mostly test fixtures or signing certs). * 28 packages shipped functional CA bundles (with a 29th, Honeybadger, found in a separate RubyGems sample).

这些内置证书包与系统安全体系的交互方式五花八门，大致可分为以下几类： * 系统叠加型 (System Overlay)：例如 excon、pip 和 redshift-connector 等库，它们会将内置证书包与系统根证书“并行加载”，这意味着即便操作系统已经吊销了某个危险根证书，应用程序依旧会盲目信任它。 * 隔离信任库 (Isolated Stores)：Stripe 的 Ruby 客户端库和 httpclient 直接利用自带的证书包构建独立的 OpenSSL::X509::Store 实例，与系统信任库彻底割裂。 * 回退与覆盖策略 (Fallbacks & Overrides)：诸如 botocore、httplib2 和 Google 的 Java 客户端等工具，仅在检测不到系统信任库时才会回退使用自带的密钥库，这导致实际安全防御水位严重依赖具体的部署环境。 * 深度潜伏文件 (Deeply Embedded Files)：libv8 将证书打包在 depot_tools 内部，而 Google App Engine 的 API 桩代码也为本地开发服务器携带了证书文件。

These bundles interact with system security in varied ways: * System Overlay: Libraries like excon, pip, and redshift-connector load their bundles alongside system roots, meaning a revoked OS-level root remains trusted. * Isolated Stores: Stripe’s Ruby library and httpclient build independent OpenSSL::X509::Store instances from their bundles. * Fallbacks & Overrides: Tools like botocore, httplib2, and Google’s Java clients fall back to bundled keystores only when system stores are missing, creating deployment-dependent security postures. * Deeply Embedded Files: libv8 bundles certificates inside depot_tools, and Google App Engine API stubs carry them for local development servers.

早被移除与失陷的危险根证书

Removed and Compromised Roots

安全人员将这些软件包中的证书与 Mozilla 历年发布的官方证书库进行历史比对，发现大量内置证书包存在令人咋舌的严重滞后现象： * 严重陈旧的证书包 (Stale Bundles)：Honeybadger 和 httpclient 分发自带的根证书列表居然分别停留在 2011 年和 2014–2015 年；令人费解的是，这些开源包的业务代码直到 2026 年底都在频繁维护更新。 * 被遗弃的 StartCom 根证书 (Orphaned StartCom Roots)：诸如 algoliasearch、aws-sdk-v1 和 Guzzle 3 等软件包，依然包含早在 2017 年就被 Mozilla 在 Firefox 58 中彻底移除的 StartCom 根证书；更可怕的是，这些不受信任的证书在密码学有效期限上竟然能一直维持到 2036 年和 2039 年。 * eMudhra 泄露风险波及 (The eMudhra Exposure)：在被扫描的软件包中，有 10 个项目 (包括 Stripe、gRPC、Composer 和 virtualenv) 包含交叉签名根证书 emSign ECC Root CA - G3，该证书正是通往已被攻陷的 eMudhra 中间证书的信任桥梁。由于大多数内置证书库缺乏在线吊销检查机制且无条件信任该根证书，在发布针对性代码补丁之前，它们始终处于易受攻击的危险状态。 * Comodo AAA 证书服务风险 (Comodo AAA Certificate Services)：尽管 Mozilla 早在 2025 年就终止了对 Comodo AAA 根证书在 TLS 领域的信任，但在本次审计中仍有 17 个关键软件包 (包括 honeybadger、httpclient、aws-sdk-v1 和 httplib2) 依然将其作为默认信任锚点或回退信任源。

Historical matching against Mozilla releases revealed severe staleness in package bundles: * Stale Bundles: Honeybadger and httpclient shipped root lists dating back to 2011 and 2014–2015, respectively, despite receiving regular code maintenance up to late 2026. * Orphaned StartCom Roots: Packages such as algoliasearch, aws-sdk-v1, and Guzzle 3 still contain StartCom roots removed by Mozilla in Firefox 58 (2017), which remain cryptographically valid until 2036 and 2039. * The eMudhra Exposure: Ten of the scanned packages (including Stripe, gRPC, Composer, and virtualenv) contained the cross-signing root emSign ECC Root CA - G3, which bridged traffic to the compromised eMudhra intermediates. Because many bundles lacked revocation checking and trusted this root, they remained vulnerable until explicitly patched. * Comodo AAA Certificate Services: Though Mozilla ended TLS trust for Comodo's AAA root in 2025, it was still found in 17 scanned packages (including honeybadger, httpclient, aws-sdk-v1, and httplib2) acting as a default trust anchor or fallback.

尽管在 10 月份的安全事件披露后，诸如 botocore、AWS SDKs 和 excon 等高知名度工具的维护者迅速推送了安全补丁，但大量下游项目、嵌套依赖项以及长期锁死固定版本的 lockfile，依然在悄无声息地分发和运行着这些包含安全隐患的证书资产。

While maintainers rapidly patched high-profile tools (such as botocore, AWS SDKs, and excon) following the October disclosures, many downstream dependencies and pinned lockfiles continue to distribute these vulnerable assets.

软件包元数据与 SBOM 的监控盲区

Package Metadata and the SBOM Blind Spot

要发现这些深埋在软件包内部的根证书信任库，安全研究人员必须对压缩归档文件的实际内容进行逐文件静态深度解析，因为目前没有任何现行的软件包元数据标准或 SBOM 格式能够追踪它们。

Discovering these embedded trust stores required statically parsing archive file contents because no standard package metadata or SBOM format tracks them.

标准的依赖关系图谱和 lockfile 仅记录软件包的包名和版本号 (例如 pkg:gem/httpclient@2.9.0)，对包内是否静态硬编码了某个历史年份的根证书库完全处于“失明”状态。CA 证书包本质上充当了一种幽灵二进制依赖 (Phantom Binary Dependency)——它们原本是由上游 Mozilla 动态维护的第三方敏感数据，却被开发者手动复制粘贴到了源码仓库中，随后在一次次的版本迭代中被悄然继承并固化。

Standard dependency graphs and lockfiles record packages by name and version (e.g., pkg:gem/httpclient@2.9.0), remaining completely blind to the fact that the package embeds a statically compiled trust store from a specific historical year. A CA bundle functions as a phantom binary dependency—third-party data maintained upstream by Mozilla, manually copied into source trees, and silently inherited across releases.

虽然 Debian 发行版的 Built-Using 元数据字段以及 CycloneDX 的 pedigree 规格规范在理论上提供了追踪静态打包依赖的机制，但绝大多数标准 SBOM 生成工具目前仍严格只读取 lockfile 声明。其直接后果是，现有的自动化漏洞扫描器在机制上根本无法察觉：某款应用在其庞杂的依赖树深处，其实正默默信任着一整套早已被吊销或废弃的危险 CA 根证书。

While Debian's Built-Using field and CycloneDX's pedigree specification offer theoretical mechanisms to track static inclusions, standard SBOM generators rely strictly on lockfiles. Consequently, vulnerability scanners remain fundamentally unequipped to detect when an application is silently trusting revoked or outdated Certificate Authorities hidden deep within its dependency tree.