NET :: ERR_CERT_REVOKED dans Chrome, lorsque le certificat n'est pas réellement révoqué
Je cherche de l'aide, essayant de satisfaire ma curiosité en découvrant pourquoi Chrome 46.0.2490.80 ne me laissera pas accéder https: // www. evernote.com , tandis que Firefox fonctionne très bien. Chrome fonctionnait également très bien, jusqu'à il y a 2 jours, mais maintenant, il génère l'erreur NET :: ERR_CERT_REVOKED.
Je suis donc devenu curieux - le certificat est-il révoqué? Eh bien, vérifions ...
J'ai ouvert la boîte de dialogue du certificat et exporté le certificat (evernote.pem), et sa chaîne émettrice (evernote-chain.pem): 
Récupérez l'URI du répondeur OCSP dans le certificat:
$ openssl x509 -noout -ocsp_uri -in evernote.pem
http://ss.symcd.com
Vérifions maintenant le statut du certificat:
$ 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
Ainsi, le certificat n'est pas révoqué, c'est pourquoi Firefox fonctionne correctement. Alors, que se passe-t-il avec Chrome? Pourquoi pense-t-il que ce certificat est révoqué?
J'ai remarqué un autre détail, qui peut être important ou non - je ne le comprends pas vraiment. La chaîne de certificats dans Chrome est différente de la chaîne obtenue à partir de Firefox ou de openssl. Chrome voit la chaîne suivante:
|- 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 et openssl voient ceci à la place:
|- 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
Je ne sais pas comment interpréter cela. Il semble que l'autorité de certification primaire publique VeriSign Class 3 soit presque identique dans Chrome, sauf qu'au lieu d'être auto-signé, il est remplacé par quelque chose qui lui ressemble exactement, mais signé par cet autre "objet intégré" Token "dans Chrome ... Qu'est-ce que cela signifie? Cela pourrait-il avoir quelque chose à voir avec le problème que je rencontre?
MISE À JOUR:
La première partie de la question a été répondue ci-dessous. La raison pour laquelle le site a cessé de fonctionner récemment est que b/c Google a décidé de se méfier du "Class 3 Public Primary CA ”Certificat racine, comme expliqué ici: https://googleonlinesecurity.blogspot.ca/2015/12/proactive-measures-in-digital.html
et ici: https://code.google.com/p/chromium/issues/detail?id=570892
Étant donné que la décision a été inversée pour l'instant, le problème peut être résolu en obtenant le dernier CRLSet dans chrome: // components /
Cependant, la deuxième partie de la question demeure:
Où se trouve Chrome d'où provient sa chaîne de certificats?
Firefox, openssl et https://www.digicert.com/help/ , montrent tous cette même chaîne:
Autorité de certification primaire publique VeriSign classe 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
Pourtant Chrome utilise:
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
La seule explication à laquelle je peux penser est que la version "diabolique" du "VeriSign Class 3 Public Primary Certification Authority - G5 "le certificat se trouve déjà quelque part dans mon magasin de certificats. Il a exactement le même CN et" Authority Key Identifier "que la" bonne "version, mais il fait référence à une autorité de certification qui n'est plus approuvée par Chrome. J'ai vérifié cette hypothèse en comparaison directe du certificat en question entre Chrome et Firefox. Ils sont identiques et doivent être générés à l'aide de la même clé privée (sinon ils ne vérifieraient pas correctement la signature sur le certificat Symantec)) , mais l'un est auto-signé (le bon), et l'autre ne l'est pas (le mauvais).
Alors, où est ce magasin/cache de certificats, qui Chrome utilise? Est-il interne, ou serait-il à l'échelle du système sur Ubuntu? Je suis sûr que si je devais trouver et effacer ce cache , www.evernote.com m'enverrait une chaîne de certificats complète lors de la prochaine prise de contact TLS, et tout irait bien (cela semble soutenir ma théorie: https://security.stackexchange.com/questions/37409/ certificat-chaîne-vérification ).
Mais comment puis-je supprimer tous mes certificats mis en cache dans Chrome?
Je ne sais pas ce que tout cela signifie, mais la réponse est là:
https://code.google.com/p/chromium/issues/detail?id=570892
et
https://googleonlinesecurity.blogspot.ca/2015/12/proactive-measures-in-digital.html
Google a révoqué un certificat Symantec des produits Google, mais ils ont suspendu la révocation suite au type de problèmes que vous décrivez (ce que j'ai également rencontré). Citant le billet Chromium:
Premièrement, la bonne nouvelle est que la modification a été temporairement annulée et que l'accès devrait être restauré. Vous pouvez forcer une mise à jour en accédant aux composants chrome: // et sous CRLSet, en cliquant sur "Mettre à jour". Vous devez avoir la version 2698 ou ultérieure pour résoudre ce problème.
Pour répondre à la deuxième partie de la question, c'est-à-dire pourquoi Chrome trouve un chemin de confiance différent des autres.
Le serveur envoie en fait les certificats suivants au client:
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
Notez que le numéro de série sur le dernier certificat est différent des deux numéros de série que vous avez dans votre texte, ce qui signifie qu'il existe plusieurs certificats avec le même sujet et la même clé publique que tous peuvent être utilisés pour construire la chaîne de confiance.
Selon les certificats que vous avez installés dans votre système et la pile SSL utilisée pour la validation, différents chemins de confiance sont possibles. Par exemple, avec openssl 1.0.1 sur Ubuntu 14.04, il utilisera également le chemin de confiance plus long que vous avez vu avec Chrome, c'est-à-dire celui qui se termine par l'autorité de certification CA "Classe 3 Public Primary Certification Authority" installée localement. Avec OpenSSL 1.0.2, la gestion des chemins d'accès de confiance multiples a été modifiée et il préférera désormais le chemin plus court qui ignore en fait la "VeriSign Class 3 Public Primary Certification Authority - G5" envoyée par le serveur et termine à la place la chaîne de confiance dans l'installation locale version d'un certificat similaire (même clé publique et même sujet, numéro de série différent).
La version de Chrome que vous avez utilisée a fait supprimer le certificat Symantec spécifique et maintenant l'un des chemins de confiance possibles contient un certificat révoqué, ce qui signifie que le chemin ne peut plus être approuvé. Le bogue est probablement que Chrome utilise alors ce résultat comme résultat final au lieu de chercher un chemin de confiance différent qui serait toujours valide.