В этом материале
Неверный сертификат может означать выбор другого virtual host по SNI или несовпадение проверяемого имени с SAN. Это разные стадии TLS. Сначала установите, какое имя отправляет клиент и какой сертификат реально возвращает сервер, сохраняя проверку доверия включённой.
Неверный сертификат может означать выбор другого virtual host по SNI или несовпадение проверяемого имени с SAN. Это разные стадии TLS. Сначала установите, какое имя отправляет клиент и какой сертификат реально возвращает сервер, сохраняя проверку доверия включённой.
Разделите адрес и identity
DNS-имя, IP назначения, HTTP Host и TLS server name выполняют разные функции. При обращении по IP клиент может не передать ожидаемое SNI, и сервер выберет default HTTPS configuration. Добавление HTTP Host после установления TLS не исправляет уже выбранный сертификат. Сохраните точный URL и способ разрешения имени. Если используется балансировщик или proxy, определите, где завершается TLS и кто отвечает за предъявляемую цепочку.
Проверьте выбор virtual host
В NGINX сравните listen, default_server, server_name и ssl_certificate для нужного адреса. SNI позволяет выбрать конфигурацию до HTTP-запроса. Один IP может обслуживать несколько имён с разными сертификатами. Не редактируйте первый попавшийся server block: фактическая конфигурация включает include files и несколько listen sockets. Сначала восстановите полный набор применяемых правил и сохраните, какая конфигурация должна отвечать на имя тестового клиента.
Разберите 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; hardware security.