Fix NET::ERR_CERT_COMMON_NAME_INVALID

NET::ERR_CERT_COMMON_NAME_INVALID usually means the certificate presented by the server does not cover the hostname in the browser's address bar. Despite the error's name, modern browser identity checks depend on Subject Alternative Name (SAN) entries, not merely the common name.

Inspect the certificate actually served, compare its SAN entries with the requested name, and check whether DNS or SNI sent the client to the wrong endpoint.

Inspect the served certificate

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

This displays certificate fields; it is not a complete validation test. Common mismatches include:

When connecting by IP, the certificate needs the appropriate IP SAN; a DNS SAN is not equivalent to an IP address.

Repair the hostname coverage

Reissue the certificate with every required name. For example, an Apache installation with the Certbot Apache plugin can request both apex and www names:

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

Use the issuance method appropriate to your actual server. *.example.com covers www.example.com but not the apex example.com; list the apex separately when needed.

Check every redirect and endpoint

Each HTTPS connection in a redirect sequence must present a certificate valid for that connection's hostname. This includes the starting HTTPS hostname: the browser must complete TLS before it can read a redirect to the canonical name. A redirect cannot repair a bad certificate on the first hop.

Check DNS records after migrations:

dig example.com A
dig example.com AAAA

A stale IPv4 or IPv6 address can send some clients to an old server. Shared hosting or an incorrect SNI configuration can also return the default site's certificate. Clients without SNI may need a default certificate covering their requested names, or an explicitly documented compatibility policy.

For a CDN, inspect the edge certificate presented to the browser separately from the origin certificate and origin Host/SNI configuration. With several backend endpoints, confirm each one loaded the new certificate.

Guance HTTP tests can check the apex, www, and relevant subdomains independently with certificate verification enabled. Use separate SSL tests for remaining-lifetime conditions.

If you are visiting someone else's site

Check the spelling and use the site's known official address. Do not assume adding or removing www makes an unfamiliar URL trustworthy. An incorrect system clock can cause certificate-validity errors, but it does not fix a genuine hostname mismatch.

Do not bypass the warning to submit credentials or sensitive information. Report the requested hostname and error to the site's administrator.

Common questions

The file on the server contains the right name. Why does the browser disagree?

The service may be serving another file, a stale loaded certificate, or a different virtual host. Inspect the actual network response and every CDN/load-balancer entry point rather than relying on a local certificate file.

Is this the same as ERR_CERT_AUTHORITY_INVALID?

No. Name mismatch and issuer trust are different checks. A private service can have both problems: an untrusted internal CA and a certificate that omits the requested hostname.

How soon should a replacement take effect?

After the correct service reloads successfully, new handshakes normally receive the new certificate. CDN propagation, existing connections, and session resumption can affect what you observe. Test fresh handshakes against each entry point.

See OpenSSL s_client and Nginx HTTPS virtual-host configuration.