My certificate's Common Name is correct. Why does Chrome still complain?

Chrome only checks the Subject Alternative Name extension. A certificate with the right CN but no matching SAN entry fails. Public CAs always add SANs, so this mostly affects self-made or internal certificates; regenerate them with -addext "subjectAltName=DNS:example.com".

Does a wildcard certificate cover the bare domain?

No. *.example.com matches exactly one label, so it covers www.example.com and shop.example.com but not example.com or a.b.example.com. Request both example.com and *.example.com in the same certificate.

I typed an IP address and got this error. Why?

Certificates are normally issued for names, not IP addresses. Visiting https://203.0.113.10 will fail unless the certificate contains that IP as an IP Address SAN. Use the hostname instead.

NET::ERR_CERT_COMMON_NAME_INVALID: hostname mismatch fixes

NET::ERR_CERT_COMMON_NAME_INVALID means the certificate is valid but was issued for a different hostname than the one you visited. It is almost always a site configuration problem: a missing www, a subdomain not on the certificate, or the server answering with another site's certificate.

Is it the site or your device?

This error is rarely caused by the visitor. Confirm with the SSL checker:

curl ssl.sh/example.com

The checker lists every name on the certificate. If the hostname you typed is missing, the site must fix it. The exceptions on the visitor side are: a typo or old bookmark pointing to a different hostname, a hosts-file entry or DNS filter sending you to the wrong server, and a captive Wi-Fi portal answering for every hostname (see captive portal errors).

Causes

1. www and bare domain not both covered

The certificate lists example.com, but the visitor typed www.example.com, or the reverse. Check the SAN list:

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

Fix: reissue with both names, for example certbot -d example.com -d www.example.com.

2. Wildcard depth or bare-domain gap

*.example.com does not match example.com or api.eu.example.com. Add the missing names explicitly or use a second wildcard for the deeper level.

3. The wrong virtual host answers (SNI)

On shared servers, Nginx serves the certificate of the default_server (or the first server block) when no block matches the requested name. A new subdomain without its own server_name gets another site's certificate. Check that each hostname has a server block with the right ssl_certificate.

4. CDN or load balancer has no certificate for this name

You added a domain to a CDN but did not upload or issue a certificate for it, so the edge presents a shared default certificate. Bind a certificate to every accelerated domain.

5. Certificate has CN only, no SAN

Self-generated certificates from old scripts may lack SANs entirely. Chrome rejects them regardless of the CN.

What it looks like in each browser

Browser	What you see
Chrome / Edge	"Your connection is not private" with `NET::ERR_CERT_COMMON_NAME_INVALID` and "its security certificate is from other-name"
Firefox	SSL_ERROR_BAD_CERT_DOMAIN
Safari	"This Connection Is Not Private"; details name the certificate's actual hostname
Internet Explorer / legacy Edge	DLG_FLAGS_SEC_CERT_CN_INVALID
curl	`SSL: no alternative certificate subject name matches target host name`

How site owners fix it

Reissuing the certificate with every hostname, and giving each hostname a matching server block, fixes it.

1. List what the certificate covers. The SSL checker and curl ssl.sh/example.com show the SAN list and which certificate each hostname receives.

2. Reissue with every hostname. With certbot or acme.sh, pass every name:

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

For wildcards you need DNS validation, for example acme.sh --issue --dns dns_cf -d example.com -d '*.example.com'.

3. Give each hostname a matching server block.

server {
    listen 443 ssl;
    server_name example.com www.example.com;
    ssl_certificate     /etc/nginx/ssl/example.com.fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;
}

4. Redirect, don't rely on the visitor. Once both names are covered, redirect one to the other with a 301 so links and bookmarks converge on a single canonical host.