NET::ERR_CERT_COMMON_NAME_INVALID: что значит ошибка и как исправить

NET::ERR_CERT_COMMON_NAME_INVALID означает, что браузер не доверяет SSL-сертификату сайта, потому что имя домена в сертификате не совпадает с адресом, который пользователь открыл. Проще говоря, сертификат выпущен не для этого домена или сервер отдаёт не тот сертификат.

Ошибка чаще всего появляется в Google Chrome, но похожая проблема может быть в Firefox, Edge, Safari и мобильных браузерах. Обычно причина связана с SSL-сертификатом, www/non-www версией сайта, DNS, Cloudflare, Nginx, Apache или неправильной настройкой хостинга.

Quick Fix

  • Проверьте, открываете ли вы правильный адрес сайта: https://example.com или https://www.example.com.
  • Откройте сайт в режиме инкогнито и в другом браузере.
  • Проверьте дату и время на устройстве.
  • Если вы владелец сайта, проверьте, для каких доменов выпущен SSL-сертификат.
  • Убедитесь, что сертификат покрывает обе версии: example.com и www.example.com.
  • Проверьте DNS-записи A, CNAME и AAAA.
  • Если сайт за Cloudflare, проверьте SSL/TLS mode и DNS-записи.
  • Проверьте, не отдаёт ли Nginx или Apache сертификат от другого сайта.
  • При необходимости перевыпустите SSL-сертификат для всех нужных доменов.

Что означает NET::ERR_CERT_COMMON_NAME_INVALID

NET::ERR_CERT_COMMON_NAME_INVALID — это ошибка SSL-сертификата. Она появляется, когда домен в адресной строке браузера не совпадает с доменом, указанным в сертификате.

Например, пользователь открывает:

https://example.com

А сервер отдаёт сертификат для:

www.example.com

Или ещё хуже — для другого домена:

another-site.com

В таком случае браузер считает соединение небезопасным и блокирует загрузку страницы.

Как выглядит ошибка

В Chrome сообщение обычно выглядит так:

Your connection is not private
NET::ERR_CERT_COMMON_NAME_INVALID

Также могут встречаться похожие сообщения:

  • SSL certificate does not match the domain name
  • Certificate name mismatch
  • Common name invalid
  • SSL_ERROR_BAD_CERT_DOMAIN
  • The certificate is only valid for another domain
  • This server could not prove that it is example.com

Если ошибка появляется у всех пользователей, проблема почти наверняка на стороне сайта. Если только у одного пользователя, стоит проверить кэш, дату, антивирус, VPN и DNS на его устройстве.

Основные причины NET::ERR_CERT_COMMON_NAME_INVALID

1. Сертификат выпущен не для того домена

Самая очевидная причина — SSL-сертификат установлен, но он не содержит домен, который открывает пользователь.

Например:

  • сертификат выпущен для example.com, но пользователь открывает www.example.com;
  • сертификат выпущен для www.example.com, но пользователь открывает example.com;
  • сертификат выпущен для старого домена;
  • сертификат выпущен для тестового домена;
  • сертификат установлен от другого сайта на том же сервере.

2. SSL не покрывает www и non-www версии

Очень частая проблема — сертификат установлен только на одну версию домена.

Есть две разные версии:

example.com
www.example.com

Для браузера это разные имена. Сертификат должен покрывать обе версии, если обе версии доступны пользователям.

Правильный вариант — выпустить сертификат сразу для:

example.com
www.example.com

3. Сервер отдаёт сертификат другого сайта

Если на одном сервере размещено несколько сайтов, Nginx или Apache может ошибочно отдавать сертификат от другого домена.

Это часто случается после:

  • миграции сайта;
  • добавления нового домена;
  • изменения server block в Nginx;
  • изменения VirtualHost в Apache;
  • неправильной настройки default server;
  • удаления старого SSL-сертификата.

4. DNS указывает на неправильный IP

Домен может указывать не на тот сервер. Например, вы установили SSL на новом VPS, но DNS всё ещё ведёт на старый сервер. Пользователь открывает ваш домен, а попадает на другой сервер с чужим сертификатом.

Проверьте:

  • A-запись домена;
  • CNAME для www;
  • AAAA-запись для IPv6;
  • DNS-записи в Cloudflare;
  • старые записи после миграции.

5. Неправильная AAAA-запись IPv6

Иногда A-запись указывает на правильный сервер, а AAAA-запись — на старый или другой сервер. Тогда часть пользователей может попадать на неправильный IP и видеть ошибку сертификата.

Если IPv6 на сервере не настроен, неправильную AAAA-запись лучше удалить или исправить.

6. Ошибка в Cloudflare

Если сайт подключён через Cloudflare, ошибка может быть связана с DNS или SSL/TLS-настройками.

