☰

X.509 证书在 Chrome 中给出错误，但在 Firefox 中有效

tag-icon • tag-icon debian chrome
X.509 证书在 Chrome 中给出错误，但在 Firefox 中有效

RedHat 6.2 VM我刚刚在运行的 Apache 2.2 的站点/虚拟主机中更新了由 Multicert 颁发的公共 X.509 证书。我们就这样称呼它吧https://www.multicert.com。我使用 Chrome 访问该网站的客户端计算机正在运行Debian 9。

令我惊讶的是，该证书在 Firefox Quantum 60.2.0esr（64 位）和 Safari 中都给出了批准/绿色，但是 Chrome 69.0.3497.92 现在抱怨该网站不安全（而之前使用旧证书时，它是好的）。

我检查了 Apache 配置，一切似乎都很好。我还三次检查了 X.509 证书链和根，一切似乎都正常。

我们还为一个类似配置的网站同时颁发了另一个公共证书，但是，它已颁发，Comodo但没有颁发Multicert，并且在此站点中，Chrome 可以很好地使用该证书，我们称其为https://www.digicert.com

如果我恢复到旧证书，Chrome 会再次工作，但是我不能就这么保留它，因为它可能会在明天被撤销，并且在几天后到期。

我们在带有 Comodo 证书的网站中注意到的唯一变化是在 Chrome 中，当单击证书时lock->Certificate-details，我们在“扩展”下有一个带有标识符的新字段OID.1.3.6.1.4.1.1.11129.2.4.2

图像

这里发生了什么？

答案1

给定 OID .1.3.6.1.4.1.1.11129.2.4.2，我找到了相关的 Let's Encrypt 文章工程深入探讨：证书中 SCT 的编码

Let's Encrypt 最近推出了在证书中嵌入 SCT。此功能允许浏览器检查证书是否已提交到证书透明度日志。

我开始对此主题进行一些调查，最终发现 Google 从 2018 年 5 月 1 日起在 Chrome 中对所有类型的 X.509 证书强制执行证书透明度。

从Google Chrome 中的证书透明度强制执行

此通知将发送给通用 CA 数据库 [1] 已知的所有 CA 运营商，并适用于当前或将来可能在 Chrome 运行的平台（Mozilla NSS、Microsoft Windows、Apple iOS/ macOS、Google ChromeOS 和 Android）。

我们谨此重申 Chrome 将于 2018 年 4 月实施的证书透明度 (CT) 强制措施。正如在 CA/B 论坛上首次宣布的那样 [2]，随后在 mozilla.dev.security.policy 论坛上发布的公告 [3]，以及后来在引用的 ct-policy 论坛中更新的 [4]，Chrome 将开始强制执行2018 年 4 月之后颁发的所有 TLS 证书均符合 Chromium CT 政策 [5]，才能获得信任。

自 2015 年 1 月起，Chrome 要求扩展验证 (EV) 证书符合 CT 要求才能获得 EV 状态。 2018 年 4 月，此要求将扩展到所有新颁发的公共信任证书（DV、OV 和 EV），并且 Chrome 评估时不符合此政策的证书将不会被视为受信任。由用户或管理员添加的本地受信任的 CA 或企业 CA 颁发的证书不受此要求的约束。

发生了什么以及何时发生？

Chrome 将要求 2018 年 4 月 30 日之后颁发的所有 TLS 服务器证书均符合 Chromium CT 政策。在此日期之后，当 Chrome 连接到提供不符合 Chromium CT 政策的公众信任证书的网站时，用户将开始看到一个完整的页面插页式广告，表明其连接不符合 CT 要求。通过不符合 CT 的 https 连接提供的子资源将无法加载，并会在 Chrome DevTools 中显示错误。强烈鼓励 CA 在 3 月底之前与客户合作，确保其 TLS 证书已准备好通过 RFC 6962 第 3.3 节 [6] 中指定的三种方式之一遵守 Chromium CT 政策，以确保部署过程中出现的任何问题CT 支持在执行截止日期之前得到解决。这些更改将首先推广到桌面平台，包括 macOS、Windows、Linux 和 ChromeOS。

为了满足某些企业的独特需求，Chrome 政策将禁止在托管设备上以及在个人设备上登录 Chrome 的托管用户上执行 CT 强制。除了通过 URL [7] 禁用 CT 强制的现有功能之外，Chrome 还将添加一项策略，允许组织为仅向该组织颁发证书的 CA 禁用 CT 强制。

从2018 年 4 月后 Chrome 需要 CT

