ERR_CERT_COMMON_NAME_INVALID: The Browser Error Explained

You open the site and Chrome blocks it with ERR_CERT_COMMON_NAME_INVALID. The connection is encrypted, but the browser does not believe the certificate belongs to this domain. Here is the precise cause, why the old Common Name field gives the error its name, and how to fix it.

Short answer

ERR_CERT_COMMON_NAME_INVALID is Chrome's error code for a hostname mismatch: the domain in the address bar is not in the certificate's Subject Alternative Name (SAN). The "common name" in the name is historical — Chrome stopped using the CN field in 2017 and now requires the name to be in SAN. The fix is to issue a certificate that lists the right domain in SAN.

Confirm the cause

See which names the certificate actually covers:

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

If the domain from the address bar is not on the list, that is the explanation. Note: if a certificate has no SAN field at all (only an old CN), Chrome shows this error too — even if the CN matches.

The most common triggers

www vs apex — the certificate covers one but not the other.
A new subdomain went live without being added to the certificate.
Wrong virtual host — multiple domains on one IP and missing SNI, so the default certificate is returned.
Old certificate without SAN — typically self-signed certificates made with an outdated OpenSSL command.

How to fix it

Issue a new certificate with all required names in SAN (e.g. both example.com and www.example.com). With ACME you simply add the names to the certificate's domain list.
Install it with the full chain and reload the service.
If you generate a self-signed certificate for testing, set SAN explicitly (old one-liners do not):

openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem \
  -days 365 -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

The small self-signed trap

Many developers know this error from local dev environments. The ancient command openssl req -x509 -subj "/CN=localhost" without -addext subjectAltName produces a certificate that modern browsers reject with exactly this error. Always add a SAN — even for localhost and 127.0.0.1.

Catch missing names before your users do

The error often hits right after a new subdomain goes live. CertControl discovers new subdomains via Certificate Transparency and DNS and flags endpoints where the certificate's SAN does not cover the name served — so you catch the mismatch at the next scan instead of through a support ticket. It is one of several TLS handshake failures worth knowing — and for which names a certificate should carry, see single-domain vs wildcard vs SAN.

Frequently asked questions

Why is the error called "common name" when it is about SAN?

For historical reasons. The domain used to live in the Common Name field. Chrome stopped using CN in 2017, but the error code's name stuck. In practice it means: the name is missing from SAN.

Can I click through past the error?

Often you can in Chrome under "Advanced", but it is a warning that you cannot trust the server's identity. Fix the certificate instead of teaching users to ignore warnings.

Why do I get the error on a brand-new Let's Encrypt certificate?

Probably because you are connecting to a name that was not included when the certificate was issued — e.g. the apex while only www was included. Reissue with both names in SAN.

Does the error only apply to Chrome?

The error code is Chrome's, but all modern browsers reject certificates where the name is not in SAN. Firefox and Safari simply show different wording.

See the platform Book a demo

ERR_CERT_COMMON_NAME_INVALID explained