NET::ERR_CERT_REVOKED in Chrome，当证书实际上没有被吊销时
NET::ERR_CERT_REVOKED in Chrome, when the certificate is not actually revoked
我正在寻求帮助，试图通过弄清楚为什么 Chrome 46.0.2490.80 不允许我访问 https://www.evernote.com 来满足我的好奇心, 而 Firefox 工作正常。 Chrome 也工作正常，直到 2 天前，但现在它抛出 NET::ERR_CERT_REVOKED 错误。
所以我很好奇 - 证书真的被吊销了吗？好吧，让我们检查一下...
我打开了证书对话框并导出了证书（evernote.pem），以及它的颁发者链（evernote-chain.pem）：
从证书中获取 OCSP 响应程序 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 Public Primary CA almost 与 Chrome 相同，除了不是自签名，它被替换为看起来一模一样，但是在 Chrome 中由另一个 "Builtin Object Token" 签名...这是什么意思？这与我遇到的问题有什么关系吗？
更新：
下面已经回答了问题的第一部分。该站点最近停止工作的原因是 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
我能想到的唯一解释是“VeriSign Class 3 Public Primary Certification Authority - G5”证书的 "evil" 版本已经在我的证书存储区的某个地方。它具有与 "good" 版本完全相同的 CN 和 "Authority Key Identifier"，但它引用的 CA 不再受 Chrome 信任。我通过直接比较 Chrome 和 Firefox 之间的相关证书验证了这个假设。它们是相同的，并且必须使用相同的私钥生成（否则它们不会都正确验证 Symantec 证书上的签名），但一个是自签名的（好的），另一个不是（邪恶的） ).
那么 store/cache 正在使用的 store/cache 证书在哪里？它是内部的，还是 Ubuntu 上的系统范围？我很确定，如果我要找到并清除此缓存，www.evernote.com 会在下一次 TLS 握手期间向我发送完整的证书链，一切都会自行恢复（这似乎支持我的理论：https://security.stackexchange.com/questions/37409/certificate-chain-checking).
但是我如何清除 Chrome 中所有缓存的证书？
不确定这一切意味着什么，但答案就在那里：
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 或更高版本来解决这个问题。
回答问题的第二部分，即为什么 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
请注意，最后一个证书上的序列号与您文本中的两个序列号不同，这意味着有多个证书具有相同的主题和 public 密钥，它们都可以是用于构建信任链。
根据您在系统中安装的证书和用于验证的 SSL 堆栈，可能存在不同的信任路径。例如，对于 Ubuntu 14.04 上的 openssl 1.0.1，它还将使用您在 Chrome 中看到的更长的信任路径，即以本地安装的 CA "Class 3 Public Primary Certification Authority" 结尾的路径。在 OpenSSL 1.0.2 中，多信任路径的处理发生了变化，它现在更喜欢较短的路径，它实际上忽略了服务器发送的 "VeriSign Class 3 Public Primary Certification Authority - G5"，而是在本地安装的类似证书版本中结束信任链（ public 密钥和主题相同，序列号不同）。
您使用的 Chrome 版本删除了特定的 Symantec 证书，现在可能的信任路径之一包含已吊销的证书，这意味着该路径不再受信任。该错误可能是 Chrome 然后使用此结果作为最终结果，而不是寻找仍然有效的不同信任路径。
我正在寻求帮助，试图通过弄清楚为什么 Chrome 46.0.2490.80 不允许我访问 https://www.evernote.com 来满足我的好奇心, 而 Firefox 工作正常。 Chrome 也工作正常，直到 2 天前，但现在它抛出 NET::ERR_CERT_REVOKED 错误。
所以我很好奇 - 证书真的被吊销了吗？好吧，让我们检查一下...
我打开了证书对话框并导出了证书（evernote.pem），以及它的颁发者链（evernote-chain.pem）：
从证书中获取 OCSP 响应程序 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 Public Primary CA almost 与 Chrome 相同，除了不是自签名，它被替换为看起来一模一样，但是在 Chrome 中由另一个 "Builtin Object Token" 签名...这是什么意思？这与我遇到的问题有什么关系吗？
更新：
下面已经回答了问题的第一部分。该站点最近停止工作的原因是 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
我能想到的唯一解释是“VeriSign Class 3 Public Primary Certification Authority - G5”证书的 "evil" 版本已经在我的证书存储区的某个地方。它具有与 "good" 版本完全相同的 CN 和 "Authority Key Identifier"，但它引用的 CA 不再受 Chrome 信任。我通过直接比较 Chrome 和 Firefox 之间的相关证书验证了这个假设。它们是相同的，并且必须使用相同的私钥生成（否则它们不会都正确验证 Symantec 证书上的签名），但一个是自签名的（好的），另一个不是（邪恶的） ).
那么 store/cache 正在使用的 store/cache 证书在哪里？它是内部的，还是 Ubuntu 上的系统范围？我很确定，如果我要找到并清除此缓存，www.evernote.com 会在下一次 TLS 握手期间向我发送完整的证书链，一切都会自行恢复（这似乎支持我的理论：https://security.stackexchange.com/questions/37409/certificate-chain-checking).
但是我如何清除 Chrome 中所有缓存的证书？
不确定这一切意味着什么，但答案就在那里：
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 或更高版本来解决这个问题。
回答问题的第二部分，即为什么 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
请注意，最后一个证书上的序列号与您文本中的两个序列号不同，这意味着有多个证书具有相同的主题和 public 密钥，它们都可以是用于构建信任链。
根据您在系统中安装的证书和用于验证的 SSL 堆栈，可能存在不同的信任路径。例如，对于 Ubuntu 14.04 上的 openssl 1.0.1，它还将使用您在 Chrome 中看到的更长的信任路径，即以本地安装的 CA "Class 3 Public Primary Certification Authority" 结尾的路径。在 OpenSSL 1.0.2 中，多信任路径的处理发生了变化，它现在更喜欢较短的路径，它实际上忽略了服务器发送的 "VeriSign Class 3 Public Primary Certification Authority - G5"，而是在本地安装的类似证书版本中结束信任链（ public 密钥和主题相同，序列号不同）。
您使用的 Chrome 版本删除了特定的 Symantec 证书，现在可能的信任路径之一包含已吊销的证书，这意味着该路径不再受信任。该错误可能是 Chrome 然后使用此结果作为最终结果，而不是寻找仍然有效的不同信任路径。