#windows #google-chrome #ssl #https #ssl-certificate
#Windows #google-chrome #ssl #https #ssl-сертификат
Вопрос:
У меня возникла несколько запутанная проблема с самозаверяющим SSL-сертификатом, который Windows признает действительным, но который не принимают современные браузеры.
Сертификат присутствует в системном хранилище сертификатов (доступ к которому осуществляется через оснастку Сертификаты в MMC), в папках Личные и доверенные корневые центры сертификации, и помечен как действительный.
Согласно утилите проверки SSL-сертификата, сертификат и цепочка сертификатов действительны.
Вот его вывод:
**************************************************************************
Processing 'localhost'
**************************************************************************
Scan started: 21-09-2020 13:43:33
Generating connection string...
Connection string is: https://localhost:14006/
Entering certificate validation callback function...
Server returned 1 certificates.
Entering server certificate chain validation function...
Leaf certificate issued to: E=REDACTED, CN=localhost, O=localhost, L=New York, S=NY, C=US
Found Subject Alternative Names extension in the certificate.
Fetching SAN values:
DNS Name=localhost
DNS Name=127.0.0.1
DNS Name=::1
IP Address=0000:0000:0000:0000:0000:0000:0000:0001
IP Address=127.0.0.1
Certificate chain successfully passed all checks.
Finished!
Scan ended: 21-09-2020 13:43:33
Если я попытаюсь получить доступ к службе с помощью Internet Explorer или curl , я получаю ожидаемый результат 200 от службы.
Однако, если я попытаюсь получить доступ к службе с помощью Edge, Chrome, Opera или Firefox, я получаю ERR_CONNECTION_RESET . Перед добавлением сертификата в хранилище сертификатов Firefox я получил PR_CONNECT_RESET_ERROR , но теперь это тоже выдает ERR_CONNECTION_RESET .
В моей системе нет активных прокси или VPN или чего-либо еще, что могло бы помешать работе сети Windows. Я в полной растерянности. Что здесь происходит и как мне это исправить?
Комментарии:
1. Сброс соединения выполняется сервером, в то время как проверка сертификата выполняется клиентом. Таким образом, ваша проблема не имеет ничего общего с тем, действителен сертификат или нет.
2. Я ценю усилия по оказанию помощи, но ERR_CONNECTION_RESET — это ошибка установления связи, которая не выдается сервером.
3. ОШИБКА_CONNECTION_RESET означает, что сервер отправил первый пакет TCP. Это не ошибка рукопожатия, но вызовет ошибку рукопожатия — если рукопожатие TLS уже было запущено. Но это не имеет никакого отношения к тому, что у клиента возникли проблемы с проверкой сертификата сервера.
4. Тогда почему он будет нормально работать в curl и IE, но не в других браузерах?
5. Я пытаюсь использовать совершенно другой самозаверяющий сертификат в IIS, и у меня такая же проблема. Работает в curl и IE и больше ни в чем.
Ответ №1:
У меня были точно такие же симптомы — IE и curl работают. Chrome, Edge и Firefox нет, все сообщают об ошибке ERR_CONNECTION_RESET.
В конечном итоге он был привязан к поврежденному HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCryptographyConfigurationLocalSSL0010002Functions ключу.
nmap сообщил об использовании одного шифра, когда он был взломан:
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519) - A
Перезагрузил ключ с правильным значением:
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp384r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp384r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519) - A
Вероятной причиной является отсутствие шифров GCM, поскольку Chromium сообщал о них как об устаревших пять лет назад.
Ответ №2:
У меня была аналогичная проблема в Chrome, где говорилось
NET::ERR_CERT_COMMON_NAME_INVALID
оказывается, ошибка была связана с самим сертификатом.
Попробуйте создать сертификат по ссылке ниже: SSL-сертификат