NET :: ERR_CERT_REVOKED、Chromeで、証明書が実際に取り消されていない場合
Chrome46.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クラス3パブリックプライマリCAは、Chromeでほぼ同じようですが、自己署名の代わりに、まったく同じように見えますが、この他の人によって署名されたものに置き換えられますChromeの「ビルトインオブジェクトトークン」...これはどういう意味ですか？それは私が経験している問題と何か関係があるのでしょうか？
UPDATE：
質問の最初の部分は以下で回答されています。最近サイトが機能しなくなった理由は、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を取得することで修正できます。
ただし、質問の2番目の部分は残ります。
Chrome証明書チェーンの取得元は？
Firefox、openssl、および https://www.digicert.com/help/ 、すべてこの同じチェーンを示します。
VeriSignクラス3パブリックプライマリ認証局-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 "証明書はすでにどこかの証明書ストアにあります。CNと" Authority Key Identifier "は"良い "バージョンとまったく同じですが、Chromeによって信頼されなくなったCAを参照しています。 ChromeとFirefox。これらは同一であり、同じ秘密鍵を使用して生成する必要があります（または、両方ともSymantec証明書の署名を正しく検証しません） 、一方は自己署名（良いもの）で、もう一方は自己署名（悪いもの）ではありません。
だから、この証明書ストア/キャッシュはどこにありますか？Chromeが使用していますか？それは内部ですか、Ubuntuではシステム全体ですか？このキャッシュを見つけてクリアした場合、私はかなり確信しています、www.evernote.comは次のTLSハンドシェイク中に完全な証明書チェーンを送信し、すべてが正しいことを確認します（これは私の理論をサポートしているようです： https://security.stackexchange.com/questions/37409/証明書チェーンチェック ）。
しかし、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で[更新]をクリックして、更新を強制できます。この問題を修正するには、バージョン2698以降が必要です。
質問の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「クラス3パブリックプライマリ認証局」で終わるパスも使用します。 OpenSSL 1.0.2では、複数の信頼パスの処理が変更され、サーバーから送信された「VeriSign Class 3 Public Primary Certification Authority-G5」を実際に無視する短いパスが優先され、代わりにローカルにインストールされた信頼チェーンが終了します同様の証明書のバージョン（同じ公開キーとサブジェクト、異なるシリアル番号）。
Chromeのバージョンでは特定のシマンテック証明書が削除されていたため、考えられる信頼パスの1つに失効した証明書が含まれています。これは、パスを信頼できないことを意味します。おそらく、Chromeは、有効な別の信頼パスを探す代わりに、この結果を最終結果として使用します。