ERR_SSL_UNRECOGNIZED_NAME_ALERT: сервер не узнал имя сайта

ERR_SSL_UNRECOGNIZED_NAME_ALERT — ошибка Chrome, Яндекс Браузера и Edge: «Не удается получить доступ к сайту. Веб-страница по адресу …, возможно, временно недоступна или постоянно перемещена по новому адресу». Она значит, что сервер получил имя сайта в начале защищённого соединения, не нашёл у себя такого сайта и прервал соединение.

Мы проверили на стенде Chromium 149 со своими серверами и nginx, какие настройки дают эту ошибку, а какие — другие, и разобрали, что с ней делать посетителю и владельцу сайта.

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

Когда браузер открывает https-сайт, он в первом же сообщении сообщает серверу, к какому сайту идёт. Это расширение SNI (Server Name Indication): на одном IP-адресе живут сотни сайтов, и по имени сервер выбирает нужный сертификат.

Если сайта с таким именем на сервере нет, у него есть варианты: отдать сертификат по умолчанию, предупредить и продолжить или прервать соединение. В последнем случае он отправляет сигнал (alert) unrecognized_name, номер 112 по стандарту TLS. Браузер получает его и показывает ошибку.

В коде Chromium:

// The SSL server sent us a fatal unrecognized_name alert. NET_ERROR(SSL_UNRECOGNIZED_NAME_ALERT, -159)

Перевод — «SSL-сервер прислал нам фатальный сигнал unrecognized_name». Ключевое слово — «фатальный». В файле openssl_ssl_util.cc ошибка BoringSSL SSL_R_TLSV1_UNRECOGNIZED_NAME превращается в этот код.

Стенд: какие ответы сервера дают эту ошибку

Стенд — Chromium 149 под Linux, свои TLS-серверы на Python и OpenSSL 3.0 и nginx 1.22. Сайт настроен на имя site.test, а открываем его по другим адресам.

Что из этого следует:

• Ошибку даёт только фатальный сигнал. OpenSSL-сервер с ключом -servername по умолчанию шлёт предупреждение (warning), и браузер продолжает соединение. В BoringSSL, на котором собран Chrome, предупреждающие сигналы пропускаются — до четырёх подряд (kMaxWarningAlerts = 4 в tls_record.cc).
• Адрес по IP имени не передаёт. Стандарт SNI (RFC 6066) запрещает передавать IP-адрес как имя. На стенде сервер получил пустое имя и, если его настроили требовать имя, отказал.
• nginx с ssl_reject_handshake отвечает именно так. Эта настройка нужна, чтобы сервер не раскрывал свой сертификат по умолчанию случайным посетителям и сканерам. Обратная сторона — каждое имя, которое не описано в server_name, получает ERR_SSL_UNRECOGNIZED_NAME_ALERT.
• Отключение проверки сертификатов не помогает. Мы повторили всё с флагом игнорирования ошибок сертификатов: сайты с сертификатом по умолчанию открылись, а с фатальным сигналом — нет. Отказ происходит до того, как сервер покажет сертификат.

Шаги рукопожатия: где возникает ошибка

Чтобы понять момент возникновения ошибки, посмотрите на шаги защищённого соединения:

1. Клиент — браузер — отправляет серверу приветствие ClientHello. В нём версии протокола, которые он поддерживает, список шифров и имя сайта в расширении SNI.
2. Сервер по имени выбирает сайт и его сертификат.
3. Сервер отвечает приветствием и присылает сертификат, который подтверждает, что это действительно нужный сайт.
4. Браузер проверяет сертификат: срок истечения, цепочку доверия, имя.
5. Стороны договариваются о ключах, и начинается безопасное шифрованное соединение.

ERR_SSL_UNRECOGNIZED_NAME_ALERT возникает на втором шаге: сервер не нашёл сайт и отправил сигнал вместо приветствия. До проверки сертификата дело не доходит. В этом главное отличие от ошибок сертификата: там сертификат есть, но с ним что-то не так, а здесь сервер вообще отказался продолжать. Отказ мгновенный — на стенде браузер получал его за сотые доли секунды.

Как выглядит ошибка

На стенде экран был таким:

Не удается получить доступ к сайту Веб-страница по адресу https://www.site.test:9001/, возможно, временно недоступна или постоянно перемещена по новому адресу. ERR_SSL_UNRECOGNIZED_NAME_ALERT

Кнопок «Дополнительно» и «Перейти на сайт» здесь нет — в отличие от экрана «Подключение не защищено» при проблемах с сертификатом.

