ERR_SSL_VERSION_OR_CIPHER_MISMATCH: причины и как исправить

ERR_SSL_VERSION_OR_CIPHER_MISMATCH — ошибка браузера, которая возникает, когда клиент и сервер не могут договориться об общей версии протокола TLS или наборе шифров (cipher suite) во время TLS-рукопожатия. Чаще всего причина серверная: включён устаревший TLS 1.0/1.1, отсутствуют современные шифры или неверно установлен сертификат.

В этом руководстве разберём, что означает ошибка, все её причины со стороны сервера и клиента, как отличить одно от другого, и дадим конкретные команды для диагностики и исправления на nginx и Apache, а также способы обхода на стороне браузера. Материал рассчитан на владельцев сайтов и системных администраторов.

Что означает ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Когда браузер открывает SSL/TLS проверку-соединение, он отправляет серверу список поддерживаемых версий TLS и шифров в сообщении ClientHello. Сервер выбирает из этого списка общий вариант и отвечает ServerHello. Если пересечения нет — ни одной общей версии протокола или ни одного общего cipher suite — рукопожатие прерывается, и Chrome показывает ERR_SSL_VERSION_OR_CIPHER_MISMATCH. В Firefox аналог — SSL_ERROR_NO_CIPHER_OVERLAP, в Safari — «Safari не может установить защищённое соединение».

Ключевое слово здесь — mismatch (несовпадение). Ошибка не про истёкший сертификат сертификат сам по себе и не про неверный домен — это отказ на самом раннем этапе, до проверки сертификата. Стороны буквально не нашли общего языка для шифрования.

Причины ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Причины делятся на две большие группы: серверные (их подавляющее большинство) и клиентские. Разберём обе.

Устаревшие версии TLS (1.0 и 1.1)

Самая частая причина после 2020 года. Chrome, Firefox, Safari и Edge отключили поддержку TLS 1.0 и TLS 1.1 как небезопасных. Если сервер настроен работать только по этим протоколам, современный браузер не найдёт общей версии и выдаст ошибку. Решение — включить на сервере TLS 1.2 и TLS 1.3.

Несовместимые cipher suites

Даже при совпадении версии TLS стороны должны согласовать конкретный набор шифров. Если сервер предлагает только устаревшие шифры (RC4, 3DES, DES, export-grade, шифры без forward secrecy), а браузер их давно не поддерживает, пересечения не будет. Нужно настроить современный список: ECDHE с AES-GCM и ChaCha20-Poly1305.

Устаревшие и слабые шифры: RC4, 3DES, DES

Шифр RC4 признан небезопасным (RFC 7465 прямо запрещает его в TLS), 3DES уязвим к атаке Sweet32, а export-grade шифры — наследие 90-х. Браузеры удалили их из своих списков. Сервер, полагающийся на такие шифры, обречён на mismatch с новыми клиентами.

Проблемы с сертификатом

Хотя ошибка в первую очередь про протокол и шифры, к ней может привести и неправильно установленный сертификат: неверный формат ключа, несоответствие типа сертификата (например, ECDSA-ключ при RSA-шифрах в конфиге), самоподписанный сертификат или повреждённый сертификат, из-за которого сервер не может корректно завершить согласование. Просроченный сертификат чаще даёт другую ошибку (NET::ERR_CERT_DATE_INVALID), но в связке с ограниченным конфигом может проявиться и как cipher mismatch.

Ошибки после включения HTTP/2 или HSTS

Протокол HTTP/2 требует так называемого ALPN и запрещает целый список слабых шифров из своего чёрного списка (RFC 7540). Если вы включили http2 в директиве listen, но оставили в ssl_ciphers только устаревшие наборы, браузер откажется завершать рукопожатие именно с этой ошибкой. Аналогично, после включения строгого HSTS с preload браузер запрещает любые понижения защиты — и малейшая несовместимость шифров превращается в жёсткий отказ без возможности продолжить по HTTP. Поэтому включайте HTTP/2 и HSTS только вместе с современным списком шифров ECDHE и AES-GCM.

Серверная или клиентская ошибка

Первый практический шаг — определить, где проблема. Если ошибку видят все пользователи на всех устройствах — почти наверняка сервер. Если только вы на одном устройстве, а с телефона по мобильному интернету сайт открывается — причина локальная (устаревший браузер, антивирус, системное время, корпоративный прокси). Таблица ниже поможет диагностировать.

Как исправить на сервере

Если диагностика указала на сервер, отредактируйте конфигурацию веб-сервера, чтобы включить актуальные протоколы и шифры. Ниже — проверенные настройки для nginx и Apache, соответствующие рекомендациям Mozilla (профиль Intermediate).

Настройка nginx

В блоке server вашего сайта задайте версии протокола и список шифров. Для TLS 1.3 набор шифров фиксирован стандартом, для TLS 1.2 указываем ECDHE-приоритет:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;

    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
}

После правки проверьте синтаксис и перезагрузите nginx:

sudo nginx -t
sudo systemctl reload nginx

Настройка Apache

В файле виртуального хоста (например, /etc/apache2/sites-enabled/example.com.conf) или в конфигурации SSL задайте:

