Если браузер показывает `NET::ERR_CERT_COMMON_NAME_INVALID`, сайт может быть доступен технически, но посетитель всё равно видит предупреждение о небезопасном соединении. Для владельца это неприятная ситуация: сервер отвечает, а клиент не доходит до страницы, формы заказа или личного кабинета.
Обычно ошибка означает, что адрес в строке браузера не совпадает с именами, на которые выпущен SSL-сертификат. Ниже разберём, где возникает несоответствие, как проверить проблему и что исправлять в первую очередь.
Что означает NET::ERR_CERT_COMMON_NAME_INVALID
При открытии сайта по HTTPS браузер проверяет не только срок действия SSL-сертификата. Он сверяет, подходит ли сертификат для имени, которое открыл пользователь: `example.ru`, `www.example.ru`, `shop.example.ru` или другой поддомен.
Если сертификат выдан на один адрес, а посетитель пришёл на другой, браузер не может подтвердить, что соединение установлено с нужным сайтом. Поэтому он показывает `NET::ERR_CERT_COMMON_NAME_INVALID` или похожее предупреждение о несовпадении имени сертификата.
Для владельца сайта смысл простой: каждый публичный адрес, который должен открываться по HTTPS, обязан быть покрыт сертификатом и корректно обслуживаться сервером, CDN или прокси.
Почему появляется ошибка
Сертификат выпущен не на тот домен
Самый прямой сценарий: на сервере установлен сертификат для другого домена. Например, сайт переехал с тестового адреса на основной, но веб-сервер всё ещё отдаёт сертификат от старого проекта. Страница может отвечать, но HTTPS-проверка не проходит.
Практический пример: владелец открывает `new.example.ru`, а сертификат выдан на `old.example.ru`. Для администратора это может выглядеть как мелкая конфигурационная ошибка, но для браузера имя сайта не совпадает с цифровым удостоверением.
Не учтён вариант с www или без www
`example.ru` и `www.example.ru` технически разные имена. Если сертификат покрывает только один вариант, второй может показывать ошибку. Особенно часто это проявляется после переноса на новый хостинг, ручного выпуска SSL или изменения основного зеркала сайта.
Проверьте оба адреса отдельно. Если один вариант открывается, а второй нет, пригодится подробный чеклист про сайт с www и без www.
Поддомен не входит в сертификат
Сертификат на основной домен не всегда покрывает поддомены. Wildcard-сертификат вида `*.example.ru` обычно закрывает поддомены первого уровня, например `shop.example.ru`, но не гарантирует покрытие более глубоких адресов вроде `api.dev.example.ru`.
Практический пример: главная страница открывается нормально, а форма оплаты на `pay.shop.example.ru` показывает ошибку. Проверка только главной страницы такой сбой не обнаружит.
CDN или прокси отдаёт не тот сертификат
Если сайт работает через CDN, WAF или обратный прокси, посетитель видит сертификат внешнего слоя. На origin-сервере может быть один сертификат, на CDN - другой. Ошибка появится, если внешний слой не знает нужный домен, сертификат ещё не выпущен или DNS уже переключён раньше, чем HTTPS-конфигурация стала готова.
Такое часто бывает при быстрых изменениях: подключили домен к CDN, поменяли DNS, включили проксирование, но не проверили каждый поддомен снаружи.
Редирект ведёт на адрес без подходящего SSL
Иногда пользователь открывает рабочий адрес, но сервер сразу перенаправляет его на другой вариант домена. Если конечный адрес не покрыт сертификатом, посетитель увидит SSL-ошибку уже после редиректа.
Пример: `https://example.ru` отправляет на `https://www.example.ru`, но сертификат выпущен только для корневого домена. Владелец проверяет первый адрес и не сразу замечает, что фактическая ошибка происходит на втором.
Сервер неправильно выбирает сертификат
На одном IP-адресе могут работать разные сайты и сертификаты. Если виртуальный хост, SNI или конфигурация панели настроены неверно, сервер может отдать сертификат соседнего сайта. Это особенно заметно после ручной правки Nginx, Apache, балансировщика или панели хостинга.
Как проверить проблему вручную
Запишите точный проблемный адрес
Не начинайте с общей формулировки «сайт не открывается». Зафиксируйте полный URL: протокол, домен, `www`, поддомен и путь страницы. Для SSL-ошибок разница между `https://example.ru`, `https://www.example.ru` и `https://shop.example.ru` принципиальна.
Сравните имена в сертификате с адресом страницы
Откройте сведения о сертификате в браузере или используйте внешний SSL-чекер. Смотрите не только срок действия, но и список доменных имён. Адрес, который открыл пользователь, должен быть в этом списке или подходить под wildcard.
Если нужно освежить базовую проверку, можно использовать инструкцию как проверить SSL-сертификат сайта.
Проверьте основные варианты домена
Минимальный набор для ручной проверки:
- `https://example.ru/`;
- `https://www.example.ru/`;
- важные поддомены, например `shop`, `api`, `lk`, `pay`;
- страницы после редиректа из рекламы, писем и поисковой выдачи.
Важно дойти до конечного адреса после всех редиректов. Ошибка может быть не на первой странице, а на адресе, куда пользователя перенаправили.
Проверьте сертификат командой
Если есть доступ к терминалу, можно посмотреть сертификат, который отдаёт сервер для конкретного имени:
```bash openssl s_client -connect example.ru:443 -servername example.ru -showcerts ```
Для поддомена подставьте его и в `-connect`, и в `-servername`. В выводе ищите доменные имена сертификата, срок действия и возможные ошибки проверки цепочки. Если сервер отдаёт сертификат чужого домена, проблема почти наверняка в конфигурации виртуального хоста, CDN или прокси.
Сверьте DNS и внешний слой
Проверьте, куда указывает проблемное имя: на текущий хостинг, CDN, балансировщик или старый сервер. Если DNS уже ведёт на новую точку, а сертификат там ещё не готов, браузер будет ругаться даже при рабочем origin-сервере.
Что исправлять в первую очередь
Выпустить сертификат на все нужные имена
Составьте список публичных адресов, которые должны работать по HTTPS: основной домен, `www`, поддомены для магазина, API, личного кабинета, оплаты, статических файлов. Сертификат должен покрывать каждый адрес или корректный wildcard-вариант.
Настроить единый канонический адрес
Выберите основной вариант домена и приведите редиректы к предсказуемой схеме. Пользователь может вводить разные варианты, но в итоге должен попадать на адрес, который покрыт сертификатом и обслуживается правильным виртуальным хостом.
После настройки проверьте не только главную, но и несколько важных страниц: карточку товара, форму заявки, страницу оплаты, личный кабинет.
Проверить CDN, прокси и хостинг
Если домен обслуживается через внешний слой, убедитесь, что домен добавлен туда полностью, SSL активен, а режим подключения к origin не маскирует ошибку. Отдельно проверьте, не остался ли поддомен на старом IP или в старой зоне DNS.
Несовпадение имени может идти рядом с другой SSL-проблемой: неполной цепочкой сертификата. Если браузеры ведут себя по-разному, стоит проверить и этот слой. Подробнее об этом есть отдельная статья про цепочку SSL-сертификата.
Чем опасна ошибка для бизнеса и SEO
Главный риск в том, что посетитель не видит ваш контент. Он видит предупреждение браузера и часто закрывает страницу. Для интернет-магазина это может сорвать переход к оплате, для сервиса - авторизацию, для B2B-сайта - отправку формы заявки.
Для поиска проблема тоже практическая. Если робот приходит на HTTPS-страницу и не может получить нормальный ответ из-за ошибки сертификата, он не считывает страницу как обычно. Один короткий сбой не стоит превращать в катастрофу, но повторяющаяся недоступность мешает стабильному обходу сайта и ухудшает контроль над посадочными страницами.
Как мониторинг помогает заметить проблему раньше
Ручная проверка почти всегда запаздывает: владелец узнаёт о проблеме после жалобы, падения заявок или странного поведения рекламы. Автоматический мониторинг полезен тем, что регулярно проверяет сайт снаружи и помогает увидеть, что важный адрес перестал открываться корректно.
Web-Puls помогает контролировать доступность сайта и быстрее заметить проблемы с HTTPS, которые не видны при случайной проверке главной страницы. Для SSL-тем особенно полезно проверять не один URL, а все важные точки входа: основной домен, `www`, поддомены, формы и страницы после редиректа.
Если нужно не только получить уведомление, но и разобраться с DNS, SSL, CDN или хостингом, можно отправить заявку через форму профессиональной поддержки или воспользоваться контактной информацией.
Вывод
`NET::ERR_CERT_COMMON_NAME_INVALID` означает, что браузер не видит совпадения между открытым адресом и именами в SSL-сертификате. Начинайте проверку с точного URL, списка имён в сертификате, вариантов с `www`, поддоменов, редиректов и внешнего слоя вроде CDN.
После исправления важно проверить сайт не только из своей сети и не только по главной странице. Чем раньше вы заметите несовпадение сертификата и домена, тем меньше посетителей увидят предупреждение вместо сайта.