Почему сервер по HTTPS выдаёт сертификат другого домена

#Что происходит и когда применима инструкция

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

#Причины: как различить похожие случаи

#Диагностика и пошаговое устранение

1. 1. Убедитесь, какое имя указано в адресной строкеОткройте адрес именно как https://example.com, а не https://IP. Предупреждение о чужом имени не обходите: это может быть как ошибка виртуального хоста, так и реальный подменённый сервер. Если ошибка возникает только при обращении к числовому IP, это не всегда неисправность SNI для домена — сравнивать нужно запросы с заданным именем.

1. 2. Сравните TLS-запрос с SNI и без негоВ терминале Linux/macOS с OpenSSL выполните два подключения к одному и тому же адресу. В первом укажите -servername example.com; во втором -noservername, если OpenSSL поддерживает этот параметр. Выведите сертификат каждой команды через openssl x509 -noout -subject -issuer -ext subjectAltName. Если с SNI имя правильное, а без него соседнее — проверьте тип клиента, а не меняйте сертификат для всех сайтов.
2. Замените имя

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   Замените имя. Это основной проверочный запрос с SNI; второй без SNI используйте отдельно по документации вашей версии OpenSSL.

   echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName

1. 3. Проверьте публичные IP и внешние проксиПолучите A/AAAA и выясните, где заканчивается TLS: локальный Nginx, CDN, балансировщик или панель. Если через IPv4 сертификат правильный, а IPv6 чужой, проблема может быть в AAAA или отдельном IPv6-виртуальном хосте; исправлять SNI в другом узле бессмысленно.
2. example.com заменить доменом; команды только для просмотра

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   example.com заменить доменом; команды только для просмотра.

   dig +short A example.com

   dig +short AAAA example.com

1. 4. Найдите нужный блок NginxЕсли TLS заканчивается на Nginx, подключитесь по SSH и выполните sudo nginx -T. Ищите listen 443 ssl, listen [::]:443 ssl, server_name example.com и ssl_certificate. Учитывайте конкретную пару адрес/порт; одинаковые имена в конфликтующих блоках могут игнорироваться. Вывод nginx -T может содержать секреты — не публикуйте целиком. Если используется Apache, посмотрите apachectl -S вместо nginx.

1. 5. Сохраните рабочую конфигурацию и исправьте привязкуПеред правкой скопируйте исходный файл server-блока либо экспортируйте настройки панели. Укажите точное server_name домена и ssl_certificate с правильным fullchain для нужного HTTPS-блока, сохраняя соответствующий ssl_certificate_key. Не назначайте сертификат одной площадки глобально на все серверы. Если имя обслуживается панелью, правьте там, чтобы её генератор не перезаписал изменения.

1. 6. Проверьте конфигурацию и примените еёВ Nginx сначала sudo nginx -t — ожидается syntax is ok и test is successful. Только при успешном тесте запустите sudo systemctl reload nginx; при ошибке верните копию и повторите тест. Если Nginx предупреждает о конфликтующих server name, устраните конфликт конкретного имени до применения.

   Linux · Терминал (Bash)С осторожностьюНужен sudoКопировать всёВыделить

   Выполнять второй вызов только при успешной проверке первого. Команда перезагрузки выполняется только при успешной проверке конфигурации (оператор &&). При ошибке исправьте конфигурацию и повторите проверку; не запускайте перезагрузку вручную.

   sudo nginx -t && sudo systemctl reload nginx

   Команда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.

1. 7. Проверьте правильный IP напрямую, без смены DNSЕсли у домена есть несколько серверов, команда curl --resolve позволяет послать HTTPS-запрос с правильным SNI и Host к одному выбранному IP. Укажите фактический адрес, а не оставляйте демонстрационный 192.0.2.10. Повторите для каждого A/AAAA и внешнего прокси. При ошибке сертификата не добавляйте -k: иначе скрывается именно та неисправность, которую нужно найти.

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   Заменить домен и документационный IP действительными. Сохраняет стандартную проверку TLS.

   curl -I --resolve example.com:443:192.0.2.10 https://example.com/

1. 8. Подтвердите работу для посетителей и способ откатаС разных сетей откройте HTTPS по имени, проверьте отсутствие предупреждений, SAN правильного сертификата и срок действия. Если тест на одном IP успешен, а публично нет — проверьте второй IP, CDN и кэши. Если результат стал хуже, восстановите сохранённые директивы конкретного виртуального хоста и проведите проверку/reload; не меняйте default_server чужого проекта.

#Как проверить, что неисправность устранена

При TLS-подключении с SNI настоящего домена сервер предлагает сертификат с этим именем в SAN. Проверки каждого A/AAAA и публичной точки входа дают тот же корректный результат, браузеры не предупреждают о другом домене.

#Если не получилось и как отменить правки

Верните старый блок конфига из резервной копии и выполните nginx -t перед reload. Если неверная привязка создана панелью хостинга, отмените изменение в панели. Не заменяйте глобальный сертификат default_server ради одного виртуального хоста.

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