Частые причины:

  • A-запись в Cloudflare указывает на неправильный IP;
  • www-запись настроена неправильно;
  • Cloudflare подключён к старому серверу;
  • на origin-сервере стоит сертификат для другого домена;
  • выбран режим Full (strict), но origin-сертификат не подходит;
  • сервер отдаёт неправильный сертификат Cloudflare.

7. Неправильный редирект

Если сайт перенаправляет пользователя на домен, который не покрыт сертификатом, появится ошибка.

Например:

  • редирект с example.com на www.example.com, но сертификата для www нет;
  • редирект с www на non-www, но сертификата для основного домена нет;
  • редирект на старый домен;
  • редирект на технический домен хостинга;
  • редирект на IP-адрес вместо домена.

8. Сертификат установлен только для поддомена

Сертификат для поддомена не всегда покрывает основной домен.

Например, сертификат для:

blog.example.com

не покрывает:

example.com

И наоборот. Если нужен один сертификат для многих поддоменов, используйте wildcard-сертификат:

*.example.com

Но важно: wildcard *.example.com не всегда покрывает сам корневой домен example.com. Его часто нужно добавлять отдельно.

9. Ошибка после миграции сайта

После переноса сайта на другой хостинг часто забывают перевыпустить SSL или обновить DNS. В результате домен открывает новый сайт, но сертификат остался от старого домена или старого сервера.

Проблема может появиться после:

  • смены хостинга;
  • смены IP сервера;
  • подключения Cloudflare;
  • смены домена WordPress;
  • клонирования сайта;
  • переноса с тестового домена на основной.

10. Старый кэш браузера или HSTS

Иногда проблема уже исправлена на сервере, но браузер продолжает использовать старые данные. Это бывает из-за кэша, HSTS или сохранённого SSL state.

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

Как исправить NET::ERR_CERT_COMMON_NAME_INVALID пользователю

1. Проверьте адрес сайта

Убедитесь, что вы открываете правильный домен. Проверьте, нет ли ошибки в написании:

  • лишняя буква;
  • неправильный домен;
  • старый адрес сайта;
  • технический домен хостинга;
  • неправильный поддомен.

Попробуйте открыть обе версии:

https://example.com
https://www.example.com

2. Откройте сайт в режиме инкогнито

Если сайт открывается в инкогнито, проблема может быть в кэше, cookies, расширениях или HSTS-данных браузера.

В Chrome используйте:

Ctrl + Shift + N

На Mac:

Command + Shift + N

3. Проверьте дату и время

Неправильная дата может вызвать SSL-ошибки. Проверьте:

  • дату;
  • время;
  • часовой пояс;
  • автоматическую синхронизацию времени.

После исправления перезапустите браузер.

4. Очистите кэш браузера

В Chrome откройте:

Настройки → Конфиденциальность и безопасность → Очистить данные браузера

Выберите:

  • cookies;
  • кэшированные изображения и файлы;
  • данные сайтов.

После очистки закройте и снова откройте браузер.

5. Очистите SSL state на Windows

  1. Откройте меню Start.
  2. Введите Internet Options.
  3. Перейдите во вкладку Content.
  4. Нажмите Clear SSL state.
  5. Перезапустите браузер.

6. Отключите VPN и прокси

VPN или прокси может направлять вас на другой сервер или ломать SSL-проверку. Отключите VPN и попробуйте открыть сайт напрямую.

Также проверьте сайт через мобильный интернет. Если через мобильную сеть всё работает, проблема может быть в Wi-Fi, DNS, VPN или провайдере.

7. Сбросьте DNS-кэш

На Windows откройте Command Prompt и выполните:

ipconfig /flushdns

На macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

После этого перезапустите браузер.

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

1. Проверьте, какие домены есть в сертификате

SSL-сертификат должен содержать домен, который открывает пользователь.

Проверьте, есть ли в сертификате:

example.com
www.example.com

Если используется поддомен, он тоже должен быть указан:

blog.example.com

Если нужного имени нет в сертификате, его нужно перевыпустить.

2. Перевыпустите SSL для www и non-www

Если используется Let’s Encrypt и Nginx:

sudo certbot --nginx -d example.com -d www.example.com

Если используется Apache:

sudo certbot --apache -d example.com -d www.example.com

После этого проверьте конфигурацию сервера.

Для Nginx:

sudo nginx -t
sudo systemctl reload nginx

Для Apache:

sudo apachectl configtest
sudo systemctl reload apache2

3. Проверьте DNS-записи

Проверьте A-запись:

dig example.com A

Проверьте www:

dig www.example.com A

Проверьте IPv6:

dig example.com AAAA