Как часто встречается

25 сентября 2026 года в нашем обходе сайтов организаций Екатеринбурга из 22 адресов, где https обрывался на рукопожатии, эту ошибку Chrome показал у четырёх. Причина везде была одна: на сервере нет сертификата для этого имени. При этом по http часть таких сайтов работала — сломан был только https.

Частые причины ошибки

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

• Имя сайта не настроено на сервере. Сайт добавлен как site.ru, а посетитель пришёл на www.site.ru, или наоборот. То же с поддоменами: shop.site.ru, m.site.ru.
• Сайт перенесли, а DNS указывает на старый сервер. Старый сервер сайта уже не знает и отказывает.
• Сайт удалён с хостинга или домен не продлён, а запись DNS осталась.
• Открывают по IP-адресу вместо имени.
• Ошибка в настройке балансировщика или CDN: домен не добавлен в список имён сертификата или слушателя (listener).
• Посредник на стороне посетителя — прокси, VPN или антивирус с проверкой HTTPS — подменяет или теряет имя сайта.

Как исправить ошибку посетителю

Посетитель не может исправить настройку сервера, но несколько шагов помогут понять, на чьей стороне проблема, и иногда — открыть сайт.

1. Проверьте адрес

Попробуйте адрес с www и без него: https://site.ru/ и https://www.site.ru/. Если вы открываете сайт по IP-адресу, введите вместо него имя. Это самый частый способ обойти ошибку — сервер настроен на одно из имён.

2. Откройте сайт с другого устройства или сети

С мобильного интернета, на другом компьютере. Если ошибка везде — дело в сервере, и исправить её может только владелец. Если только у вас — проверьте посредников.

3. Отключите VPN и прокси

VPN и прокси устанавливают соединение от своего имени. Отключите их на время проверки. Прокси в Windows: «Параметры» → «Сеть и Интернет» → «Прокси-сервер».

4. Отключите проверку HTTPS в антивирусе

Антивирусы с проверкой защищённых соединений встают посередине между браузером и сайтом. Отключите эту функцию на время проверки и повторите попытку.

5. Очистите кэш DNS

Если сайт недавно переехал, компьютер может помнить старый адрес. В командной строке выполните ipconfig /flushdns, в Chrome на странице chrome://net-internals/#dns нажмите «Clear host cache».

6. Напишите владельцу сайта

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

Как исправить ошибку владельцу сайта

1. Проверьте ответ сервера

openssl s_client -connect site.ru:443 -servername www.site.ru

На стенде ответ на неизвестное имя выглядел так:

error:0A000458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name:
../ssl/record/rec_layer_s3.c:1602:SSL alert number 112

curl пишет: curl: (35) OpenSSL/3.0.22: error:0A000458:SSL routines::tlsv1 unrecognized name. Проверьте все имена сайта: с www, без www, поддомены.

2. Добавьте имя в настройки сервера

Чтобы устранить ошибку, необходимо сделать так, чтобы сервер знал каждое имя вашего сайта. Решения для разных серверов следующие.

nginx: перечислите все имена в server_name того блока, который обслуживает сайт:

server {
    listen 443 ssl;
    server_name site.ru www.site.ru;
    ...
}

Если в блоке по умолчанию стоит ssl_reject_handshake on, это нормально — но тогда каждое рабочее имя должно быть описано явно.

Apache: добавьте ServerAlias www.site.ru в <VirtualHost *:443> сайта.

Хостинг-панель: добавьте псевдоним (алиас) www или поддомен к сайту и перевыпустите сертификат.

3. Выпустите сертификат на все имена

Добавить имя в настройки мало: когда сервер начнёт принимать новое имя, он покажет сертификат, и если имени в нём нет, ошибка сменится на «Подключение не защищено». Обновление сертификата обязательно вместе с правкой настроек — иначе проблема не будет решена.

Сертификат должен покрывать все имена, по которым приходят посетители. Let's Encrypt: certbot --nginx -d site.ru -d www.site.ru. Проверить список имён в сертификате можно командой:

openssl s_client -connect site.ru:443 -servername site.ru </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName

4. Проверьте DNS

Убедитесь, что все имена сайта указывают на тот сервер, где он настроен: nslookup www.site.ru. Старая запись A на прежний хостинг — частая причина после переезда.

5. Проверьте CDN и балансировщик

Если перед сайтом стоит CDN или балансировщик, домен должен быть добавлен и туда, вместе с сертификатом.

