# Сервер отдаёт чужой сертификат: SNI, SAN и default virtual host

Диагностика: Сервер отдаёт чужой сертификат: SNI, SAN и default virtual host. Признаки, последовательность проверки, рабочий пример и критерии восстановления.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/tls-sni-san-wrong-certificate/
Language: ru

Неверный сертификат может означать выбор другого virtual host по SNI или несовпадение проверяемого имени с SAN. Это разные стадии TLS. Сначала установите, какое имя отправляет клиент и какой сертификат реально возвращает сервер, сохраняя проверку доверия включённой.

## Разделите адрес и identity

DNS-имя, IP назначения, HTTP Host и TLS server name выполняют разные функции. При обращении по IP клиент может не передать ожидаемое SNI, и сервер выберет default HTTPS configuration. Добавление HTTP Host после установления TLS не исправляет уже выбранный сертификат. Сохраните точный URL и способ разрешения имени. Если используется балансировщик или proxy, определите, где завершается TLS и кто отвечает за предъявляемую цепочку.


[Официальный источник 1](https://nginx.org/en/docs/http/configuring_https_servers.html).

## Проверьте выбор virtual host

В NGINX сравните listen, default_server, server_name и ssl_certificate для нужного адреса. SNI позволяет выбрать конфигурацию до HTTP-запроса. Один IP может обслуживать несколько имён с разными сертификатами. Не редактируйте первый попавшийся server block: фактическая конфигурация включает include files и несколько listen sockets. Сначала восстановите полный набор применяемых правил и сохраните, какая конфигурация должна отвечать на имя тестового клиента.


[Официальный источник 2](https://www.rfc-editor.org/rfc/rfc9525.html).

## Разберите SAN mismatch

RFC 9525 описывает сопоставление service identity: DNS-ID и IP-ID проверяются по своим правилам. Сертификат для api.example.org не становится подходящим для произвольного IP только потому, что DNS указывает туда. В учебном тесте подключение к имени получает правильный SAN, а подключение по literal IP — ошибку identity. Это ожидаемое различие, если сертификат не содержит подходящего IP-ID. Оно не доказывает истечение срока или отсутствие доверенного CA.

| Наблюдение | Проверяемая стадия |
| --- | --- |
| Возвращён чужой leaf | SNI и выбор virtual host |
| Leaf правильный, имя отвергнуто | SAN и reference identity |
| Цепочка не доверена | CA store и intermediates |
| Сертификат вне срока | Время и validity interval |

## Исправьте назначение имени

Используйте предусмотренное DNS-имя, исправьте TLS server-name настройку клиента либо корректно настройте сертификат и virtual host. Не заменяйте identity verification отключением проверки: тогда исчезает сам критерий, который защищает связь с нужным сервисом. Для проверки нового сертификата сравните fingerprint и SAN, затем проверьте опубликованную цепочку. Перезагрузка NGINX должна проходить после проверки конфигурации и в предусмотренном порядке, учитывающем реальные полномочия оператора.

## Сохраните безопасный протокол

В артефакт включите URL без секретных query parameters, IP, отправленное имя, SAN и fingerprint. Private key не нужен для диагностики ответа сервера и не должен попадать в отчёт. Повторите запрос после изменения тем же клиентом и отдельно проверенным инструментом. Если одно работает, а другое нет, сравните client configuration. Такой протокол отличает SNI routing от доверия и времени, не объявляя любой certificate error одной и той же проблемой.

Связанные разборы: [network and uptime](/ru/journal/network-and-uptime/); [hardware security](/ru/journal/hardware-security/).