Если домен указывает на неправильный IP, исправьте DNS у регистратора, на хостинге или в Cloudflare.

4. Исправьте CNAME для www

Часто www должен быть настроен как CNAME на основной домен:

www → example.com

Или как A-запись на тот же IP, что и основной домен.

Главное — обе версии должны вести на сервер, где установлен правильный SSL-сертификат.

5. Удалите неправильную AAAA-запись

Если IPv6 не настроен, но в DNS есть AAAA-запись, браузер может идти по IPv6 на неправильный сервер.

Проверьте:

dig example.com AAAA

Если запись ведёт на старый или неизвестный сервер, удалите её или настройте SSL на IPv6-сервере.

6. Проверьте Nginx server block

В Nginx должен быть правильный server_name и правильные пути к сертификату.

Пример:

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    root /var/www/example.com;
    index index.php index.html;
}

Проверьте, нет ли дублирующих конфигов:

sudo grep -R "example.com" /etc/nginx/

Затем проверьте Nginx:

sudo nginx -t
sudo systemctl reload nginx

7. Проверьте Apache VirtualHost

В Apache должен быть правильный VirtualHost для порта 443.

Пример:

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com

    DocumentRoot /var/www/example.com/public_html

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
</VirtualHost>

Проверьте активные сайты:

ls -la /etc/apache2/sites-enabled/

Проверьте конфигурацию:

sudo apachectl configtest
sudo systemctl reload apache2

8. Проверьте default server

Если Nginx или Apache не находит подходящий блок для домена, он может отдать сертификат первого или default-сайта. Тогда пользователь видит сертификат от другого домена.

В Nginx проверьте блоки с:

default_server

Найдите их:

sudo grep -R "default_server" /etc/nginx/

Убедитесь, что default server не отдаёт чужой сертификат для вашего домена.

9. Проверьте Cloudflare

Если сайт работает через Cloudflare, проверьте:

  • DNS — A-запись должна указывать на правильный IP;
  • www — CNAME или A-запись должны быть правильными;
  • SSL/TLS mode — лучше Full или Full (strict);
  • Origin certificate — сертификат должен быть выпущен для нужного домена;
  • Universal SSL — должен быть активен;
  • Page Rules / Redirect Rules — не должно быть редиректа на домен без сертификата.

Для теста можно временно переключить DNS-запись с оранжевого облака на серое. Если ошибка остаётся, проблема на origin-сервере или в DNS. Если исчезает, проверьте настройки Cloudflare.

10. Проверьте WordPress URL

В WordPress откройте:

Настройки → Общие

Проверьте:

  • Адрес WordPress (URL)
  • Адрес сайта (URL)

Они должны соответствовать реальному домену, для которого установлен SSL.

Например:

https://example.com

или:

https://www.example.com

Не используйте одновременно разные версии без правильного редиректа и SSL.

Правильный редирект www и non-www

Выберите одну основную версию сайта:

  • https://example.com
  • или https://www.example.com

Обе версии должны иметь SSL-сертификат. После этого настройте редирект на основную версию.

Редирект с www на non-www в Nginx

server {
    listen 443 ssl http2;
    server_name www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    return 301 https://example.com$request_uri;
}

Редирект с non-www на www в Nginx

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    return 301 https://www.example.com$request_uri;
}

Редирект через .htaccess для Apache

С www на non-www:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]
</IfModule>

С non-www на www:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]
</IfModule>

Не ставьте оба правила одновременно. Иначе можно получить редирект-луп.

NET::ERR_CERT_COMMON_NAME_INVALID после установки SSL

Если ошибка появилась сразу после установки сертификата, проверьте:

  • сертификат выпущен для правильного домена;
  • в сертификате есть и www, и non-www;
  • сертификат установлен в правильный VirtualHost или server block;
  • DNS указывает на сервер с этим сертификатом;
  • Cloudflare не направляет трафик на старый IP;
  • не остался старый сертификат в панели хостинга;
  • порт 443 открыт и обслуживает нужный сайт.

NET::ERR_CERT_COMMON_NAME_INVALID после миграции сайта

После переноса сайта проверьте такой порядок:

  1. DNS A-запись указывает на новый сервер.
  2. www-запись указывает на новый сервер.
  3. AAAA-запись удалена или настроена правильно.
  4. SSL выпущен на новом сервере.
  5. Nginx или Apache отдаёт правильный сертификат.
  6. Cloudflare DNS обновлён.
  7. Кэш CDN очищен.
  8. WordPress URL соответствует основному домену.

Advanced Troubleshooting

Проверьте, какой сертификат отдаёт сервер

Если у вас VPS, можно проверить сертификат через OpenSSL:

openssl s_client -connect example.com:443 -servername example.com