6. Настройте переадресацию на основное имя

Когда сервер принимает оба имени, переведите посетителей на одно основное 301-й переадресацией. Это нужно и для поисковиков: сайт не должен быть доступен по двум адресам с одинаковым содержимым.

7. Протестируйте сайт онлайн-инструментом

Кроме openssl, проверить настройку помогут онлайн-инструменты тестирования SSL, например SSL Labs Server Test от Qualys. Введите доменное имя — инструмент исследует сервер и покажет, совпадает ли имя в запросе с именами в сертификате, полна ли цепочка промежуточных сертификатов, каков срок действия и до какой даты сертификат действителен. Проверяйте каждое имя отдельно: результат для site.ru ничего не говорит о www.site.ru.

8. Если сайт на хостинге — объясните проблему поддержке

Если доступа к настройкам сервера нет, напишите в поддержку хостинга. Объясните коротко: «Сайт открывается по адресу site.ru, а по адресу www.site.ru браузер показывает ERR_SSL_UNRECOGNIZED_NAME_ALERT. openssl s_client с -servername www.site.ru получает alert number 112. Прошу добавить www.site.ru к сайту и в сертификат». Такой запрос сразу указывает на причину, и поддержке не нужно её определять заново.

Почему это важно для сайта

Ошибка может повлиять на всех посетителей, которые пришли по ненастроенному имени, — а это часто ссылки из старых рекламных материалов, визиток и записей в справочниках с www. Пользователям такой сайт кажется неработающим, и они уходят к конкурентам. Кнопки «Перейти на сайт» нет, поэтому даже тот, кто доверяет сайту, зайти не сможет.

Для поисковиков https тоже имеет значение: Google в 2014 году объявил, что использует HTTPS как сигнал ранжирования. Если робот приходит на адрес с www и получает отказ в рукопожатии, страница по этому адресу в поиск не попадёт.

Шифрование защищает данные посетителей: пароли, данные для входа, сведения о картах и другую финансовую информацию. Отказ сервера по неизвестному имени сам по себе не делает сайт уязвимым — наоборот, это защитная настройка. Проблема только в том, что под неё попали рабочие имена.

Как предотвратить ошибку

Несколько простых практик позволят избежать ошибки:

• Составьте список всех имён сайта — с www и без, поддомены — и держите его в одном файле рядом с настройками сервера.
• Проверяйте все имена после каждого изменения. При внесении изменений в конфигурацию виртуального хоста, переезде или смене CDN запускайте openssl s_client -servername для каждого имени.
• Настройте автоматическое продление сертификата. certbot умеет продлевать сертификаты Let's Encrypt автоматически; убедитесь, что при продлении в сертификат попадают все имена.
• Следите за DNS-записями. После переезда удалите записи, которые указывают на старый сервер.
• Используйте мониторинг. Сервисы проверки доступности умеют следить за https-адресом и сообщать о сбое — подключите в них каждое имя.

Источники

• Chromium, net/base/net_error_list.h — SSL_UNRECOGNIZED_NAME_ALERT, −159
• Chromium, net/ssl/openssl_ssl_util.cc — какой ответ BoringSSL даёт этот код
• BoringSSL, ssl/tls_record.cc — предупреждающие сигналы пропускаются, не больше четырёх
• RFC 6066, раздел 3 — расширение SNI; IP-адрес именем не передаётся
• nginx, документация ngx_http_ssl_module — ssl_reject_handshake

Похожие ошибки

Про сертификаты и их установку — в статье «SSL-сертификат для сайта».

Границы замера

Стенд — Chromium 149 под Linux, 18.10.2026, серверы на Python 3 и OpenSSL 3.0.22, nginx 1.22.1. Сертификаты подписывал наш учебный центр сертификации, которому браузер не доверял. Поэтому вместо ошибки «чужое имя в сертификате» браузер показывал «центр сертификации не признан» — обе относятся к экрану «Подключение не защищено». CDN и облачные балансировщики мы не проверяли.

Коротко

ERR_SSL_UNRECOGNIZED_NAME_ALERT — сервер не знает сайт с таким именем и прервал защищённое соединение. Обойти её кнопкой «Дополнительно» нельзя. Посетителю — попробовать адрес с www и без, отключить VPN, прокси и проверку HTTPS в антивирусе. Владельцу — добавить имя в настройки сервера, выпустить сертификат на все имена сайта и проверить ответ командой openssl s_client -servername.