Проверить имя
Сертификат должен покрывать именно открываемый домен и нужный www-вариант.
Практическая диагностика · SSL/TLS
SSL-сертификат установлен, но браузер показывает ошибку: что проверить
Зелёный статус в панели хостинга ещё не гарантирует корректный HTTPS. Браузер проверяет имя домена, срок действия, цепочку доверия и сертификат, который реально отдаёт сервер на порту 443. Разбираем, где чаще всего возникает несоответствие.
Быстрый маршрут
Что проверить за первые 5 минут
Сначала фиксируем точный тип ошибки и сертификат, который браузер получает сейчас.
Проверить срок
Не истёк ли сертификат и корректно ли время на клиенте.
Проверить цепочку
Сервер должен отдавать промежуточные сертификаты.
Проверить SNI/443
На общем IP сервер обязан выбрать сертификат нужного домена.
Проверить DNS
Домен не должен вести на старый сервер с другим сертификатом.
Ошибка HTTPS почти всегда объясняется конкретным несоответствием.Нужно смотреть не сертификат «в панели», а тот, который реально получает браузер по нужному hostname.
Шаг 1
Сначала отделите ошибку имени, срока и доверия
Сообщение о несовпадении имени означает, что сертификат выпущен не для того hostname, который открыт. Ошибка срока связана с notBefore/notAfter или неверными часами клиента. Ошибка доверия обычно указывает на цепочку, самоподписанный сертификат или перехват трафика.
Точный текст браузера экономит время: разные классы ошибок требуют разных проверок.
Шаг 2
Проверьте, покрывает ли сертификат основной домен и www
Сертификат для www.example.ru не обязан автоматически покрывать example.ru, и наоборот. Wildcard вида *.example.ru обычно покрывает поддомены первого уровня, но не корневой домен, если он не добавлен отдельно.
После миграции часто забывают один из вариантов: редирект с www на non-www срабатывает уже после TLS-рукопожатия, поэтому сертификат должен быть валиден ещё до редиректа.
Шаг 3
Сервер должен отдавать не только leaf-сертификат
Промежуточный сертификат связывает сертификат сайта с доверенным корневым центром. Некоторые браузеры могут достроить цепочку из кеша, а другие клиенты — нет, поэтому ошибка выглядит непостоянной.
Проверяем fullchain и конфигурацию веб-сервера. Если после ручной установки загружен только cert.pem без промежуточных сертификатов, часть клиентов может считать соединение недоверенным.
То, что HTTPS работает на вашем компьютере, ещё не доказывает корректность цепочки для новых устройств и API-клиентов.
Шаг 4
Сертификат может быть правильным, но домен приходит не на тот сервер
Если A/AAAA ещё указывают на старый IP, браузер получает сертификат прежней машины. Это особенно похоже на «сертификат установлен, но не работает»: в новой панели он действительно установлен, просто запрос до неё не доходит.
Сравниваем A и AAAA, а при наличии CDN или прокси учитываем, какой сертификат завершается на внешнем слое.
Шаг 5
Проверяйте не только выпуск, но и фактическое автопродление
Let's Encrypt и другие автоматические сертификаты работают надёжно только пока challenge, DNS и конфигурация веб-сервера позволяют обновление. После смены DNS, firewall или document root автопродление может перестать проходить.
Проверяем дату следующего обновления заранее и смотрим журнал renewal. Ручное перевыпускание каждые три месяца — признак, что автоматизация фактически не работает.
Практический пример
На основном домене HTTPS работает, на www — ошибка сертификата
После перевыпуска сертификата example.ru открывается нормально, но www.example.ru показывает предупреждение. Редирект с www на основной домен настроен, поэтому кажется, что проблема должна исчезнуть сама.
Проверка показывает: TLS-рукопожатие происходит раньше HTTP-редиректа, а сертификат содержит только example.ru. Добавляем www в SAN, перевыпускаем сертификат и проверяем, какой vhost отвечает на 443.
| Проверка | Результат |
|---|---|
| example.ru | сертификат валиден |
| www.example.ru | hostname mismatch |
| после перевыпуска | оба имени проходят TLS до редиректа |
Типовые сценарии
Как сопоставить ошибку и причину
Тип ошибки браузера часто почти напрямую указывает на нужный слой проверки.
| Симптом | Вероятная причина | Что делать |
|---|---|---|
| Сертификат для другого домена | не тот vhost/SNI или старый сервер | проверить DNS и конфигурацию 443 |
| Истёк срок | не сработало автопродление | обновить сертификат и починить renewal |
| Недоверенная цепочка | не хватает intermediate | установить fullchain |
| Работает без www, с www ошибка | www не покрыт сертификатом | добавить hostname и перевыпустить |
| Ошибка только у части клиентов | цепочка, IPv6 или прокси | сравнить сертификат и DNS с разных сетей |
Чего не делать
Типичные действия, которые мешают диагностике
Смотреть только статус в панели
Панель не доказывает, какой сертификат реально отдаёт сервер.
Надеяться на редирект
TLS проверяется раньше HTTP-редиректа.
Удалять HTTPS-конфигурацию целиком
Можно сломать рабочие hostname вместо локального исправления.
Игнорировать AAAA
IPv6 может вести на другой сервер и другой сертификат.
Чек-лист
Проверка ошибки SSL/TLS
- Зафиксировать текст ошибки: Имя, срок или доверие.
- Проверить hostname: Сертификат покрывает основной домен и www.
- Проверить даты: notBefore/notAfter и часы клиента.
- Проверить цепочку: Сервер отдаёт intermediate.
- Проверить DNS: A/AAAA ведут на ожидаемый сервер.
- Проверить SNI: 443 выбирает сертификат нужного сайта.
- Проверить редиректы: Нет циклов после успешного TLS.
- Проверить автопродление: Renewal реально проходит.
- Сравнить сети: Исключить старый DNS/IPv6.
- Повторить SSL-тест: Подтвердить исправление извне.
Когда нужен доступ к проекту
Какие данные ускоряют диагностику
Если сервер отдаёт другой сертификат, чем установлен в панели, нужен доступ к конфигурации 443, SNI и списку virtual host. При прокси/CDN дополнительно проверяется внешний TLS-слой.
Передавать пароли в текст статьи или публичную переписку не нужно. Для рабочей диагностики доступы выдаются отдельно и только к тем системам, которые действительно нужны для проверки.
Вопросы
Короткие ответы
Почему сертификат установлен, а браузер видит другой?
Запрос может приходить на другой IP или другой virtual host на том же сервере.
Редирект с www на без-www решает ошибку сертификата?
Нет, потому что TLS устанавливается до выполнения HTTP-редиректа.
Почему ошибка есть только на старом телефоне?
Возможны проблемы цепочки доверия, старого TLS-стека или кеша DNS.
Нужно ли перевыпускать сертификат после каждой смены IP?
Обычно нет: сертификат привязан к имени, но новый сервер должен иметь его корректную конфигурацию.