Сертификат обновился, а сайт отдаёт старый: как проверить TLS

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

Что именно считается старым

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

В документации OpenSSL x509 описаны просмотр сроков, серийного номера и отпечатка сертификата. Для сравнения фиксируйте одинаковый вид данных и алгоритм отпечатка. Совпадение названия издателя у старого и нового выпуска не означает, что это один сертификат.

Нарисуйте путь до TLS, а не до приложения

Составьте схему: браузер → внешняя точка входа → внутренний сервер → приложение. Уберите звенья, которых в вашей конфигурации нет, и подпишите, где завершается защищённое соединение. Не подставляйте CDN в схему только потому, что домен когда-то подключали к похожему сервису.

Например, Cloudflare описывает edge-сертификаты как сертификаты, предъявляемые посетителям на соединении с Cloudflare. Поэтому файл на исходном сервере и сертификат внешней точки могут быть разными объектами. Это пример конкретной архитектуры, а не утверждение, что всякий CDN или прокси работает одинаково.

Учебная ведомость точек проверки

Наблюдения в таблице придуманы для объяснения, а не получены с реального сайта. В рабочей ведомости укажите конкретные адреса, время и идентификаторы сертификатов. Пустая клетка означает отсутствие проверки; заполнять её результатом соседнего узла нельзя.

Проверяйте соединение с нужным именем

Nginx в описании HTTPS объясняет роль SNI при выборе сертификата для имени. Подключение только к IP может не воспроизводить обращение браузера по домену. Поэтому при проверке отдельного узла нужно сохранять имя, для которого вы исследуете TLS.

В руководстве OpenSSL s_client параметр servername задаёт SNI отдельно от адреса соединения. Но получение списка через showcerts не является проверенной цепочкой доверия. В отчёте различайте «сертификат предъявлен», «это ожидаемый сертификат» и «проверки доверия и имени пройдены».

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

Путь в конфигурации и применённое состояние

Если публичный TLS действительно заканчивается на нужном Nginx, проверьте, какой файл указан в действующей конфигурации этого экземпляра. Возможны несколько каталогов, копий настройки и узлов. Замена файла в похожем пути не подтверждает замену того объекта, который читает обслуживающий процесс.

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

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

Пять шагов до подтверждённого исправления

1. Запишите публичное имя, время и сведения о полученном сертификате.
2. Установите фактическую внешнюю точку TLS и ожидаемый сертификат именно для неё.
3. При нескольких узлах сравните каждый разрешённый маршрут с сохранением нужного имени.
4. Исправьте найденное расхождение в соответствующей системе и подтвердите успешное применение.
5. Проверьте новые соединения по тем же маршрутам, затем отдельно имя, срок и доверие.

Проверка одного удачного соединения закрывает только это наблюдение. Если есть несколько адресов или точек обслуживания, запишите, какие проверены, а какие остаются неизвестными. Не обещайте полное покрытие инфраструктуры на основании одного скриншота браузера.

Что включить в дальнейшее сопровождение

Продление и фактическая выдача — разные этапы контроля. Сохраните, где выпускается сертификат, куда он доставляется, кто применяет его и что получает клиент. Для поддержки сайта эта схема удобнее разрозненных напоминаний о сроке файла.

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