Срок сертификата не истёк, но браузер сообщает несовпадение имени. Проверка срока решает лишь одну часть TLS. Сопоставьте фактический хост адреса, SAN сертификата, конечное назначение и сертификат, выбранный сервером через SNI.
Срок действия и проверка имени — разные условия
Сертификат должен подтверждать имя того хоста, к которому подключается клиент. Рабочий сертификат для www не обязательно подходит адресу без www, а сертификат одного поддомена не покрывает другой автоматически.
TLS аутентификация связывает сертификат сервера с доменным именем, к которому подключается клиент. Официальная документация.
Сертификат может быть действительным по времени, выданным доверенным центром и всё же не подтверждать адрес, который открыл человек. Запишите фактический хост из URL до любых переходов. В сведениях сертификата найдите имена SAN, а не ограничивайтесь привычным названием владельца. Проверьте также цепочку доверия, но не смешивайте эти ошибки в один диагноз. Если браузер говорит о несовпадении имени, сначала сопоставьте нужный хост с фактически полученным сертификатом. Правильный срок не исправляет другое имя, а новый сертификат на соседнем сервере не меняет текущий ответ.
Матрица основного домена, www и CDN
Учебные сценарии в таблице задают ожидаемое поведение; фактические ответы своего сайта заносите отдельно.
| Сценарий | Отличие | Решение | Проверка |
|---|---|---|---|
| example.com | Основной хост | Проверить SAN | Имя покрыто |
| www.example.com | Другой хост | Проверить отдельно | Не только срок |
| cdn.example.com | Ресурсный поддомен | Свой сертификат | Нужное имя |
| Неправильный SNI | Чужой виртуальный хост | Указать servername | Правильный сертификат |
Проверьте example.com, www.example.com и используемый cdn.example.com отдельно. Если сайт принимает оба основных варианта по HTTPS, исходное соединение каждого должно пройти проверку до HTTP редиректа. Для поддоменов составьте точный список. Wildcard проверяйте по правилам покрытия конкретного имени; не считайте звёздочку разрешением любого уровня вложенности или корневого домена автоматически. В таблице сохраняйте полученный сертификат, имена, точку инфраструктуры и итоговую ошибку. Один успешный вариант www не является приёмкой non-www, даже если оба должны в итоге открывать одну страницу.
Проверьте SAN фактически полученного сертификата
Запишите фактический URL и ошибку клиента, откройте сведения сертификата и SAN. Проверьте оба варианта хоста и разные точки инфраструктуры в предусмотренном режиме. При SNI диагностике укажите имя сервера явно.
Получите сертификат средствами браузера и предусмотренной TLS диагностики. Сохраните публичные сведения об именах, сроке и выдавшем центре; закрытый ключ не нужен. Укажите хост соединения и SNI имя, поскольку общий IP может обслуживать много сайтов. Если DNS даёт несколько адресов, проверьте допустимые точки отдельно: на одном узле сертификат обновлён, на другом старый. Не используйте отключённую проверку как подтверждение исправности. Параметр, позволяющий игнорировать ошибку, помогает только отдельной диагностике и не показывает, что обычный посетитель сможет установить доверенное соединение.
Учебный HTTPS редирект с неправильным исходным именем
Учебный сервер имеет сертификат только для www.example.com. Прямой HTTPS вход на example.com ошибается до HTTP 301. Проверка обоих имён показывает, почему срок действия и редирект не заменяют покрытие нужного хоста.
Учебный сертификат покрывает www.example.com, а example.com должен делать 301 на www. Браузер при HTTPS входе сначала устанавливает TLS с example.com и проверяет его имя. Только потом может прочитать HTTP ответ с Location. Поэтому корректное правило 301 не спасает исходный хост от mismatch. Исправьте покрытие или предусмотренную архитектуру адресов и повторите прямой вход без исключения безопасности. Для HTTP входа последовательность иная, но это не повод оставлять HTTPS вариант сломленным. Пользователь может получить его из закладки, внешней ссылки или привычного автоматического выбора браузера.
SNI и виртуальный хост на сервере
Установите сертификат с нужными именами на соответствующий виртуальный хост или CDN. Исправьте маршрутизацию SNI, если выдаётся сертификат другого сайта. Затем проверьте цепочку доверия и оба публичных варианта адреса.
В openssl s_client можно явно задать -connect и -servername; для проверки имени предусмотрен -verify_hostname. Справка OpenSSL описывает эти параметры. Убедитесь, что проверяете нужную версию инструмента и согласованный хост. Если сервер выдаёт сертификат другого проекта, сравните привязку виртуального хоста, SNI и конфигурацию TLS терминации. Не переустанавливайте сертификаты всех сайтов на общем IP без локализации. В системе с CDN браузер видит сертификат края, а origin может иметь отдельное соединение; его проверяют по требованиям используемой инфраструктуры, не смешивая две роли.
Проверьте все точки выдачи и цепочку доверия
Редирект с HTTPS на HTTPS требует успешного TLS на исходном хосте до получения HTTP-ответа. Поэтому ошибочный сертификат нельзя считать исправленным лишь настройкой 301.
После установки проверьте каждый предусмотренный публичный хост из обычного клиента. Сравните несколько узлов или регионов только в доступном разрешённом режиме. При балансировке возможна неоднородность rollout, поэтому один успешный запрос не исключает старую конфигурацию другого сервера. Дополнительно проверьте цепочку доверия и работоспособность ресурса после TLS. Правильный сертификат не гарантирует успешный HTTP ответ, а HTTP 200 с отключённой валидацией не гарантирует TLS безопасность. Держите результаты раздельно и запишите дату, чтобы отличить текущую проверку от данных старого монитора.
Приёмка без отключения TLS валидации
Приёмка подтверждает нужные имена SAN, корректную цепочку и успешное соединение без override. Проверьте исходный HTTPS вход, конечный адрес после редиректа и используемые поддомены ресурсов. Если настройка HSTS предусмотрена, не пытайтесь обойти её ради сокрытия mismatch: исправьте исходную причину. Сохраните публичные сведения сертификата и перечень проверенных хостов. Следующее продление должно использовать тот же согласованный список имён, иначе ошибка может вернуться. Мониторинг срока полезен, но не заменяет проверку имени и фактически выдаваемого сертификата на каждой поддерживаемой точке.
Критерии завершения проверки
Каждый предусмотренный публичный хост проходит проверку имени и доверия без отключения валидации. Исходный HTTPS-вход способен выполнить нужный переход, инфраструктура выдаёт правильный сертификат.
- example.com: Имя покрыто. Зафиксируйте фактический результат и адрес проверенного сценария.
- www.example.com: Не только срок. Зафиксируйте фактический результат и адрес проверенного сценария.
- cdn.example.com: Нужное имя. Зафиксируйте фактический результат и адрес проверенного сценария.
- Неправильный SNI: Правильный сертификат. Зафиксируйте фактический результат и адрес проверенного сценария.
Для смежных вопросов: Ошибки SSL-сертификата: причины и способы исправления и SSL-сертификаты: полное руководство по HTTPS в 2026 году. Отдельные проверки сайта собраны на странице технического аудита reChecker.