Подтвердить что ты не робот

ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED в Google Chrome

У меня есть веб-сайт, на котором используется авторизация сертификата SSL-клиента. Все клиентские сертификаты создаются с использованием OpenSSL и самозаверяются. Все работало со всеми веб-браузерами, но рекомендуемым был Google Chrome, поскольку он использует тот же SSL-хранилище, что и IE, поэтому установка сертификата была довольно простой (клик-клик-пароль-сделано!). После последнего обновления Google "Chrome 29.0.1547.57 м" никто не может получить доступ к моему веб-серверу, даже мне. Только ошибка Google Chrome! IE и FF работают нормально. Ошибка: ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED. То же самое в журнале ошибок сервера. Есть ли у вас какие-либо предложения? Проблема в том, что большинство клиентов не знакомы с ПК, и они очень испугались этой ситуации. Поэтому парни поддержки телефонов находятся под волной звонков.

4b9b3361

ОТВЕТЫ

Ответ 1

Я испытываю то же самое здесь, когда клиентские системы Windows7 не могут аутентифицироваться с сертификатами клиентов в отношении некоторых наших систем, но не для других. На затронутых серверах работает Apache Tomcat, в то время как незатронутые работают с IIS7, хотя я не решаюсь идентифицировать эту разницу в качестве виновника.

Кто-нибудь еще видит это?

EDIT:

Я могу устранить проблему, отключив TLSv1.2 на сервере. Кто-нибудь еще может повторить этот опыт?

Мне также было бы интересно узнать, видит ли кто-нибудь еще это на чем-либо, кроме платформы Windows, поскольку это единственное место, которое здесь происходит (в той же версии OSX нет проблем).

EDIT2:

Отчет об ошибке Chrome здесь: https://code.google.com/p/chromium/issues/detail?id=278370

EDIT3:

Должен работать снова в последней стабильной Chrome. Chrome 30 будет иметь более надежное исправление, но 29.x также должен работать.

Ответ 2

Мы сталкиваемся с той же проблемой. Как сообщил Шон, кажется, что Chrome на Windows XP согласовывает TLSv1.2, даже если операционная система не поддерживает SHA-2 (скажем, SHA-256 или SHA-384) хэш-функции.

Мы обнаружили, что Chrome терпит неудачу, когда он получает запрос "запрос клиента" после SERVER HELLO. SERVER HELLO сам ведет переговоры с RC4-SHA1 (в нашей среде), который должен преуспеть. Проблематичный пакет представляет собой "запрос сертификата клиента", который включает функции SHA-2 (а также SHA1) для хэшей.

Вызов Chrome с "--enable-logging -log-level = 0" выводит следующее сообщение: ОШИБКА: nss_ssl_util.cc(193)] ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED: ошибка NSS -12222, ошибка ОС -2146893816

Это ошибка операционной системы, соответствующая "NTE_BAD_ALGID" для функции CryptSignHash: http://msdn.microsoft.com/en-us/library/windows/desktop/aa380280(v=vs.85).aspx

Отключение TLSv1.2 на сервере должно устранить проблему. Но я думаю, что Chrome должен предпочесть SHA1 в Windows XP.

Ответ 4

Проблема вызвана тем, что Chrome работает с TLSv1.2 в Windows XP.

Это может быть отключено на стороне сервера, но также и на стороне клиента.

Чтобы запустить Chrome с более низкой версией TLS, запустите его с помощью командной строки --ssl-version-max = tls1.1

Ответ 5

У меня была эта проблема. Подключение Chrome с помощью WebSockets к apache throw proxy_wstunnel_module.

Мое решение заключалось в настройке 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 не нравится параметр SSLVerifyClient необязательный

Надеюсь, это поможет.