NET::ERR_CERT_COMMON_NAME_INVALID: сертификат выпущен на другое имя

NET::ERR_CERT_COMMON_NAME_INVALID значит, что сертификат сайта выпущен на другое имя: в нём нет адреса, который вы открыли. Ошибка возникает при загрузке страницы по https: сервер ответил, но доказать, что он и есть example.ru, не смог. Chrome показывает заглушку «Подключение не защищено» и код ошибки под заголовком. Мы подняли стенд с десятью вариантами имён в сертификате, проверили 2056 сайтов организаций с www и без и открыли каждый проблемный адрес в Chromium.

Работает ли защищённое соединение у вашего сайта, можно посмотреть проверкой доступности: наш сервер запрашивает страницу и показывает код ответа, время отклика и срок SSL-сертификата.

Что означает ошибка

В каждом SSL-сертификате записано, для каких имён он выпущен. Главный список — поле Subject Alternative Name (SAN, альтернативные имена): там перечислены домены, например example.ru и www.example.ru, или маска вида *.example.ru. При открытии сайта браузер сравнивает адрес из строки с этим списком. Совпадения нет — соединение не считается безопасным, и появляется сообщение об ошибке.

Само слово Common Name в названии ошибки осталось с прошлых лет. Раньше имя сайта писали в поле Common Name (CN), теперь браузер его не читает. На стенде сертификат с CN=sayt.test и списком SAN из другого домена Chromium отверг, хотя CN совпадал с адресом.

Полный текст в Chromium 149 на русском, после нажатия «Дополнительные»:

Не удалось подтвердить, что это сервер sayt.test. Его сертификат безопасности относится к hosting.test. Возможно, сервер настроен неправильно или кто-то пытается перехватить ваши данные.

Имя после слов «относится к» — главная подсказка. Оно показывает, на какой домен выпущен сертификат, который отдал сервер.

Как посмотреть, на какое имя выпущен сертификат

Нажмите на значок «Не защищено» слева в адресной строке и выберите «Сертификат недействителен». На вкладке «Подробнее» найдите поле «Альтернативное имя субъекта сертификата»: там перечислены все адреса, для которых сертификат действует. Если вашего адреса в списке нет — причина найдена. Тут же видно, кем выпущен сертификат и до какого числа он действует: если срок истек, вероятно, вы столкнулись не с одной, а с несколькими поломками сразу.

Администратору сайта то же самое быстрее показать с помощью команды:

openssl s_client -connect example.ru:443 -servername example.ru </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName

Стенд: какие имена браузер принимает

Мы выпустили свой корневой сертификат, добавили его в доверенные Chromium и подняли nginx 1.22 с разными сертификатами. Адрес сайта везде один — sayt.test, меняется только список имён.

Что видно из стенда:

• Маска покрывает ровно один уровень. *.sayt.test подходит для sub.sayt.test, но не для самого sayt.test и не для a.b.sayt.test. Поэтому в сертификат с маской обычно добавляют и голый домен.
• www — отдельное имя. Сертификат на sayt.test не действует для www.sayt.test, и наоборот.
• Без SAN Chromium сертификат не принимает. Для сравнения мы открыли тот же сертификат в curl 7.88, Python 3.11 и Node 20 — все трое его приняли. Если у вас «в curl работает, а в браузере нет», проверьте, есть ли в сертификате список альтернативных имён.
• Кириллический домен записывается в сертификате в виде punycode. Адрес сайт.test браузер перевёл в xn--80aswg.test и открыл страницу.
• Сервер по умолчанию отдаёт свой сертификат. Мы настроили в nginx два сайта на одном адресе. Запрос на имя, которого нет в настройках, получил сертификат сайта по умолчанию и ошибку «относится к hosting.test». Именно так выглядит заглушка хостинга.

Ссылки «Перейти на сайт» может не быть

На обычной заглушке под кнопкой «Дополнительные» есть ссылка «Перейти на сайт sayt.test (небезопасно)». Мы открыли на стенде правильный сайт, который отдал заголовок Strict-Transport-Security (HSTS), а затем тот же адрес с чужим сертификатом. Ссылки не стало, а текст сменился:

