NET::ERR_CERT_COMMON_NAME_INVALID: What It Means and How to Fix It

NET::ERR_CERT_COMMON_NAME_INVALID is the error Chrome and other Chromium-based browsers show when the certificate a server presents is valid but does not cover the host name you visited. You asked for www.example.com, and the server answered with a certificate for example.com, or for *.shop.example.com, or for some other site entirely. The browser cannot confirm it is talking to the site you wanted, so it stops.

Firefox shows the same problem as SSL_ERROR_BAD_CERT_DOMAIN, and Safari says the certificate belongs to a different website. The fix is always one of two things: get a certificate that lists the right names, or make sure the right server, with the right certificate, answers for that name.

What the browser actually checks

Despite the error's name, modern browsers do not look at the certificate's Common Name (CN). They compare the host name in the address bar with the certificate's Subject Alternative Name (SAN) list. Chrome dropped Common Name matching in version 58 in 2017; a certificate that has a name only in the CN field fails in Chrome even if the CN is correct. Publicly trusted CAs put every name in the SAN list, so this mainly affects old self-signed or internal certificates.

To see the names a live certificate covers:

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

The output looks like this:

subject=CN=example.com
X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com

If the host name you visited is not in that list, and no wildcard entry matches it, the browser shows the error. Our free SSL certificate checker shows the same list without a terminal.

Wildcard rules

Wildcards are the most common source of confusion. The matching rules, set out in RFC 9525 and followed by browsers, are strict:

• The wildcard matches exactly one label. *.example.com covers www.example.com and api.example.com.
• It does not cover deeper levels. *.example.com does not cover eu.api.example.com. You need *.api.example.com or the exact name.
• It does not cover the bare domain. *.example.com does not cover example.com. Add the apex as its own SAN entry.
• The wildcard must be the whole leftmost label. Publicly trusted certificates use only the *.example.com form; patterns such as w*.example.com are not issued by public CAs.

Common causes

www and apex mismatch

A certificate issued only for example.com is used on www.example.com, or the reverse. This often appears when someone adds a redirect from one to the other: the redirect itself is served over HTTPS, so the host being redirected from also needs a valid certificate. Issue one certificate that covers both names:

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

A new subdomain that was never added

A team adds app.example.com or status.example.com in DNS and points it at an existing server, whose certificate lists only the old names. Expand the certificate (Certbot's --expand option, or reissue with the extra -d name) or issue a separate one for the new host.

DNS points at a new host before it has a certificate

During a migration to a new host or CDN, DNS starts sending visitors to the new provider before it has issued a certificate for your domain. Until it does, visitors get the provider's default certificate, for a host name like *.provider-cdn.net, which does not match. Most managed platforms issue the certificate within minutes of verifying the domain. Check the domain status in the provider's dashboard and, for future moves, verify the domain or pre-issue the certificate before switching DNS.

Shared hosting or the wrong virtual host

On a server hosting several sites, a request for a name that has no matching virtual host falls through to the default site, which serves its own certificate. In nginx, check that server_name lists every host name in the server block that has the right certificate:

server {
    listen 443 ssl;
    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;
}

Then confirm which block answers a given name with sudo nginx -T, which prints the full merged configuration.

SNI not sent

Servers that host several certificates on one IP address pick the right one using Server Name Indication (SNI), the host name the client sends at the start of the TLS handshake. A client that sends no SNI, or sends the wrong one, gets the default certificate. All current browsers send SNI; the usual culprits are old HTTP libraries, embedded devices and scripts that connect by IP address. When testing with OpenSSL, always pass -servername so the test matches what a browser does.

Visiting by IP address or an internal name

https://203.0.113.10/ or https://server01.internal/ will not match a certificate issued for example.com. Use the public host name, or for internal names, issue certificates from an internal CA that include those names.

A connection reused for the wrong name

With HTTP/2, a browser may reuse one connection for several host names when the certificate covers them all and they resolve to the same address. If the server is not configured for one of those names, it can reply with 421 Misdirected Request rather than a certificate error. That is a sign the certificate and the server configuration disagree about which names are served.

Is it the server or the visitor?

Unlike an expired-certificate error, a name mismatch is almost never caused by the visitor's device. There are two exceptions worth ruling out:

• Interception by security software or a network proxy. Some antivirus products, corporate proxies and public Wi-Fi portals intercept HTTPS and present their own certificate. If only users on one network see the error, open the certificate details in the browser and look at the issuer: a name like your company's firewall vendor rather than a public CA points to interception.
• A hosts-file entry or local DNS override that sends the name to an old server. Check /etc/hosts on macOS and Linux, or C:\Windows\System32\drivers\etc\hosts on Windows.

If the error appears from several networks, or in an external check such as the SSL certificate checker, the cause is on the server side.

How to fix it, step by step

1. Note the exact host name in the address bar, including any www or subdomain.
2. List the certificate's SANs with the openssl command above, using that host name for -servername.
3. If the name is missing, reissue the certificate with every host name you serve, or add a wildcard plus the apex.
4. If the certificate belongs to another site or provider, fix DNS or the server configuration so the request reaches the server that holds your certificate.
5. Reload the web server and check again from outside your network.
6. Check every name. If you serve example.com, www.example.com and api.example.com, test all three.

How to catch it early

Name mismatches usually appear right after a change: a new subdomain, a hosting or CDN migration, or a certificate reissue that left a name out. Three habits help:

• After any DNS or certificate change, test every public host name, not just the main one.
• Monitor each important host name separately, including www, the apex and API or app subdomains. A list of which URLs to monitor helps you cover them.
• Keep certificate renewals automated and watch their expiry too. See SSL certificate monitoring for the full list of things to check.

PingRobot monitors each URL you add every minute on Pro or every five minutes on Free, and every HTTPS monitor also reads the certificate daily and reminds you 7, 14 or 30 days before it expires, then every day in the last three.

Start monitoring free — 10 monitors, no credit card.