CertGuru

NET::ERR_CERT_COMMON_NAME_INVALID

"NET::ERR_CERT_COMMON_NAME_INVALID" means Chrome could not match the hostname in the address bar to any name in the certificate's Subject Alternative Name extension. Despite the name of the error, Chrome has ignored the Common Name field since Chrome 58, so a certificate whose CN is exactly right still fails this check if it carries no SAN extension listing that hostname. Nothing about trust, expiry or the certificate chain is wrong when this error appears — the certificate is valid, it was simply issued for different names. Run `openssl x509 -in certificate.crt -noout -ext subjectAltName` to list the names it does cover, and reissue the certificate with the missing hostname among them.

Updated August 19, 2026 Verified against OpenSSL 3.5.7

What the error actually means #

Certificate validation asks two independent questions: is this certificate trustworthy, and does it belong to the host I asked for. This error is a failure of the second question only. The signature is fine, the chain is fine, the dates are fine — the certificate simply does not carry the name you typed.

Step 1 — list the names the certificate covers #

Read the SAN extension
openssl x509 -in certificate.crt -noout -ext subjectAltName
Expected output 
X509v3 Subject Alternative Name:
  DNS:example.com, DNS:www.example.com

The hostname in the address bar must appear in that list literally, or be covered by a wildcard. If the command prints nothing at all, the certificate has no SAN extension and will fail against every modern browser regardless of its Common Name:

Subject and SAN side by side
openssl x509 -in certificate.crt -noout -subject -ext subjectAltName

For a certificate you have not been given as a file, read it off the live server:

Read the SAN list from a running server
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -ext subjectAltName

Step 2 — find which case you are in #

Symptom Cause Fix
SAN list is empty Certificate predates SAN, or the CSR omitted it Reissue with SANs
SAN has example.com, you browsed www.example.com Both names were not requested Reissue with both
SAN has *.example.com, you browsed example.com A wildcard does not cover the bare domain Reissue adding example.com
SAN has *.example.com, you browsed a.b.example.com A wildcard covers one label only Reissue adding *.b.example.com
You browsed an IP address SAN carries DNS names, not IP: entries Use the hostname
Subject is a hosting provider’s name The server is serving its default certificate SNI or vhost problem

Step 3 — reissue with every name the service answers on #

Names are covered by the CA’s signature, so they cannot be added afterwards. Generate a new CSR listing all of them:

A CSR carrying the apex and www
openssl req -new -newkey rsa:2048 -nodes \
-keyout site.key -out site.csr \
-subj "/CN=example.com" \
-addext "subjectAltName=DNS:example.com,DNS:www.example.com"

Confirm the extension survived into the CSR before sending it to the CA — this is the step that most often goes wrong silently:

openssl req -in site.csr -noout -text | grep -A1 "Subject Alternative Name"

The full walkthrough, including the config-file form for long name lists, is on generate a CSR with SANs.

When the server serves the wrong certificate #

If the certificate you are looking at belongs to someone else entirely — a hosting provider, a CDN, or another site on the same box — the certificate is not the problem. The server picked the wrong virtual host.

Compare what the server returns with and without SNI
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject
openssl s_client -connect example.com:443 </dev/null 2>/dev/null | openssl x509 -noout -subject

Two different subjects means the server has a default certificate that is answering for unrecognised names. Either the server_name directive does not list the hostname, or the request is reaching a different backend than you expect. The nginx side of this is covered in install an SSL certificate on nginx.

What not to do #

Frequently asked questions

The Common Name is correct, so why does Chrome say it is invalid?
Chrome stopped reading the Common Name in Chrome 58, following RFC 2818's deprecation of the practice. Name matching now uses the Subject Alternative Name extension exclusively. A certificate with a perfect CN and no SAN extension fails against every current browser, and the error name is simply a historical artefact.
Does a wildcard certificate cover sub-subdomains?
No. *.example.com matches api.example.com but not a.b.example.com, and it does not match the bare example.com either. A wildcard replaces exactly one label, which is why certificates usually list both *.example.com and example.com.
Can I add a hostname to a certificate that has already been issued?
No. The names are covered by the CA's signature, so changing them invalidates it. Generate a new CSR listing every name and have the certificate reissued — most CAs do this at no extra cost within the existing term.
Why does this only happen when I browse by IP address?
The SAN list must contain IP:10.0.0.5 for an IP address to match, and public CAs will not issue those. Use the hostname instead, and override DNS locally if that is the obstacle.
Chrome shows this but curl does not complain. Why?
Check which certificate each is receiving. If curl omits SNI or connects to a different address, the server may answer with a different virtual host. Compare openssl s_client -servername output against what the browser reports in the certificate viewer.

References

Related pages