How to Fix NET::ERR_CERT_COMMON_NAME_INVALID

What NET::ERR_CERT_COMMON_NAME_INVALID actually means

When Chrome, Edge, or another Chromium browser shows NET::ERR_CERT_COMMON_NAME_INVALID, it is telling you one specific thing: the certificate the server presented is otherwise fine, but the hostname you typed is not listed on it. The traffic was encrypted correctly, this is not a trust-chain or expiry problem, the name simply does not match.

The confusing part is the phrase 'common name'. For years a certificate's identity lived in its Common Name (CN) field. Since Chrome 58, back in 2017, browsers ignore the CN entirely and read only the Subject Alternative Name (SAN) extension. So err_cert_common_name_invalid almost never means the CN is wrong, it means the SAN list does not contain the exact hostname sitting in your address bar.

The usual causes

Nearly every case comes down to a name that should be on the certificate but isn't:

• www vs apex: the certificate covers www.example.com but you loaded example.com, or the reverse. Each is a distinct SAN entry and neither is implied by the other.
• A wildcard that doesn't reach far enough: *.example.com matches app.example.com but not example.com itself, and not a.b.example.com two levels deep.
• The wrong certificate on the virtual host: shared hosting or a misconfigured reverse proxy is serving another site's certificate, or a default self-signed one.
• Reaching the server by IP address or an internal hostname that was never added to the SAN.
• A recently added subdomain pointed at a server whose certificate was issued before that subdomain existed.

Diagnose it: read the certificate's SAN

The fastest way to confirm the cause is to look at exactly which names the served certificate covers. From any machine with OpenSSL:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text | grep -A1 'Subject Alternative Name'

The -servername flag matters: it sends SNI, so a server hosting many sites returns the right certificate instead of a default. Compare the DNS: entries in the output against the hostname in your browser. If your hostname isn't there, that's the entire bug. If you'd rather skip the terminal, paste the domain into VigilDog's SSL checker and read the SAN list it returns.

How to fix it

You cannot patch this from the browser side, the fix is to make the certificate cover the name, then serve it. In order:

• Reissue the certificate with every hostname in the SAN. For a typical site that means both example.com and www.example.com, plus each subdomain you actually serve.
• If you use a wildcard, remember it covers exactly one label. Include the apex explicitly (example.com) alongside *.example.com.
• Install the reissued certificate on the correct virtual host and reload the web server. Confirm the proxy or load balancer in front isn't still terminating TLS with an older certificate.
• For Let's Encrypt, add the missing name to the certificate: certbot --expand -d example.com -d www.example.com, then reload.
• If the browser still complains after a correct install, it may be a cached certificate, hard-refresh or test in a private window.

Verify and keep it from recurring

After reissuing, re-run the OpenSSL command (or the checker) and confirm the exact hostname now appears under Subject Alternative Name. Load the site in a fresh browser profile to be sure no cache is masking the real result.

Mismatched SANs tend to reappear the moment someone launches a new subdomain and forgets it isn't on the certificate. That gap is invisible until a visitor hits the error. Continuous SSL and domain monitoring catches a missing SAN, and an approaching expiry, before your users do, which is the difference between a quiet alert and a support ticket. See also what to do when an SSL certificate has expired for the related trust errors.