title: NET::ERR_CERT_REVOKED in Chrome, when the certificate is not actually revoked
body: <p>I am looking for some help, trying to satisfy my curiosity by figuring out why <code>Chrome</code> <em>46.0.2490.80</em> won't let me access <a href="https://www.evernote.com" rel="nofollow noreferrer">https://www.evernote.com</a>, while Firefox works fine. Chrome was working fine too, until 2 days ago, but now it  throws the NET::ERR_CERT_REVOKED error.</p>
  
  <p>So I got curious - is the certificate actually revoked? Well let's check...</p>
  
  <p>I opened the certificate dialog and exported the certificate (evernote.pem), and it's issuer chain (evernote-chain.pem):
  <a href="https://i.stack.imgur.com/aphpK.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/aphpK.png" alt="enter image description here"></a></p>
  
  <p><a href="https://i.stack.imgur.com/JulcR.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/JulcR.png" alt="enter image description here"></a></p>
  
  <p>Grab the OCSP Responder URI from the certificate:</p>
  
  <pre><code>$ openssl x509 -noout -ocsp_uri -in evernote.pem
  http://ss.symcd.com 
  </code></pre>
  
  <p>Let's check the certificate status now:</p>
  
  <pre><code>$ 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
  </code></pre>
  
  <p>So, the certificate is not revoked, which is why Firefox works correctly. So what's going on with Chrome? Why does it think that this certificate is revoked?</p>
  
  <p>I did notice another detail, which may or may not be important - I don't really understand it. The chain of certificates in Chrome is different from the chain obtained from Firefox, or from openssl. Chrome is seeing the following chain:</p>
  
  <pre><code>|- 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
  </code></pre>
  
  <p>Firefox and openssl see this instead:</p>
  
  <pre><code>|- 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
  </code></pre>
  
  <p>I am not sure how to interpret this. It seems VeriSign Class 3 Public Primary CA is <em>almost</em> the same in Chrome, except instead of being self signed, it is replaced with something that looks exactly like it, but signed by this other "Builtin Object Token" in Chrome... What does this mean? Could it have anything to do with the problem I am experiencing?</p>
  
  <p><strong>UPDATE:</strong></p>
  
  <p>The first part of the question has been answered below. The reason why the site stopped working recently is b/c Google decided to distrust the “<code>Class 3 Public Primary CA</code>” root certificate, as explained here:
  <a href="https://googleonlinesecurity.blogspot.ca/2015/12/proactive-measures-in-digital.html" rel="nofollow noreferrer">https://googleonlinesecurity.blogspot.ca/2015/12/proactive-measures-in-digital.html</a></p>
  
  <p>and here: <a href="https://code.google.com/p/chromium/issues/detail?id=570892" rel="nofollow noreferrer">https://code.google.com/p/chromium/issues/detail?id=570892</a></p>
  
  <p>Since the decision was reversed for now, the problem can be fixed by getting the latest CRLSet in chrome://components/</p>
  
  <p>However, the second part of the question remains: </p>
  
  <p><strong>Where is Chrome getting it's certificate chain from?</strong></p>
  
  <p>Firefox, openssl and <a href="https://www.digicert.com/help/" rel="nofollow noreferrer">https://www.digicert.com/help/</a>, all show this same chain:</p>
  
  <pre>
  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
  </pre>
  
  <p>Yet Chrome is using:</p>
  
  <pre><code>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   &lt;- 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
  </code></pre>
  
  <p>The only explanation I can think of is that the "evil" version of the "<code>VeriSign Class 3 Public Primary Certification Authority - G5</code>" certificate is already in my certificate store somewhere. It has exactly the same CN and "Authority Key Identifier" as the "good" version, but it references a CA that is no longer trusted by Chrome. I have verified this assumption by direct comparison of the certificate in question between Chrome and Firefox. They are identical, and must generated using the same private key (or they wouldn't both be correctly verifying the signature on the Symantec cert), but one is self signed (the good one), and the other is not (the evil one).</p>
  
  <p>So where is this certificate store/cache, which Chrome is using? Is it internal, or would it be system wide on Ubuntu? I am pretty sure that if I was to find and clear this cache, www.evernote.com would send me a full certificate chain during the next TLS handshake, and everything would right itself (this seems to support my theory: <a href="https://security.stackexchange.com/questions/37409/certificate-chain-checking">https://security.stackexchange.com/questions/37409/certificate-chain-checking</a>). </p>
  
  <p>But how do I blow away all of my cached certificates in Chrome?</p>