На сайте sayt.test для защиты ваших данных обычно используется шифрование. Однако учетные данные, которые мы получили от сайта sayt.test сейчас, отличаются от тех, которые он отправляет обычно.

Кнопку обхода браузер в этом случае не показывает, и обойти такую заглушку нельзя. Это защита: если сайт раньше открывался безопасно, а теперь сертификат чужой, кто-то мог встать между вами и сервером.

Наш замер: 45 сайтов с этой ошибкой

18 октября 2026 года мы проверили сертификаты у сайтов организаций из нашего списка — 2056 доменов. Для каждого открыли защищённое соединение с адресом без www и с www и сверили имя. Без www по https ответили 1655 сайтов. У 46 сертификат был выпущен на другое имя. Все 46 мы открыли в Chromium: у 45 он показал ERR_CERT_COMMON_NAME_INVALID, а один открыл, сам перейдя на www.

У 33 сайтов из 46 сервер отдал заглушку хостинга или конструктора — сертификат на имя вида *.timeweb.ru. Так бывает, когда домен смотрит на сервер хостинга, а сайта с этим именем там нет или на него не выпущен сертификат. Ещё у 11 сертификат принадлежит совсем другому сайту, у трёх из них — крупным компаниям: amd.com, Google и Яндекс Маркет. Обычно это значит, что DNS домена указывает на чужой сервер.

Сайты, у которых не работает www

Отдельно мы посчитали домены второго уровня — 1775 адресов вида example.ru. У 1272 оба варианта, с www и без, работают. У 26 адрес без www в порядке, а www отдаёт сертификат с другим именем. У 14 из них сертификат выпущен только на вариант без www, у 12 — чужой.

Здесь мы заметили поведение Chromium, которого не ожидали. Мы открыли все 16 сайтов, где сертификат подходит к соседнему варианту адреса: 14 — без www вместо www и 2 — наоборот. У 13 браузер не показал ошибку, а сам, без предупреждения, перешёл на вариант из сертификата. У трёх ошибка осталась: у них соседний вариант отвечает перенаправлением 302 или кодом 404.

На стенде с нестандартным портом такого перехода не было. Поэтому полагаться на него не стоит: в других браузерах и программах ошибка остаётся.

Ещё 113 ошибок дал адрес с www перед поддоменом, например www.ekaterinburg.example.ru. Маска *.example.ru второй уровень не покрывает, как на стенде. Такими адресами почти никто не пользуется, но по ссылке с www посетитель увидит заглушку.

Наш nexforce.ru отдаёт сертификат с обоими именами — nexforce.ru и www.nexforce.ru, а с www перенаправляет кодом 301 на адрес без www.

Причины ошибки

На стороне сайта:

• сертификат выпущен на другой домен или поддомен;
• сертификат не покрывает www или, наоборот, голый домен;
• маска *.example.ru использована для адреса второго уровня или для самого example.ru;
• домен направлен на хостинг, но сайт к нему не привязан, и сервер отдаёт сертификат по умолчанию;
• после переезда DNS указывает на старый или чужой сервер;
• сертификат вообще не установлен, и сервер отдаёт сертификат панели управления или самого хостинга;
• в сертификате только поле CN без списка альтернативных имён.

На стороне посетителя — если ошибка появилась на многих сайтах сразу:

• публичный Wi-Fi со страницей входа может подставлять свою страницу и свой сертификат;
• прокси или VPN перенаправляет запросы на другой сервер;
• вирус или программа изменили файл hosts, и домен ведёт на чужой адрес;
• антивирус или корпоративная защита проверяют HTTPS со своими сертификатами.

Как исправить ошибку посетителю

Пользователь, который видит эту заглушку, чаще всего ни в чём не виноват. Если ошибка на одном сайте, исправить её можете не вы: сертификат устанавливает владелец. Но некоторые причины связаны с вашим устройством и сетью, поэтому выполните следующие шаги:

