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

给定 OID .1.3.6.1.4.1.1.11129.2.4.2，我发现了一篇相关的 Let's Encrypt 文章Engineering deep dive: Encoding of SCTs in certificate

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

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

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

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

我们写信是为了重申即将在 2018 年 4 月在 Chrome 中实施证书透明度 (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 颁发的证书不受此要求的约束。

发生了什么，何时发生？

Chrome 将要求 2018 年 4 月 30 日之后颁发的所有 TLS 服务器证书都符合 Chromium CT 政策。在此日期之后，当 Chrome 连接到提供不符合 Chromium CT 政策的公共信任证书的网站时，用户将开始看到一个完整的页面插页式广告，表明他们的连接不符合 CT 标准。通过不符合 CT 的 https 连接提供的子资源将无法加载，并将在 Chrome DevTools 中显示错误。强烈鼓励 CA 与他们的客户合作，以​​确保他们的 TLS 证书在 3 月底之前通过 RFC 6962 第 3.3 节 [6] 中指定的三种方式中的任何一种准备好遵守 Chromium CT 政策，以确保任何部署问题CT 支持在执行截止日期之前解决。

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

来自Chrome 2018 年 4 月之后需要 CT

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

• 通过 TLS 扩展提供来自在检查时合格的日志的签名证书时间戳 (SCT)，或者嵌入在装订的 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 扩展从主机传送到连接的客户端。这发生在使用名为 signed_certificate_timestamp 的扩展的 TLS 握手期间，但确实需要主机更新其服务器并将其配置为传递 SCT。这里的好处是 CA，他们不必改变他们颁发证书的方式，但是等待 SCT TLS 扩展的可靠服务器实现对于站点运营商来说可能不是很好。

OCSP 装订

我是 OCSP 装订的粉丝，它通常用于提供有关我们证书的吊销信息，但它也可用于将 SCT 从 CA 提供给站点运营商。CA 再次受益，因为他们不必更改其颁发过程，他们只需照常签署和颁发证书，并通过 OCSP 提供 SCT。不过，这对我们来说也是个问题，因为我们的服务器需要能够可靠地进行 OCSP 装订，并在握手期间将 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
  

  并重新启动 Apache。

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

另请参阅Chrome Linux 未显示 X.509 扩展、SCT

更多技术细节

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

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

对于那些对证书透明度功能感兴趣的人，更有趣的目录似乎是 components/certificate_transparency/最有趣的 doc 文件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 逐渐要求越来越多的公共信任证书需要证书透明度。

• 自 2015 年 1 月 1 日起，Chrome 要求所有扩展验证证书都必须通过 Certificate Transparency 进行披露。未正确披露的证书将被剥夺其 EV 状态，但不会向不遵守规定的网站的访问者显示警告。

• 自 2016 年 6 月 1 日起，Chrome 要求所有由 Symantec Corporation 拥有的根证书集颁发的新证书都必须通过 Certificate Transparency 披露。未公开或未以符合 RFC 6962 的方式公开的证书将被视为不受信任而被拒绝。

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

域隐私

通过将证书公开到 CT 日志来支持 CT 意味着证书的全部内容将可公开访问和查看。特别是，这意味着证书所针对的域将包含在证书透明度日志中，以及它们所属的组织，如果它们的验证级别高于域验证或由特定于组织的 CA 颁发.

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

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

从服务/网络/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 is not shown an X.509 Extension, SCT

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

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