NET::ERR_CERT_REVOKED in Chrome, when the certificate is not actually revoked NET::ERR_CERT_REVOKED in Chrome, when the certificate is not actually revoked google-chrome google-chrome

NET::ERR_CERT_REVOKED in Chrome, when the certificate is not actually revoked


Not sure what it all means, but the answer is there:

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

and

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

Google revoked a Symantec certificate from Google products, but they have suspended the revocation following the type of issues you're describing (which I also experienced). Quoting the Chromium ticket:

First, the good news is the change has been temporarily reverted, and you should find access restored. You can force an update by going to chrome://components and under CRLSet, clicking "Update". You should have version 2698 or later to fix this issue.


To answer the second part of the question, i.e. why Chrome finds a different trust path than the others.

The server is actually sending the following certificates to the client:

www.evernote.com18:A9:E9:D2:F7:F4:D9:A1:40:23:36:D0:F0:6F:DC:91Symantec Class 3 Secure Server CA - G451:3F:B9:74:38:70:B7:34:40:41:8D:30:93:06:99:FFVeriSign Class 3 Public Primary Certification Authority - G525:0c:e8:e0:30:61:2e:9f:2b:89:f7:05:4d:7c:f8:fd

Note that the serial number on the last certificate is different to both serial numbers you have in your text, which means that there are several certificates with the same subject and public key out there which all can be used to built the trust chain.

Depending on the certificates you have installed in your system and the SSL stack used for validation different trust path are possible. For instance with openssl 1.0.1 on Ubuntu 14.04 it will also use the longer trust path you've seen with Chrome, i.e. the one which ends with the locally installed CA "Class 3 Public Primary Certification Authority". With OpenSSL 1.0.2 the handling of multiple trust path was changed and it will now prefer the shorter path which actually ignores the "VeriSign Class 3 Public Primary Certification Authority - G5" sent by the server and instead ends the trust chain in the locally installed version of a similar certificate (same public key and subject, different serial number).

The version of Chrome you've used had the specific Symantec certificate removed and now one of the possible trust path contains a revoked certificate, which means that the path cannot be trusted any longer. The bug is probably that Chrome then uses this result as the final result instead of looking for a different trust path which still would be valid.