Chrome 将要求 2018 年 4 月 30 日之后颁发的所有 TLS 服务器证书均符合 Chromium CT 政策。”这意味着 SSL/TLS 证书必须通过满足以下条件之一来获得 CT 资格：

  • 来自检查时合格的日志的签名证书时间戳 (SCT) 通过 TLS 扩展提供，或者嵌入到装订的 OCSP 响应中，其中至少有一个来自 Google 日志的、在检查时合格的 SCT，并且至少一项来自非 Google 日志的 SCT，在检查时合格。

  • 提供检查时合格的日志中的嵌入式 SCT，其中至少有一个来自 Google 日志的嵌入式 SCT，至少有一个来自非 Google 日志的嵌入式 SCT，并且存在嵌入式 SCT 的最小数量。

所以从证书透明度简介

签名证书时间戳

证书通常由颁发证书的 CA 提交到 CT 日志，但站点所有者也可以将自己的证书提交到日志。 SCT 是您提交证书时证书日志的响应，这本质上是承诺在给定的时间内将证书添加到日志中。当客户与我们的网站建立 TLS 连接时，我们必须向客户提供此 SCT，我们可以通过 3 种方法来实现此目的。

x.509v3 扩展

为站点运营商提供 SCT 的首选方法是通过 X.509v3 扩展。这意味着您的 CA 将在签署证书并将其颁发给您之前将 SCT 嵌入到您的证书中，因此您完全不需要进行任何工作或设置。 CA 将构建您的证书，并在签署最后一步之前将其作为预证书提交到 CT 日志。日志将使用预证书的 SCT 进行响应，CA 会将其嵌入到证书中，然后对其进行签名，准备颁发给您。

TLS 扩展

SCT 还可以通过 TLS 扩展从主机传送到连接客户端。这是在 TLS 握手期间使用名为signed_certificate_timestamp 的扩展进行的，但确实需要主机更新其服务器并将其配置为传送 SCT。这里的好处是对于 CA 来说，他们不必改变颁发证书的方式，但等待 SCT TLS 扩展的可靠服务器实现对于站点运营商来说可能并不好。

OCSP 装订

我是 OCSP Stapling 的粉丝，它通常用于传递有关我们证书的吊销信息，但它也可用于将 SCT 从 CA 传递给站点运营商。这对 CA 来说又是一个好处，因为他们不必更改其颁发流程，只需照常签署和颁发证书，并通过 OCSP 提供 SCT。不过，这对我们来说也是一个问题，因为我们的服务器需要能够可靠地进行 OCSP Staple 并在握手期间将 SCT 包含到客户端。

结果是我的两个网站，其中一个（例如：www.digicert.com）直接在证书中包含 SCT X.509 扩展，并且不需要在服务器端进行任何设置修改。

在另一个站点（例如：multicert.com）上，CA 操作员选择使用 X.509 装订，因此 Apache Web 服务器需要更改配置。

我还在 Digicert 上找到了一篇关于Apache 的 OCSP 装订

因此，为了使站点能够进行 OSCP 装订工作，我需要：

  • Apache 版本大于 2.3.3

  • 与 CA OCSP 服务器进行通信的 VM

  • 添加到虚拟主机：

    在 <virtualhost...> 指令之外

     SSLStaplingCache shmcb:/tmp/stapling_cache(128000)

    在 <virtualhost...> 指令内

     SSLUseStapling on

    并重新启动阿帕奇。

在使用 Multicert 颁发的 X.509 证书的网站进行这些更改后，Chrome 表示证书在两个网站中均有效。

也可以看看Chrome Linux 未显示 X.509 扩展、SCT

更多技术细节

我还被问到 2018 年 5 月 1 日的时间门槛是如何规定的，以及旧证书会发生什么情况。由于网上缺乏更多明显的细节，我从以下位置下载了 Chromium 源代码https://chromium.googlesource.com/chromium/src/使用命令：

git clone https://chromium.googlesource.com/chromium/src

对于那些对证书透明度功能感兴趣的人来说，更有趣的目录似乎是 components/certificate_transparency/最有趣的文档文件net/docs/certificate-transparency.md

有趣的摘录自net/docs/certificate-transparency.md

概述

证书透明度 (CT) 是一种协议，旨在修复 SSL/TLS 证书生态系统中的多个结构性缺陷。描述于 RFC 6962，它提供了一个公共的、仅附加的数据结构，可以记录由证书颁发机构 （CA）。通过记录证书，公众可以查看给定 CA 颁发了哪些证书。这使得站点操作员能够检测何时为其域颁发了证书，从而允许他们检查是否有未经授权的颁发。它还允许浏览器和根存储以及更广泛的社区检查 CA 颁发的证书并确保 CA 遵守其预期或披露的做法。