В выводе ищите домен сертификата и список SAN-имён. Нужный домен должен быть в сертификате.

Проверьте дублирующиеся конфиги

Для Nginx:

sudo grep -R "server_name" /etc/nginx/sites-enabled/
sudo grep -R "example.com" /etc/nginx/

Для Apache:

sudo grep -R "ServerName" /etc/apache2/sites-enabled/
sudo grep -R "example.com" /etc/apache2/

Если один и тот же домен указан в нескольких местах, сервер может использовать не тот конфиг.

Проверьте SNI

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

Проблема чаще встречается на старых серверах, старых панелях хостинга или при ручной настройке нескольких SSL-сайтов на одном IP.

Проверьте wildcard-сертификат

Wildcard-сертификат вида:

*.example.com

покрывает:

blog.example.com
shop.example.com
app.example.com

Но он может не покрывать сам домен:

example.com

Поэтому корневой домен лучше добавлять отдельно при выпуске сертификата.

Проверьте старый сертификат в панели хостинга

На shared-хостинге иногда остаётся старый сертификат, даже если вы уже выпустили новый. Откройте раздел SSL/TLS и проверьте, какой сертификат привязан к домену.

Если панель позволяет, удалите старый SSL и установите новый заново.

Чего не стоит делать

  • Не игнорируйте предупреждение браузера на рабочем сайте.
  • Не советуйте пользователям нажимать “Продолжить небезопасно”.
  • Не ставьте сертификат только для www, если сайт открывается без www.
  • Не удаляйте SSL-сертификат без возможности быстро перевыпустить его.
  • Не меняйте DNS, SSL, Cloudflare и редиректы одновременно без проверки.
  • Не оставляйте неправильную AAAA-запись после миграции.

Как предотвратить NET::ERR_CERT_COMMON_NAME_INVALID

  • Всегда выпускайте SSL для всех нужных имён домена.
  • Покрывайте обе версии: example.com и www.example.com.
  • После миграции проверяйте DNS и SSL на новом сервере.
  • Удаляйте старые и дублирующиеся конфиги Nginx или Apache.
  • Не оставляйте неправильные AAAA-записи.
  • Проверяйте Cloudflare DNS перед включением прокси.
  • Выберите одну основную версию сайта и настройте 301-редирект.
  • Проверяйте SSL после смены домена, хостинга или CDN.

Когда обращаться в поддержку хостинга

Обратитесь в поддержку, если:

  • вы не можете перевыпустить SSL-сертификат;
  • панель хостинга показывает SSL как активный, но браузер видит ошибку;
  • сервер отдаёт сертификат другого домена;
  • вы не знаете, где изменить www или non-www настройки;
  • ошибка появилась после миграции;
  • домен работает через Cloudflare, но origin-сервер отдаёт неправильный сертификат;
  • у вас нет доступа к Nginx или Apache конфигам.

Перед обращением подготовьте домен, скрин ошибки, информацию о www/non-www версии, время появления проблемы и данные о последней смене DNS, SSL или хостинга.

FAQ

Что значит NET::ERR_CERT_COMMON_NAME_INVALID?

Это значит, что SSL-сертификат не совпадает с доменом, который пользователь открыл. Браузер ожидал сертификат для одного домена, а сервер отдал сертификат для другого имени.

Как быстро исправить NET::ERR_CERT_COMMON_NAME_INVALID?

Проверьте, покрывает ли SSL-сертификат обе версии домена: example.com и www.example.com. Затем проверьте DNS, Cloudflare, Nginx или Apache и при необходимости перевыпустите сертификат.

Почему ошибка появляется только на www?

Скорее всего, SSL-сертификат выпущен только для основного домена без www. Нужно перевыпустить сертификат и добавить www.example.com.

Почему ошибка появилась после переноса сайта?

Домен может указывать на старый сервер, новый сервер может отдавать старый сертификат, или SSL ещё не выпущен для нового IP. Проверьте DNS, Cloudflare и сертификат на новом хостинге.

Может ли Cloudflare вызвать эту ошибку?

Да. Если в Cloudflare указан неправильный IP, выбран строгий SSL-режим при неправильном origin-сертификате или DNS ведёт на старый сервер, может появиться ошибка имени сертификата.

Вывод

NET::ERR_CERT_COMMON_NAME_INVALID почти всегда означает несоответствие между доменом и SSL-сертификатом. Сначала проверьте, какой адрес открывает пользователь: www или non-www. Затем убедитесь, что сертификат покрывает эту версию домена.

Для владельца сайта лучший порядок действий такой: проверить SSL-сертификат, DNS, www/non-www, Cloudflare, Nginx или Apache. Если нужного домена нет в сертификате, перевыпустите SSL сразу для всех используемых имён.