Skip to content
EN

ERR_SSL_RENEGOTIATION_NOT_SUPPORTED

Коротко:

ERR_SSL_RENEGOTIATION_NOT_SUPPORTED — server запросил renegotiation (пересоздание keys), а client (или протокол) не поддерживает. TLS 1.3 полностью убрал renegotiation (security issue). Если сервер всё ещё инициирует — downgrade на TLS 1.2 или (лучше) убрать логику renegotiation вообще. Типично для mTLS/client-auth workflows.

Эта ошибка блокирует HTTPS-доступ. Ниже: причины, исправление, FAQ.

Проверить SSL своего сайта →

Причины ошибки

  • TLS 1.3 removed renegotiation — server всё ещё пытается
  • mTLS (client-auth): сервер требует client cert после handshake через re-neg
  • Legacy java applications с renegotiation-based key refresh
  • Apache + SSLVerifyClient require: внутри
  • Old JVM (

Пошаговое исправление

  1. TLS 1.3: переходите на post-handshake authentication (RFC 8446)
  2. TLS 1.2 + mTLS: clientauth запрашивайте на port/host level, не через re-neg
  3. nginx + mTLS: ssl_verify_client optional_no_ca; ssl_client_certificate
  4. Удалите renegotiation из client pool/library settings
  5. Обновите client Java/OpenSSL/curl до поддержки TLS 1.3

Проверить SSL-сертификат →

Смежные SSL-ошибки

Что такое ошибка ERR_SSL_RENEGOTIATION_NOT_SUPPORTED?

Ошибка ERR_SSL_RENEGOTIATION_NOT_SUPPORTED возникает, когда клиент (например, браузер) пытается выполнить повторную переговорку TLS (Transport Layer Security) с сервером, но сервер не поддерживает эту функцию. Это может привести к сбоям в установлении безопасного соединения, что особенно критично для сайтов, требующих защищенной передачи данных. Для решения проблемы необходимо настроить сервер так, чтобы он поддерживал повторную переговорку, либо отключить эту функцию на клиенте.

Настройка сервера для поддержки повторной переговорки TLS

Для того чтобы сервер поддерживал повторную переговорку TLS, необходимо внести изменения в его конфигурацию. Например, для веб-сервера Apache вы можете использовать следующие настройки:

SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite HIGH:!aNULL:!MD5
SSLHonorCipherOrder on
SSLSessionCache shmcb:/var/run/ssl_gcache_data(512000)
SSLSessionCacheTimeout 300

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

SSLInsecureRenegotiation on

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

sudo systemctl restart apache2

Для Nginx конфигурация будет выглядеть следующим образом:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'HIGH:!aNULL:!MD5';
ssl_prefer_server_ciphers on;

Для включения повторной переговорки в Nginx также потребуется добавить:

ssl_renegotiation off;

После изменения конфигурации перезапустите Nginx:

sudo systemctl restart nginx

Причины возникновения и методы устранения ошибки ERR_SSL_RENEGOTIATION_NOT_SUPPORTED

Ошибка ERR_SSL_RENEGOTIATION_NOT_SUPPORTED может возникать по нескольким причинам. Во-первых, это может быть связано с настройками безопасности на сервере, которые ограничивают возможность повторной переговорки. Во-вторых, некоторые браузеры могут блокировать повторные переговорки, если они определяют, что это потенциально небезопасно.

Для устранения проблемы, прежде всего, проверьте настройки вашего веб-сервера на наличие параметров, связанных с повторной переговоркой. Убедитесь, что сервер правильно настроен для поддержки необходимых версий TLS и шифров. Также проверьте, не используете ли вы устаревшие версии TLS, такие как 1.0 и 1.1, которые могут вызвать проблемы совместимости.

Если вы используете OpenSSL, вы можете проверить поддерживаемые версии TLS с помощью команды:

openssl s_client -connect example.com:443 -tls1_2

Замените example.com на ваш домен. Если соединение установлено, значит, сервер поддерживает TLS 1.2. Если нет, вам нужно будет обновить настройки сервера.

Также стоит обратить внимание на клиентские настройки. Например, в Chrome можно отключить поддержку повторной переговорки через флаги:

  1. Введите chrome://flags в адресной строке.
  2. Найдите параметр Allow insecure renegotiation.
  3. Установите значение Enabled и перезапустите браузер.

Однако отключение этой функции не рекомендуется, так как это может снизить уровень безопасности соединения. Лучше всего исправить настройки на стороне сервера.

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

СертификатСрок, издатель, домены (SAN)
ЦепочкаПроверка промежуточных и корневых CA
TLS-протоколВерсия TLS и набор шифров
УязвимостиHeartbleed, POODLE, слабые шифры

Почему нам доверяют

TLS 1.3
поддержка
Полная
цепочка CA
<2с
результат
30/14/7
дней до истечения

Как это работает

1

Введите домен

2

Проверка цепочки TLS

3

Дата истечения и уязвимости

Что проверяет SSL-тест?

SSL/TLS — протокол шифрования, который защищает данные между браузером и сервером. Наш инструмент анализирует сертификат, цепочку доверия, версию TLS и известныеуязвимости.

Детали сертификата

Издатель, срок действия, алгоритм подписи, покрываемые домены (SAN) и тип валидации (DV/OV/EV).

Цепочка доверия

Проверка полной цепочки: от конечного сертификата через промежуточные до корневого CA.

Анализ TLS

Версия протокола (TLS 1.2/1.3), набор шифров, поддержка Perfect Forward Secrecy (PFS).

Оповещения об истечении

Создайте монитор — получайте уведомления в Telegram и email за 30/14/7 дней до истечения.

DV vs OV vs EV сертификаты

DV (Domain Validation)
  • Подтверждение только владения доменом
  • Выдаётся за минуты автоматически
  • Бесплатно через Let's Encrypt
  • Подходит для большинства сайтов
  • Самый распространённый тип
OV / EV
  • Проверка организации (OV) или расширенная проверка (EV)
  • Выдаётся за 1-5 рабочих дней
  • Стоимость от $50 до $500/год
  • Для финансов, e-commerce, госсайтов
  • Повышает доверие пользователей

Кому это нужно

DevOps

мониторинг SSL-сертификатов

Безопасность

аудит TLS-конфигурации

SEO

HTTPS как фактор ранжирования

E-commerce

доверие покупателей

Частые ошибки

Истёкший сертификатБраузеры блокируют сайт с истёкшим SSL. Настройте автопродление или мониторинг.
Неполная цепочка сертификатовБез промежуточного CA некоторые браузеры и боты не смогут верифицировать сертификат.
Mixed content на HTTPS-сайтеHTTP-ресурсы на HTTPS-странице — замок в браузере пропадает, снижается доверие.
Использование TLS 1.0/1.1Устаревшие версии TLS содержат известные уязвимости. Используйте TLS 1.2+ или 1.3.
Несовпадение домена в сертификатеСертификат должен покрывать все домены сайта, включая www и поддомены.

Лучшие практики

Настройте автопродлениеLet's Encrypt + certbot с cron — сертификат обновляется автоматически каждые 60-90 дней.
Включите HSTSЗаголовок Strict-Transport-Security заставляет браузер всегда использовать HTTPS.
Используйте TLS 1.3TLS 1.3 быстрее (1-RTT handshake) и безопаснее — убраны устаревшие шифры.
Мониторьте срок действияСоздайте монитор на Enterno.io — получайте уведомления задолго до истечения.
Проверяйте цепочку после обновленияПосле обновления сертификата убедитесь, что промежуточные сертификаты установлены.

Получите больше с бесплатным аккаунтом

Мониторинг SSL-сертификатов, история проверок и уведомления за 30 дней до истечения.

Зарегистрироваться (FREE)

Больше по теме

Источники

Часто задаваемые вопросы

Что такое TLS renegotiation?

Процесс во время активной TLS-сессии, когда стороны пересогласовывают keys/cipher/auth без разрыва connection. TLS 1.3 заменил на post-handshake auth.

Почему renegotiation удалили?

Vulnerable к atak (CVE-2009-3555 renegotiation MITM). TLS 1.3 использует KeyUpdate и post-handshake auth — безопасная замена.

Как настроить mTLS в 2026?

Для TLS 1.3: server отправляет CertificateRequest при handshake, client отвечает. Без renegotiation. Nginx поддерживает.

Legacy Java client — что делать?

Обновите до Java 17+ (TLS 1.3 support). Или оставьте TLS 1.2 для этого endpoint + правильно настройте mTLS.

Запустить инструмент, который описан в этой статье

Бесплатный тариф — 10 мониторов, проверки каждые 5 мин, без карты. Платные тарифы — интервал от 1 минуты и проверки из нескольких регионов.