#Что происходит и когда применима инструкция
Браузер открывает https://www.example.com, но https://example.com получает ошибку несоответствия имени. Сертификат может защищать только вариант www, а редирект с голого домена не исправит начальный TLS-обмен: сертификат проверяется до HTTP-перенаправления.
#Основные причины и их признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| В SAN отсутствует основной доменНаличие www не распространяется автоматически на имя без www. | В сертификате указан только www.example.com | Выпустите сертификат с обоими именами. |
| На голом домене другой серверБез www запрос попадает на другой хостинг или IPv6-узел. | A/AAAA и CNAME ведут на разные устройства | Сравните DNS и выдаваемые сертификаты. |
| Виртуальные узлы настроены отдельноSNI выбирает блок, у которого нет нужного сертификата. | Оба имени ведут на один IP, но отдаются разные сертификаты | Проверьте server_name/ServerName и TLS-файлы. |
#Пошаговая диагностика и устранение
- Сравните оба адреса отдельноОткройте в новом окне именно
https://example.comиhttps://www.example.com. Запишите текст предупреждения, сертификат и время. На первом шаге не нажимайте продолжение на небезопасный сайт, особенно если там вводят пароли.
- Посмотрите список имён в сертификатеВ информации о сертификате браузера найдите Subject Alternative Name (SAN). Для современной проверки важен именно SAN; отсутствие
example.comобъясняет сбой без www. Сравните также срок действия, чтобы не смешать две ошибки.
- Проверьте адреса DNSНа компьютере с
digзапросите A и AAAA обоих имён. Убедитесь, что они ведут на ожидаемый хостинг или CDN. Если указан сторонний сервис, перепроверьте, что домен добавлен в его настройки, прежде чем менять записи. - Linux/macOS с dig, только чтение; подставьте свой доменLinux · Терминал (Bash)КомандаLinux/macOS с dig, только чтение; подставьте свой домен. Отсутствие AAAA не обязательно ошибка.
dig +short example.com A; dig +short example.com AAAA; dig +short www.example.com A
- Проверьте ответы одного сервера с SNIПодключитесь к
example.com:443с-servername example.com, затем повторите для www. Если результаты различаются, зафиксируйте, какой сертификат получил каждый вариант имени и на каких IP. - Терминал с OpenSSL; вывод диагностическийLinux · Терминал (Bash)КомандаТерминал с OpenSSL; вывод диагностический. Проверяйте также цепочку и SAN, одна команда не подтверждает все проверки.
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null
- Подготовьте новый сертификат с обоими именамиВ панели сертификатов укажите и
example.com, иwww.example.com, выберите поддерживаемую проверку владения доменами. Для Certbot уточните текущий способ установки и имена в существующем сертификате; не удаляйте старую действующую пару ключей до проверки новой.
- Привяжите сертификат к обоим именамВ панели сайта либо виртуальном хосте Nginx/Apache укажите оба имени и проверьте, что именно эта конфигурация обслуживает оба адреса. Если внешним TLS управляет CDN, настройте сертификат там, а не только на исходном сервере.
- Настройте перенаправление после TLSКогда оба HTTPS-имени дают доверенный сертификат, выберите канонический адрес и добавьте корректное 301/308-перенаправление на него. Проверьте один переход без бесконечного цикла; редирект не должен быть единственным способом скрыть неправильный сертификат.
- Проверьте повторно без кешаПроверьте оба варианта имени в новой вкладке, с мобильного устройства и через командную TLS-проверку. Убедитесь, что сертификат валиден до любого перенаправления, а посетитель видит конечный URL без предупреждений.
#Проверка результата
И www, и основной домен проходят проверку TLS по SAN; при выбранном перенаправлении конечный адрес один, без предупреждений и циклов. Сертификат покрывает оба имени во всех точках подключения.
#Если решить проблему не удалось
Если один вариант всё ещё ведёт на старый сертификат, проверьте распространение DNS, отдельный AAAA, прокси и IP балансировщика. Не удаляйте DNS-записи наугад, пока не выяснили, какие сервисы ими пользуются.