NET::ERR_CERT_REVOKED dans google Chrome, lorsque le certificat n'est pas réellement révoqué
Je suis à la recherche d'un peu d'aide, en essayant de satisfaire ma curiosité de découvrir pourquoi Chrome 46.0.2490.80 ne me laisse pas l'accès https://www.evernote.com, tandis que Firefox fonctionne très bien. Chrome fonctionnait bien, trop, jusqu'à 2 jours, mais maintenant, il jette le NET::ERR_CERT_REVOKED erreur.
Je me suis donc curieux - est, le certificat révoqué? Eh bien nous allons vérifier...
J'ai ouvert la boîte de dialogue certificat et exporter le certificat (evernote.pem), et c'est l'émetteur de la chaîne (evernote-chaîne.pem):
Saisir le Répondeur OCSP URI du certificat:
$ openssl x509 -noout -ocsp_uri -in evernote.pem
http://ss.symcd.com
Nous allons vérifier l'état du certificat maintenant:
$ 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
Donc, le certificat n'est pas révoqué, ce qui est pourquoi Firefox fonctionne correctement. Donc ce qui se passe avec Chrome? Pourquoi ne fait-il penser que ce certificat est révoqué?
J'ai remarqué un détail, qui peut ou peut ne pas être important - je ne comprends pas vraiment. La chaîne de certificats de Chrome est différente de la chaîne obtenue à partir de Firefox, ou d'openssl. Chrome, c'est de voir 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 voir 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 suis pas sûr de la façon de l'interpréter. Il semble VeriSign Class 3 Primaire Publique de CA est presque la même dans Chrome, sauf qu'au lieu d'être auto-signé, il est remplacé par quelque chose qui ressemble exactement, mais signé par cet autre "Builtin Objet Token" dans Chrome... Qu'est-ce que cela signifie? 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épondu ci-dessous. La raison pour laquelle le site a cessé de travail récemment est b/c, Google a décidé de se méfier de la “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
Depuis que la décision a été annulée pour l'instant, le problème peut être résolu par l'obtention de la dernière CRLSet dans chrome://components/
Cependant, la deuxième partie de la question demeure:
Où est-Chrome obtenir le certificat de la chaîne de?
Firefox, openssl et https://www.digicert.com/help/, montrent cette même chaîne:
VeriSign Class 3 Primaire Publique De L'Autorité De Certification - G5 18:DA:D1:9E:26:7D:E8:BB:4A:21:58:CD:CC:6B:3B:4A Symantec Classe 3 Serveur Sécurisé de 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
Encore google 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
La seule explication que je peux penser, c'est que le "mal" version de la "VeriSign Class 3 Public Primary Certification Authority - G5" certificat est déjà dans mon magasin de certificats quelque part. Il a exactement les mêmes CN et "l'Identificateur de Clé d'Autorité", comme la "bonne" version, mais il fait référence à une autorité de certification qui n'est plus approuvé par google Chrome. J'ai vérifié cette hypothèse par comparaison directe de l'attestation en question entre Chrome et Firefox. Ils sont identiques, et doit générées à l'aide de la même clé privée (ou qu'ils ne serait pas à la fois être correctement vérification de la signature sur le Symantec cert), mais une seule est auto-signé (la bonne), et l'autre ne l'est pas (le malin).
Alors, où est-ce magasin de certificats/mémoire cache de Chrome est l'aide? Est-il interne, ou serait-il à l'échelle du système sur Ubuntu? Je suis sûr que si j'étais à trouver et effacer ce cache, www.evernote.com serait de m'envoyer une attestation complète de la chaîne au cours de la prochaine poignée de main TLS, et tout aurait le droit lui-même (ce qui semble à l'appui de ma théorie: https://security.stackexchange.com/questions/37409/certificate-chain-checking).
Mais comment puis-je souffler tous mes certificats mis en cache dans google Chrome?
Tu veux dire l'obtention de la dernière CRLSet dans chrome://components/ ne parvenez pas à résoudre votre problème?
Oui, Il ne résout pas mon problème. soyoustart.com
OriginalL'auteur Val Blant | 2015-12-18
Vous devez vous connecter pour publier un commentaire.
Pas sûr de 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 de retirer un certificat Symantec à partir de produits de Google, mais ils ont suspendu la révocation suivant le type de problèmes que vous décrivez (que j'ai également de l'expérience). Citant le Chrome billet:
Tout d'abord, la bonne nouvelle, c'est que le changement a été temporairement revenue, et vous devriez trouver l'accès restauré. Vous pouvez forcer une mise à jour en allant à la page chrome://composants et sous CRLSet, en cliquant sur "mettre à Jour". Vous devez disposer de la version 2698 ou plus tard pour résoudre ce problème.
CRLSet ne pas mettre à jour quoi que ce soit. J'utilise IIS sertivicate sur localhost. Et le sertificate est ajouté dans chaque endroit possible... Ressemble à Chrome bug est happaning pendant plusieurs années...
OriginalL'auteur Yann
Pour répondre à la deuxième partie de la question, à savoir pourquoi Chrome trouve un autre chemin d'approbation que les autres.
Le serveur est en fait l'envoi des certificats suivants pour le client:
Noter que le numéro de série sur le dernier certificat est différente pour les 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 clé publique, qui peuvent tous être utilisés pour construire la chaîne de confiance.
Selon les certificats que vous avez installé dans votre système et les SSL pile utilisé pour la validation de confiance différents parcours sont possibles. Par exemple, avec openssl 1.0.1 sur Ubuntu 14.04 il utilisera aussi le plus confiance dans le chemin que vous avez vu avec Chrome, c'est à dire celui qui se termine avec le installé en local CA la Classe 3, Principale Autorité de Certification Publique". Avec OpenSSL 1.0.2 la manipulation de plusieurs chemin d'approbation a été modifiée, et préfèrent le plus court chemin qui, de fait, ignore le "VeriSign Class 3 Primaire Publique de l'Autorité de Certification - G5" envoyé par le serveur et au lieu extrémités de la chaîne de confiance dans la version installée localement d'une attestation semblable (même clé publique et sous réserve, le numéro de série différent).
La version de google Chrome, vous avez utilisé spécifiquement Symantec certificat supprimé et maintenant l'un des possibles confiance le chemin d'accès contient un certificat révoqué, ce qui signifie que le chemin ne peut pas faire confiance plus longtemps. Le bug est probablement que Chrome utilise ensuite ce résultat que le résultat final au lieu de chercher un autre chemin d'approbation qui serait encore valable.
OriginalL'auteur Steffen Ullrich