去年年底，CA/浏览器论坛决定限制 2015 年 4 月 1 日之后颁发的 TLS/SSL 证书的最长有效期。在此之后，正如官方指南所说。
CA 不得颁发有效期超过 39 个月的证书。
我最近（重新）颁发了有效期为2015-04-07 08:57:25 GMTto的证书2018-07-09 07:00:18 GMT。对我来说，这看起来很像 39 个月零 2 天，但我使用的每 一个 SSL 检查器 都说它完全有效。它在 Firefox 37.0.1 和 Internet Explorer 11.0.9600 中也能正常工作。
问题是，Chrome 给了我一个NET::ERR_CERT_VALIDITY_TOO_LONG错误，我倾向于同意这一点。这发生在版本 42.0.2311.68 m 和 44.0.2360.0 canary（64 位）中。
这是证书的问题还是 Chrome 中的错误？
更具体地说，出于 TLS/SSL 证书的目的，应该如何计算“月”？
请注意，这不应该与Chrome 42中发生的 SHA-1 签名证书的停用有关，新证书肯定是使用 SHA256 签名的。
应该注意的是，从 TLS 或 x509 的角度来看，证书没有任何问题。CA/浏览器论坛适用于发布订阅这些指南的公众信任证书的 CA。并非所有 TLS 或 x509 用例都涉及公共信任。
例如，内部政府或企业 CA 可能会合理地选择完全忽略这些准则。事实上，如果 Chrome 将这些规则严格应用于非公开证书，这有点与 x509v3 相矛盾：
在某些情况下，设备会获得无法为其分配好的到期日期的证书。例如，可以为设备颁发证书，将其型号和序列号与其公钥绑定；此类证书旨在用于设备的整个生命周期。
显然 Chrome 没有义务接受此类证书，但它们仍然是合法类型的证书。想要信任自己的 Intranet CA（例如 Active Directory）的 Intranet 用户可能会发现 Chrome 会根据与他们无关的要求阻止他们这样做，因为他们没有订阅 CA/Browser 论坛。
说 x509v3 证书无效是不正确的，因为在一般情况下它的有效期很长。
说 x509v3 证书无效是正确的，因为当它由预期符合 CAB 要求的 CA 颁发并由预期符合 CAB 的用户代理使用时，它的到期日期很长要求。
因此，重要的是要认识到，没有确定 CA 是否应该符合 CAB 的内在技术机制。因此，浏览器可以选择：
a) 假设订阅 CA/浏览器论坛的 CA 符合要求，如果 CA 出于任何原因不符合要求，则接受误报。
b) 在任何情况下都积极拒绝不符合要求的证书，无论 CA 是谁，强加 CAB 风格的要求，即使它们可能是有害的。
我认为两者都不是错误的（除非有一点 CAB 对浏览器施加了义务，否则我不能声称已经逐字记住了整个事情- 请参阅附录）。正确的是您使用的 SSL 测试仪不会拒绝证书，因为证书本身就是无效的。没有任何上下文，说它们无效是错误的。
那么，您所描述的结果正是人们对这些要求的期望以及对“这是证书问题还是 Chrome 中的错误”问题的答案。是，在我看来，证书，因为它是由一个订阅 CAB 论坛的 CA 颁发的，该 CA 未能以明确的方式履行其义务，迫使浏览器自己决定是否通过否决来强制执行这些义务或不。
附录：
这些要求对认证机构来说不是强制性的，除非并且直到它们被依赖方应用软件供应商采纳和执行。
Chrome（一个依赖方应用程序软件...... zzzz）已经采用并正在执行它，因此根据法律条文，我们可以断言对于处理公共信任证书并订阅 CAB 的 CA 是强制性的论坛要求创建符合此要求的证书。
（除非我们过于迂腐，在这种情况下它是复数形式，我们实际上需要 2 个以上的浏览器来执行它，因为否则 Chrome 只是一个依赖方应用程序软件供应商，而不是 Suppliers 。）
我认为有趣的是，CA 的义务实际上必然会根据每个供应商的个别实施细节而改变。每当网络浏览器或与全球任何地方的 CAB 相关联的任何软件突然更新时，CA 可能必须实现他们以前没有的要求。
因此，除非它在 Chrome 中失败，否则 CA 没有义务遵守。当 Chrome 被修补以开始抛出此错误时，CA 违反了他们的义务。惊喜，MF！