J'ai un site Web qui utilise l'autorisation du certificat client SSL. Tous les certificats clients sont générés à l'aide d'OpenSSL et sont auto-signés. Tout fonctionnait avec tous les navigateurs Web, mais Google Chrome était recommandé, car il utilise le même entrepôt SSL que IE, ce qui facilite l'installation du certificat (clic-clic-mot-de-passe-terminé!) "Chrome 29.0.1547.57 m" personne ne peut accéder à mon serveur Web, même à moi . Erreur Google Chrome uniquement! IE et FF fonctionnent correctement .. L'erreur est: ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED. Idem dans le journal des erreurs du serveur . Avez-vous des suggestions? Le problème est que la plupart des clients ne sont pas familiarisés avec les ordinateurs personnels et ont très peur de cette situation. Donc, les gars de l'assistance téléphonique sont sous la vague d'appels.
Je rencontre la même chose ici avec des systèmes clients Windows7 incapables de s'authentifier avec des certificats clients sur certains de nos systèmes, mais pas sur d'autres. Les serveurs affectés exécutent Apache Tomcat, tandis que les non affectés exécutent IIS7, bien que j’hésite à identifier cette différence en tant que coupable.
Quelqu'un d'autre a vu ça?
MODIFIER:
Je peux éliminer le problème en désactivant TLSv1.2 sur le serveur. Quelqu'un d'autre est-il capable de reproduire cette expérience?
Je serais également intéressé de savoir si quelqu'un d'autre le voit sur autre chose que sur la plate-forme Windows, car c'est le seul endroit où cela se produit ici (même version OSX n'a pas de problème).
EDIT2:
Rapport de bogue Chrome ici: https://code.google.com/p/chromium/issues/detail?id=278370
EDIT3:
Devrait fonctionner à nouveau dans la dernière version stable de Chrome. Chrome 30 aura un correctif plus robuste, mais 29.x devrait également fonctionner maintenant.
Nous rencontrons le même problème. Comme Sean l'a signalé, il semble que Chrome sous Windows XP Négocie TLSv1.2 même si le système d'exploitation ne prend pas en charge SHA-2 (par exemple, SHA-256 ou SHA-384) Fonction de hachage.
Nous avons constaté que Chrome échouait lorsqu'il recevait une "demande de certificat client" à la suite de SERVER HELLO . SERVER HELLO lui-même négocie RC4-SHA1 (dans notre environnement), ce qui devrait aboutir. Le paquet problématique Semble être la "demande de certificat client" qui inclut les fonctions SHA-2 (ainsi que SHA1) pour les hachages.
L'appel de Chrome avec "--enable-logging --log-level = 0" génère le message suivant: ERREUR: nss_ssl_util.cc (193)] ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED: erreur NSS -12222, erreur OS -2146893816.
Ceci est une erreur du système d'exploitation correspondant à "NTE_BAD_ALGID" pour la fonction CryptSignHash: http://msdn.Microsoft.com/en-us/library/windows/desktop/aa380280(v=vs.85).aspx
Désactiver TLSv1.2 sur le serveur devrait résoudre le problème. Mais je pense que Chrome devrait préférer SHA1 sur Windows XP.
Le problème est dû à l'exécution de TLSv1.2 par Chrome sur Windows XP.
Cela peut être désactivé côté serveur mais également côté client.
Pour exécuter Chrome avec une version inférieure de TLS, démarrez-le avec l'option de ligne de commande --ssl-version-max = tls1.1
C’est une combinaison de Win XP et de Google Chrome 29.0.1547.57 m Sur Win 7/8, ce problème ne se produit pas.
Vous pouvez installer une version de travail plus ancienne 28.0.1500.95 http://www.filehippo.com/download_google_chrome/15657/
Toutefois, les paramètres de désactivation de la mise à jour ne sont pas si faciles . http://dev.chromium.org/administrators/turning-off-auto-updates
J'ai eu ce problème lors de la connexion de Chrome avec WebSockets à Apache.
Ma solution configurait httpd.conf
ProxyPass /wss2/ ws://127.0.0.1:8080/ retry=0 keepalive=On
ProxyPassReverse /wss2/ ws://127.0.0.1:8080/ retry=0
<Location /wss2/>
SSLRequireSSL On
SSLVerifyClient none
SSLVerifyDepth 1
SSLOptions +StdEnvVars +StrictRequire
SSLRenegBufferSize 10486000
</Location>
Chrome WebSockets n'aime pas le paramètre SSLVerifyClient facultatif
J'espère que ça aide.