基本

如果证书附带的 CT 信息表明它已记录在多个 CT 日志中，我们就说该证书支持证书透明度。此 CT 信息必须符合Chrome 中的证书透明度 政策。我们有时将“支持”CT 的站点称为使用“CT 合格”或“通过 CT 披露”的证书。

Chrome 政策

在过去的几年里，Chrome 逐渐要求越来越多的公众信任的证书具有证书透明度。

  • 自2015年1月1日起，Chrome 要求通过证书透明度披露所有扩展验证证书。未正确披露的证书将被被剥夺电动车身份，但不会向不合规网站的访问者显示任何警告。

  • 自2016年6月1日起，Chrome 要求赛门铁克公司拥有的根证书集颁发的所有新证书均通过证书透明度进行披露。未披露或未以符合 RFC 6962 的方式披露的证书将因不可信而被拒绝。

  • 对于 2018 年 4 月 30 日之后颁发的所有新证书，Chrome 将要求通过证书透明度公开证书。如果在此日期之后颁发证书，并且证书和站点均不支持 CT，则这些证书将因不可信而被拒绝，并且连接将被阻止。在加载主页的情况下，用户将看到全页证书警告页面，并带有错误代码net::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED。如果您收到此错误，则表明您的 CA 尚未采取措施确保您的证书支持 CT，您应该联系 CA 的销售或支持团队以确保您可以获得有效的替换证书。

域名隐私

通过向 CT 日志披露证书来支持 CT，意味着证书的完整内容将可供公开访问和查看。特别是，这意味着证书所属的域以及它们所属的组织将包含在证书透明度日志中，前提是它们的验证级别高于域验证或由组织特定的 CA 颁发。

注意：有趣的是，RFC 6292定义为实验性的

至于时间开始日期 2018 年 5 月 1 日，Chromium 代码中有特定的硬编码实例（Chrome 常见），定义了过渡中 Chrome/Chromium 代码中将出现的截止日期年。这解释了 2018 年 5 月 1 日之前颁发的证书的不同行为。

来自 services/network/network_context.cc：

1525         // For old certificates (issued before 2018-05-01),
1526         // CheckCTRequirements() may return CT_NOT_REQUIRED, so we check the
1527         // compliance status here.
1528         // TODO(https://crbug.com/851778): Remove this condition once we require
1529         // signing certificates to have CanSignHttpExchanges extension, because
1530         // such certificates should be naturally after 2018-05-01.
1531         if (ct_verify_result.policy_compliance ==
1532                 net::ct::CTPolicyCompliance::CT_POLICY_COMPLIES_VIA_SCTS ||
1533             ct_verify_result.policy_compliance ==
1534                 net::ct::CTPolicyCompliance::CT_POLICY_BUILD_NOT_TIMELY) {
1535           ct_verify_result.policy_compliance_required = true;
1536           break;
1537         }

来自组件/certificate_transparency/chrome_ct_policy_enforcer.cc：

217   // ... AND there is at least one embedded SCT from a Google Log once or
218   //   currently qualified;
219   // AND there is at least one embedded SCT from a non-Google Log once or
220   //   currently qualified;
221   // ...
222   //
223   // Note: This policy language is only enforced after the below issuance
224   // date, as that's when the diversity policy first came into effect for
225   // SCTs embedded in certificates.
226   // The date when diverse SCTs requirement is effective from.
227   // 2015-07-01 00:00:00 UTC.
228   const base::Time kDiverseSCTRequirementStartDate =
229       base::Time::UnixEpoch() + base::TimeDelta::FromSeconds(1435708800);
230   if (issuance_date >= kDiverseSCTRequirementStartDate &&
231       !(has_embedded_google_sct && has_embedded_nongoogle_sct)) {
232     // Note: This also covers the case for non-embedded SCTs, as it's only
233     // possible to reach here if both sets are not diverse enough.
234     return CTPolicyCompliance::CT_POLICY_NOT_DIVERSE_SCTS;
235   }

Adenda：基于我在进行调查后发现的一些内容，详细信息如下：Chrome Linux 未显示 X.509 扩展、SCT

SCT 扩展https://www.digicert.com

数字证书

OCSP 定义https://www.multicert.com

多重证书

相关内容