NET::ERR_CERT_COMMON_NAME_INVALID

What’s actually happening

The page is replaced by a full red/grey interstitial before any content loads. Clicking "Advanced" shows the certificate was issued for a different name than the one in the address bar. It happens on every visit, not intermittently, and an incognito window behaves identically. Other devices on the same network hit the same wall, which rules out a local cache problem.

Common causes

• Certificate covers the apex (example.com) but you're loading www.example.com, or vice versa — the missing variant isn't in the SAN.
• The cert has no Subject Alternative Name extension at all. Chrome 58+ ignores the legacy Common Name field entirely, so a CN-only cert always fails.
• A wildcard like *.example.com is served on a deeper label such as api.eu.example.com — wildcards match exactly one level.
• A self-signed or appliance default cert (router, NAS, load balancer admin UI) issued for an internal name is being served on a public hostname.
• The cert was issued before a new domain alias or vanity hostname was added, so that name was never included.

How to fix it

1. Confirm the mismatchRun openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 'Subject Alternative Name'. Compare the listed DNS names against the host in the address bar.
2. Reissue the certificate with every hostname in the SANWhen requesting the cert, list both apex and www (and any subdomains you actually serve) as SAN entries. With certbot: certbot --nginx -d example.com -d www.example.com. With a CA, add each name to the order's SAN field before issuance.
3. Fix the server so the right cert is sent for this hostnameOn multi-site servers the wrong vhost can answer. Check that the Nginx server_name / Apache ServerName (or the SNI mapping on your load balancer or CDN) routes this hostname to the block that holds the correct cert.
4. Redirect instead of dual-certing, if you only meant to serve one nameIf www should always go to apex (or the reverse), 301-redirect the unused variant — but the redirect endpoint still needs a cert valid for the name being requested, so the SAN fix comes first.
5. For internal-only appliances, import the cert as trusted or use its real nameDon't ship a self-signed default cert to production. Either install a proper cert for the public hostname or access the box by the exact name the cert was issued for.