☰

我的操作系统（Linux）如何使安全证书无效？

tag-icon • tag-icon linux https
我的操作系统（Linux）如何使安全证书无效？

我可以访问该网站https://ce.uci.edu在非 Linux 机器（包括我的手机）上没有问题。但是当我在 Linux 电脑上用 Chrome 或 Firefox 浏览它时，我收到错误“NET::ERR_CERT_AUTHORITY_INVALID”。

为什么我的操作系统会导致这种情况，而其他操作系统不会？安全证书验证不是应该独立于操作系统吗？

这导致与 IT 部门的对话变得尴尬，因为他们没有发现问题。

答案1

服务器没有发送“中间”证书（又名“链”），因此客户端根本没有足够的信息来验证。

您的桌面浏览器和/或操作系统通过缓存它看到的所有中间证书来解决这个问题。当您访问此网站时，浏览器会使用其缓存来完成该链。移动浏览器和非浏览器应用通常不会这样做。

这导致与 IT 部门的对话变得尴尬，因为他们没有发现问题。

他们不知道如何正确检查，只能在浏览器中打开网站。（“如果能打开，就说明可以正常工作。”）

尝试向他们提供扫描结果https://www.ssllabs.com/ssltest/这是一个广泛使用的网站，它试图检测此类错误配置。

安全证书验证不是应该独立于操作系统吗？

过程本身 – 是的（大多数情况下；可能会变得复杂）。

（让我们忽略诸如错误或时钟不匹配之类的琐碎问题。）

“受信任”根 CA 列表

第一个区别是，许多浏览器不使用自己的“受信任”证书颁发者列表——它们委托那操作系统的一部分，每个操作系统可能都有不同的列表。微软和苹果当然有自己的操作系统可信发行者程序，而大多数 Linux 发行版使用 Mozilla 的列表。（我相信谷歌也有专门针对 Android 的列表，但没有针对桌面 Chrome 的列表。）

  • 例如，IE 和 Edge/UWP 始终使用 Windows“SChannel”TLS 堆栈，包括其证书验证和根 CA 列表。
  • Chrome 还会调用 Windows TLS 证书函数（因此会使用 Windows CA 列表），尽管其余部分使用的是自己的“BoringTLS”库。不过，它会在基本 CA 检查的基础上应用自定义策略，例如根据签发日期拒绝某些签名类型。
  • Firefox 内置了 Mozilla CA 列表，并在其“NSS”库中内部完成所有操作。此外，它还可以添加超出标准验证范围的策略限制。
    • 但在 Windows 上，Firefox 可以可选地除了内置列表外，还从操作系统列表加载管理员安装的根 CA。（重要的是，即使手动启用此功能，它仍然不会加载默认 CA。）
    • 同样，在 Linux 上，一些 Linux 发行版修补了 NSS（以及 Firefox），使其始终使用系统范围的 CA 列表，而不是内部列表。这做加载默认系统 CA。
  • Windows 上的大多数非浏览器应用程序都使用 SChannel，但有些应用程序使用 OpenSSL。让 OpenSSL 像 Chrome 那样遵循 Windows TLS 验证相对困难，因此这些应用程序经常捆绑自己的 CA 集（名为 的文件curl-ca-bundle.crt，是 Mozilla 列表的副本），有时该文件会变得相当过时。
  • 然后是 Java...

缓存

还有“中间缓存”的问题。商业 Web 证书始终使用至少 2 层系统颁发：根 CA 是离线保护的，并且只颁发“中间”证书，只有这些证书在线并被允许颁发服务器证书。要通过验证，客户端需要知道整个“链”。

通常，客户端只有根 CA，服务器发送中间证书。但有时系统管理员错误配置服务器（或无法正确配置），导致中间证书未发送，验证链中断。例如，您的站点使用“InCommon RSA Server CA”颁发的证书，该证书比根 CA 低一级。但它不发送 InCommon 证书本身，因此无法将其与“受信任的根 CA”列表进行匹配。

为了应对此类错误，一些浏览器和一些操作系统会建立以前见过的中间 CA 的缓存。（Windows 会缓存它必须自行下载的中间 CA；Firefox 会缓存它见过的每个中间 CA。）这意味着，如果你访问的是配置错误的网站，成功/失败现在可能会有所不同从用户到用户，因为它们都建立了不同的缓存。

当系统管理员的自动响应是“它在我的系统上运行良好”时，这种情况尤其有害，因为他们可能在不知情的情况下制成它只在他们的系统上运行。

链建设

有时可能会多种的由于进行了“交叉签名”，因此多个证书链对同一证书有效。例如，Let's Encrypt 证书可以植根于 IdenTrust 的“DST Root CA X3”或者它们可以扎根于他们自己的shiny-new“ISRG Root X1”，取决于客户端拥有什么，也取决于服务器发送什么中间体（它可以发送多个）。

一些美国军事/政府网站使用自己的联邦 PKI 证书，而不是来自商业 CA 的证书。Windows 是唯一带有“受信任”根 CA 的操作系统，除非您手动安装一些根 CA，否则其他浏览器不会接受它。并且取决于哪个您安装的根 CA，同一个网站可能有许多可能的信任路径，有时链中多达 6-7 个证书。

不同的浏览器（尤其是那些将验证转移给操作系统的浏览器）可能会在这种情况下得出不同的可能链。例如，Windows 非常灵活，而 OpenSSL 在 1.1.x 之前非常缺乏，Firefox 经历了三重写了其链式构建代码。（当前使用的库 mozilla::pkix 最初被称为“insanity::pkix”，这应该能让您了解它有多么不必要地复杂。）

权威信息访问

我提到 Windows 能够自行下载那些缺失的中间件——尽管从技术上讲这是一项标准功能，但有些浏览器出于隐私方面的考虑完全拒绝实现此功能，而有些浏览器则因为额外的不必要复杂性而懒得使用它。这又是 Windows 和 Linux 之间的另一个区别。

（同样，此功能在美国“联邦 PKI”中被广泛使用，其中交叉签名非常普遍，并且系统开始看起来更像一个网而不是根层次结构。例如，组织 A 可能识别链 A→B→C→D，而另一个组织可能识别 B→A→C→D 或 B→C→D，且服务器证书 D 完全相同。）

相关内容