ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED w Google Chrome

Question

Mam stronę internetową, która korzysta z autoryzacji SSL klienta. Wszystkie certyfikaty klienta są generowane przy użyciu OpenSSL i są samopodpisane. Wszystko działało ze wszystkimi przeglądarkami internetowymi, ale zalecanym był Google Chrome, ponieważ używa tego samego magazynu SSL co IE, więc instalacja certyfikatu była dość łatwa (kliknięcie-hasło-wykonane!). Po ostatniej aktualizacji Google "Chrome 29.0.1547.57 m" nikt nie może uzyskać dostępu do mojego serwera internetowego, nawet ja. Tylko błąd chrome Google! IE i FF działają bez zarzutu. Błąd: ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED. To samo w logu błędów serwera. Czy masz jakieś sugestie? Problem polega na tym, że większość klientów nie zna się na komputerach osobistych i bardzo przestraszyli się tej sytuacji. Więc faceci wsparcia telefonicznego są pod falą połączeń.

Answer 1

Mam takie same problemy z systemami klienckimi Windows7, które nie są w stanie uwierzytelnić się za pomocą certyfikatów klienta w stosunku do niektórych naszych systemów, ale nie do innych. Zainfekowane serwery uruchamiają Apache Tomcat, podczas gdy niezmodyfikowane działają w IIS7, choć nie jestem pewien, czy rozpoznaję tę różnicę jako winowajcę.

Ktoś jeszcze to widział?

EDIT:

jestem w stanie wyeliminować ten problem przez wyłączenie TLSv1.2 na serwerze. Czy ktokolwiek inny jest w stanie powtórzyć to doświadczenie?

Chciałbym również wiedzieć, czy ktokolwiek inny widzi to na czymkolwiek poza platformą Windows, ponieważ jest to jedyne miejsce, w którym to się dzieje (w tej samej wersji OSX nie ma problemów).

EDIT2:

Chrome Bug Report tutaj: https://code.google.com/p/chromium/issues/detail?id=278370

Edit3:

Należy ponownie pracuje w najnowszej stabilnej Chrome. Chrome 30 będzie miał mocniejszą poprawkę, ale 29.x również powinno działać teraz.

Answer 2

Jest to połączenie Win XP i Google Chrome 29.0.1547.57 m W Win 7/8 ten problem nie występuje.

Można zainstalować starszą wersję pracy 28.0.1500.95 http://www.filehippo.com/download_google_chrome/15657/

Ale ustawienia wyłączenie aktualizacji nie są tak łatwe. http://dev.chromium.org/administrators/turning-off-auto-updates

Answer 3

Mamy ten sam problem. Jak donosił Sean, wygląda na to, że Chrome w systemie Windows XP negocjuje protokół TLSv1.2, mimo że system operacyjny nie obsługuje funkcji skrótu SHA-2 (powiedzmy, SHA-256 lub SHA-384) .

Znaleziono błąd przeglądarki Chrome po otrzymaniu "żądania certyfikatu klienta" po SERVER HELLO. SERVER HELLO sam negocjuje RC4-SHA1 (w naszym środowisku), który powinien się powieść. Problematyczny pakiet wydaje się być "żądaniem certyfikatu klienta", które zawiera funkcje SHA-2 (jak również SHA1) dla skrótów.

Wywoływanie chrom z "enable wspomagane --log poziomu = 0", wysyła się komunikat: BŁĄD: nss_ssl_util.cc (193)] ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED: błąd NSS -12222, błąd systemu -2146893816

jest to błąd systemu operacyjnego odpowiada „NTE_BAD_ALGID” dla funkcji CryptSignHash: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380280(v=vs.85).aspx

Wyłączenie TLSv1.2 na serwerze powinno rozwiązać problem. Ale myślę, że Chrome powinien preferować SHA1 w Windows XP.

Answer 4

Problem jest spowodowany uruchomieniem przeglądarki TLSv1.2 w systemie Windows XP.

Można to wyłączyć po stronie serwera, ale także po stronie klienta.

Aby uruchomić Chrome z niższą wersją TLS, należy uruchomić go z opcją wiersza polecenia --ssl-version-max = tls1.1

Answer 5

miałem ten problem z połączeniem Chrome z WebSocket Apache rzutów proxy_wstunnel_module.

Moje roztwór konfiguracji 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 nie lubi SSLVerifyClient parametru opcjonalnego

Mam nadzieję, że to pomaga.