<VirtualHost *:443>
    ServerName example.com

    SSLEngine on
    SSLCertificateFile      /etc/ssl/example.com/fullchain.pem
    SSLCertificateKeyFile   /etc/ssl/example.com/privkey.pem

    SSLProtocol             -all +TLSv1.2 +TLSv1.3
    SSLHonorCipherOrder     off
    SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
</VirtualHost>

Проверьте конфигурацию и перезапустите Apache:

sudo apachectl configtest
sudo systemctl reload apache2

Проверка результата через openssl и curl

Убедитесь, что сервер теперь принимает TLS 1.2 и отдаёт корректный шифр. Команда openssl s_client покажет согласованную версию протокола и cipher suite:

openssl s_client -connect example.com:443 -tls1_2
# В выводе ищите строки: Protocol : TLSv1.2 и Cipher : ECDHE-RSA-AES128-GCM-SHA256

Для быстрой проверки через curl с подробным логом рукопожатия:

curl -v --tlsv1.2 https://example.com/
# Строка '* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256' подтверждает успех

Как исправить в браузере

Если ошибка возникает только у вас, а сайт открывается на других устройствах, проблема на стороне клиента. Действуйте по порядку:

1. Обновите браузер и ОС. Старые версии Chrome, Firefox или устаревшая Windows/Android могут не поддерживать современные шифры.
2. Очистите SSL-состояние и кэш. В Windows: «Свойства браузера» → «Содержание» → «Очистить SSL». Перезапустите браузер.
3. Проверьте дату и время. Неверное системное время ломает TLS на многих сайтах — синхронизируйте по NTP.
4. Отключите HTTPS-сканирование антивируса. Kaspersky, ESET, Avast и другие вклиниваются в TLS и могут навязывать несовместимые шифры.
5. Проверьте прокси и VPN. Корпоративные прокси с SSL-инспекцией — частая причина. Временно отключите их для теста.
6. Попробуйте режим инкогнито. Это исключит влияние расширений браузера.

Важно: не пытайтесь «включить старый TLS 1.0/1.1» в браузере ради обхода — это снижает вашу безопасность. Правильное решение — исправить сервер.

Как проверить SSL вашего сайта

Прежде чем менять конфигурацию, полезно увидеть полную картину: какие версии TLS и шифры реально предлагает сервер, корректна ли цепочка сертификата и когда он истекает. Наша бесплатная проверка SSL-сертификата покажет согласованный протокол, набор шифров, срок действия и цепочку доверия за пару секунд — без установки утилит. Это быстрый способ подтвердить, что после правок ошибка ERR_SSL_VERSION_OR_CIPHER_MISMATCH устранена.

Полезные смежные материалы: исправление ERR_SSL_PROTOCOL_ERROR, почему падает SSL-рукопожатие и сравнение TLS 1.3 и TLS 1.2.

Частые вопросы

Почему ошибка появилась внезапно на работавшем сайте?

Скорее всего, обновился браузер и отключил устаревший протокол или шифр, на котором держался ваш сервер. Chrome и Firefox постепенно убирают TLS 1.0/1.1 и слабые шифры. Сервер, который вчера работал, сегодня оказался несовместим. Обновите конфигурацию до TLS 1.2/1.3 с современными TLS cipher suites 2026 — и доступ восстановится.

Это проблема сервера или моего компьютера?

Проверьте сайт с другого устройства и через мобильный интернет. Если ошибка у всех — виноват сервер: старый TLS или слабые шифры. Если только у вас — причина локальная: устаревший браузер, антивирус с HTTPS-сканированием, неверное системное время или корпоративный прокси. Таблица в статье поможет точно локализовать источник.

Нужно ли оставлять поддержку TLS 1.0 и 1.1 для старых клиентов?

Нет. TLS 1.0 и 1.1 официально устарели (RFC 8996) и небезопасны. Оставлять их — значит держать открытой уязвимость ради ничтожной доли устройств. Современные ОС и браузеры давно поддерживают TLS 1.2. Настройте TLS 1.2 и 1.3 — этого достаточно для всех актуальных клиентов без ущерба безопасности.

Как понять, какие шифры предлагает мой сервер?

Используйте команду openssl s_client -connect host:443 -tls1_2 и смотрите строку Cipher в выводе, либо запустите онлайн-проверку на странице /ssl. Она покажет полный список согласуемых наборов шифров, версию протокола и оценку безопасности конфигурации — без установки инструментов на компьютер.

Помогает ли перевыпуск сертификата?

Только если исходная проблема была в самом сертификате — повреждён, неверный формат ключа или несоответствие типа (ECDSA против RSA). В большинстве случаев ERR_SSL_VERSION_OR_CIPHER_MISMATCH вызвана настройками протокола и шифров, а не сертификатом, поэтому сначала исправьте ssl_protocols и ssl_ciphers, а перевыпуск оставьте на крайний случай.

Источники

• MDN Web Docs — Transport Layer Security
• RFC 8446 — The TLS Protocol Version 1.3
• Mozilla SSL Configuration Generator