当证书未实际撤销时，Chrome中的NET :: ERR_CERT_REVOKED

Question

我正在寻求一些帮助，试图通过弄清楚为什么Chrome 46.0.2490.80 让我访问https://www.evernote.com来满足我的好奇心，而Firefox工作良好。 Chrome也正常工作，直到2天前，但现在它抛出了NET :: ERR_CERT_REVOKED错误。

所以我很好奇 - 证书真的被撤销了吗？好吧，让我们检查......

我打开证书对话框并导出证书（evernote.pem）及其发行人链（evernote-chain.pem）：

从证书中获取OCSP Responder URI：

$ openssl x509 -noout -ocsp_uri -in evernote.pem
http://ss.symcd.com 

现在让我们检查证书状态：

$ openssl ocsp -no_nonce -issuer evernote-chain.pem -CAfile evernote-chain.pem -cert evernote.pem -url http://ss.symcd.com
Response verify OK
evernote.pem: good
        This Update: Dec 16 09:14:05 2015 GMT
        Next Update: Dec 23 09:14:05 2015 GMT

因此，证书未被撤销，这就是Firefox正常运行的原因。那么Chrome正在发生什么？为什么认为该证书被撤销？

我确实注意到了另一个细节，这些细节可能重要，也可能不重要 - 我不太了解它。 Chrome中的证书链与从Firefox或openssl获得的链不同。 Chrome正在看到以下链：

|- Class 3 Public Primary Certification Authority (Builtin Object Token, self-signed)
|---- VeriSign Class 3 Public Primary Certification Authority - G5 (35:97:31:87:F3:87:3A:07:32:7E:CE:58:0C:9B:7E:DA)
|------- Symantec Class 3 Secure Server CA - G4
|---------- www.evernote.com

Firefox和openssl反而看到了这一点：

|- VeriSign Class 3 Public Primary Certification Authority - G5 (18:DA:D1:9E:26:7D:E8:BB:4A:21:58:CD:CC:6B:3B:4A, self-signed)
|---- Symantec Class 3 Secure Server CA - G4
|------- www.evernote.com

我不确定如何解释这一点。似乎VeriSign Class 3公共主要CA在Chrome中几乎相同，除了不是自签名，它被替换为看起来完全像它的东西，但由另一个＆＃34;内置签名对象令牌＆＃34;在Chrome中......这是什么意思？它与我遇到的问题有什么关系吗？

更新

问题的第一部分已在下面得到解答。该网站最近停止工作的原因是b / c Google决定不信任“Class 3 Public Primary CA”根证书，如下所述： https://googleonlinesecurity.blogspot.ca/2015/12/proactive-measures-in-digital.html

在这里：https://code.google.com/p/chromium/issues/detail?id=570892

由于目前的决定已被撤销，因此可以通过在chrome：// components /

中获取最新的CRLSet来解决问题

然而，问题的第二部分仍然存在：

Chrome从哪里获得证书链？

Firefox，openssl和https://www.digicert.com/help/都显示了相同的链：

VeriSign Class 3 Public Primary Certification Authority - G5
18:DA:D1:9E:26:7D:E8:BB:4A:21:58:CD:CC:6B:3B:4A

Symantec Class 3 Secure Server CA - G4
51:3F:B9:74:38:70:B7:34:40:41:8D:30:93:06:99:FF

www.evernote.com
18:A9:E9:D2:F7:F4:D9:A1:40:23:36:D0:F0:6F:DC:91

但Chrome正在使用：

Class 3 Public Primary Certification Authority
70:BA:E4:1D:10:D9:29:34:B6:38:CA:7B:03:CC:BA:BF
- This is the no longer trusted Root CA

VeriSign Class 3 Public Primary Certification Authority - G5
35:97:31:87:F3:87:3A:07:32:7E:CE:58:0C:9B:7E:DA   <- WTF?!

Symantec Class 3 Secure Server CA - G4
51:3F:B9:74:38:70:B7:34:40:41:8D:30:93:06:99:FF

www.evernote.com
18:A9:E9:D2:F7:F4:D9:A1:40:23:36:D0:F0:6F:DC:91

我能想到的唯一解释是＆＃34;邪恶＆＃34; ＆＃34; VeriSign Class 3 Public Primary Certification Authority - G5＆＃34;的版本证书已经存在于我的证书库中。它具有完全相同的CN和＆＃34;权限密钥标识符＆＃34;作为＆＃34;好＆＃34;版本，但它引用了Chrome不再信任的CA.我已通过直接比较Chrome和Firefox之间的相关证书来验证此假设。它们是相同的，必须使用相同的私钥生成（或者它们都不能正确验证Symantec证书上的签名），但一个是自签名（好的），另一个不是（邪恶的一个）。

那么Chrome正在使用哪个证书存储/缓存？它是内部的，还是Ubuntu的系统范围？我很确定如果我要找到并清除这个缓存，www.evernote.com会在下一次TLS握手期间向我发送完整的证书链，一切都会正确（这似乎支持我的理论：{{3} }）。

但是如何在Chrome中删除所有缓存的证书？

Answer 1

不确定这一切意味着什么，但答案就在那里：

https://code.google.com/p/chromium/issues/detail?id=570892

和

https://googleonlinesecurity.blogspot.ca/2015/12/proactive-measures-in-digital.html

Google撤销了Google产品的赛门铁克证书，但他们已根据您所描述的问题类型（我也遇到过）暂停了撤销。引用Chromium票：

首先，好消息是暂时还原了更改，您应该找到恢复的访问权限。您可以转到chrome：// components并在CRLSet下单击“Update”来强制更新。您应该有2698或更高版本来解决此问题。

Answer 2

回答问题的第二部分，即Chrome为何找到与其他信任路径不同的信任路径。

服务器实际上是将以下证书发送给客户端：

www.evernote.com
18:A9:E9:D2:F7:F4:D9:A1:40:23:36:D0:F0:6F:DC:91

Symantec Class 3 Secure Server CA - G4
51:3F:B9:74:38:70:B7:34:40:41:8D:30:93:06:99:FF

VeriSign Class 3 Public Primary Certification Authority - G5
25:0c:e8:e0:30:61:2e:9f:2b:89:f7:05:4d:7c:f8:fd

请注意，最后一个证书上的序列号与文本中的序列号不同，这意味着有多个具有相同主题和公钥的证书可用于构建信任链。

根据您在系统中安装的证书和用于验证的SSL堆栈，可以使用不同的信任路径。例如，对于Ubuntu 14.04上的openssl 1.0.1，它还将使用您在Chrome中看到的更长的信任路径，即以本地安装的CA“Class 3 Public Primary Certification Authority”结尾的路径。使用OpenSSL 1.0.2，更改了多个信任路径的处理，现在它更喜欢实际忽略服务器发送的“VeriSign Class 3公共主要证书颁发机构 - G5”的较短路径，而是结束本地安装的信任链类似证书的版本（相同的公钥和主题，不同的序列号）。

您使用的Chrome版本删除了特定的Symantec证书，现在可能的信任路径之一包含已撤销的证书，这意味着该路径不再可信任。该错误可能是Chrome然后使用此结果作为最终结果，而不是寻找仍然有效的不同信任路径。