#Что происходит и когда применима инструкция
После переноса сайта на новый сервер появляется предупреждение «сертификат не соответствует имени». Причиной бывает не только новый сервер, но и временный адрес, оставшаяся запись AAAA, старый CDN или проверка по IP вместо имени домена.
#Основные причины и их признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| На новом узле чужой сертификатНовый виртуальный хост не содержит корректной TLS-привязки. | Подключение по SNI выдаёт сертификат соседнего сайта | Добавьте домен и сертификат в новый виртуальный узел. |
| DNS ещё ведёт на прежний адресКеш DNS либо разные записи A/AAAA направляют клиентов не туда. | Разные сети показывают разные сертификаты | Сравните все публичные адреса и узлы. |
| Проверяют сервер по IPОбычный сертификат доменного имени не обязан подтверждать прямой IP. | У браузера в адресной строке IP, а сертификат выпущен на домен | Проверяйте исходный домен с SNI. |
#Пошаговая диагностика и устранение
- Соберите эталон прежней и новой конфигурацииУточните основное доменное имя, старый и новый публичные IP, используемый CDN и время переключения. Запишите, что именно показывает браузер: ошибку имени, недоверенную цепочку или истечение срока. Эти ошибки требуют разного решения.
- Проверьте DNS из нескольких сетейНа локальном компьютере выполните
dig +shortдля A и AAAA. Сравните ответы с настройками регистратра или авторитетного DNS. Не удаляйте старый сервер, пока есть подтверждённые запросы по старым адресам. - Без администратора; только запросы DNSLinux · Терминал (Bash)КомандаБез администратора; только запросы DNS. Замените домен, учитывайте собственную систему кеширования.
dig +short example.com A; dig +short example.com AAAA
- Проверьте новый сервер напрямую с правильным именемДля проверки ещё до смены DNS воспользуйтесь
curl --resolve: соединение идёт на выбранный IP, но имя HTTPS остаётся доменным. Не используйте-k, иначе проверка правильности сертификата будет отключена.Linux · Терминал (Bash)КомандаLinux/macOS/Windows с curl; замените TEST-NET IP реальным новым IP и домен. При верном сертификате нет ошибки проверки TLS.curl -Iv --resolve example.com:443:192.0.2.10 https://example.com/
- Проверьте сертификат и SAN нового сервераВ панели хостинга нового сервера найдите сертификат сайта и перечень имён SAN. Убедитесь, что в нём именно исходный домен, а не техническое имя сервера. При выпуске через ACME добавьте правильные записи DNS и выполните предусмотренную проверку владения.
- Найдите нужный виртуальный хостДля Nginx проверьте
server_name,listen 443 sslиssl_certificate, для Apache —ServerName,ServerAliasи файл сертификата. Если сервер управляется панелью, редактируйте через панель, а не параллельно вручную. Сохраните конфигурацию до изменения.
- Исправьте привязку и проверьте синтаксисПривяжите корректную цепочку и ключ к нужному домену, проверьте конфигурацию штатной командой веб-сервера, затем примените через мягкую перезагрузку. Если ключ не соответствует сертификату, сервер может не стартовать; при ошибке восстановите резервную версию.
- Проверьте отдельный IPv6 и CDNУзнайте, заканчивается ли HTTPS на CDN. Проверьте внешний сертификат CDN и сертификат исходного сервера как два разных комплекта. Отдельная AAAA-запись может обслуживать старую машину, пока A уже указывает на новую.
- Проверьте окончательное переключениеПосле изменения посмотрите сайт из двух сетей и повторите
curl --resolveдля каждого адреса, обслуживающего домен. Убедитесь, что главная, вход в систему и обращения API не имеют предупреждений TLS и всё ещё работают после отключения временного режима.
#Проверка результата
Новый сервер отвечает на доменное HTTPS-имя корректным сертификатом с нужным SAN, в публичном DNS нет забытых адресов, а на всех узлах CDN/прокси выдаётся правильная цепочка.
#Если решить проблему не удалось
Если предупреждение есть только в одной сети, сохраните её DNS-ответы, фактический IP, отпечаток сертификата и время. Не объясняйте это «кешем браузера» без проверки: нередко существует отдельный IPv6 либо второй балансировщик.