1. Проверьте адрес в строке. Опечатка в домене или лишний www — частая причина. Если сайт открывается без www, сохраните в закладки этот вариант.
2. Откройте страницу в режиме инкогнито — так видно, не мешают ли расширения. Затем откройте сайт через другую сеть, например с телефона по мобильному интернету. Если там всё в порядке, ищите причину в своей сети.
3. Если подключены к публичному Wi-Fi или сеть роутера в кафе блокирует доступ до входа, откройте любой сайт без https, чтобы появилась страница входа, и пройдите её.
4. Отключите VPN, прокси и расширения браузера, которые меняют соединение. Временный выход в интернет напрямую быстро покажет, связаны ли с ними проблемы.
5. Проверьте файл hosts: в Windows это C:\Windows\System32\drivers\etc\hosts, в macOS и Linux — /etc/hosts. Это системный файл, его содержимое обычно правят только программы. Лишняя строка с адресом сайта перенаправляет запросы туда, куда захотел тот, кто её дописал.
6. Обновите браузер, если у вас устаревшая версия. Если не помогло, перезапустите устройство.
7. Проверьте антивирус: некоторые из них проверяют HTTPS-трафик своими сертификатами. Отключите эту проверку на время и откройте сайт снова. Если сайт открылся при отключённой защите, дело в ней; после проверки сразу включайте защиту обратно.

Если другие способы не помогли и сайт по-прежнему не удается открыть, обратитесь к владельцу сайта, иначе ошибку не устранить: напишите адрес страницы и имя из строки «Его сертификат безопасности относится к …».

Время и дату на компьютере при этой ошибке трогать не нужно, настройка часов этому не поможет: неверная дата даёт NET::ERR_CERT_DATE_INVALID, а не эту ошибку.

Как исправить владельцу сайта

1. Посмотрите, какое имя в сертификате. Команда openssl выше или строка «относится к …» на заглушке покажут, чей сертификат отдаёт сервер.
2. Если это имя хостинга — привяжите домен к сайту в панели хостинга и выпустите сертификат на него. У многих хостингов для этого есть бесплатный сертификат Let's Encrypt в панели. Включите автоматическую замену, чтобы сертификат продлевался сам, и проверьте, что вместе с ним сервер получил и закрытый ключ.
3. Выпустите сертификат на оба варианта. Решения проще нет: впишите в него example.ru и www.example.ru, даже если вариант с www только перенаправляет. Перенаправление срабатывает уже после проверки сертификата, поэтому без правильного сертификата посетитель до него не дойдёт.
4. Проверьте DNS и конфигурацию. Записи A и AAAA для обоих вариантов должны указывать на сервер, где лежит сайт и сертификат.
5. Проверьте сервер по умолчанию. В nginx и Apache на одном адресе может работать много сайтов. Если имя сайта не попало в настройку, сервер отдаст сертификат другого.
6. Для поддоменов используйте маску *.example.ru и добавьте в сертификат сам example.ru. Адреса третьего уровня с www — отдельные имена.
7. После замены перезапустите веб-сервер, если панель не сделала этого сама, и проверьте сайт в браузере и командой openssl с обоими вариантами адреса.

Похожие ошибки

• Ваше подключение не защищено — общий разбор заглушки и всех кодов под ней.
• NET::ERR_CERT_AUTHORITY_INVALID — браузер не доверяет тому, кто выпустил сертификат.
• NET::ERR_CERT_DATE_INVALID — сертификат просрочен или неверны часы.
• NET::ERR_CERT_REVOKED — центр сертификации отозвал сертификат, перейти на сайт нельзя.
• SSL-сертификат сайта — как его выбрать и установить.

Границы замера

Стенд — nginx 1.22 и Chromium 149 на Linux со своим корневым сертификатом. Firefox, Safari и мобильные браузеры мы не проверяли. В обходе мы только устанавливали защищённое соединение и читали сертификат, страницы не запрашивали. Защита сайта или сервисов перед ним иногда отдаёт нашему серверу другой сертификат, чем посетителю из другой сети. Если доступ к сайту из нашей сети был закрыт, такой сайт мог попасть в замер как неответивший.

Коротко

NET::ERR_CERT_COMMON_NAME_INVALID — в сертификате нет имени, которое вы открыли. В нашем замере у 33 из 46 таких сайтов сервер отдавал заглушку хостинга, то есть сертификат на сайт просто не выпустили. Владельцу нужно выпустить сертификат на оба варианта адреса, с www и без, и проверить, куда указывает DNS. Посетителю — проверить адрес и сеть, а если ошибка на одном сайте, написать владельцу.