ERR_CERT_COMMON_NAME_INVALID: The certificate does not match the hostname
The certificate is valid and trusted, but it was issued for a different hostname than the one in the address bar. The classic case is a certificate covering example.com being served for www.example.com.
Short answer
The certificate is valid and trusted, but it was issued for a different hostname than the one in the address bar. The classic case is a certificate covering example.com being served for www.example.com.
What ERR_CERT_COMMON_NAME_INVALID means
Browsers check the requested hostname against the certificate's Subject Alternative Name list. If there is no exact match — and wildcards only cover one label — the connection is rejected regardless of how healthy the certificate otherwise is.
Causes and fixes, most likely first
The certificate covers the apex domain but not the www hostname, or the reverse. Reissue covering both names, or redirect the uncovered hostname at the DNS/HTTP layer before TLS is negotiated — which is not possible over HTTPS, so the certificate must cover it.
A wildcard certificate is being used one level too deep (*.example.com does not cover a.b.example.com). Issue a certificate for the specific deeper hostname, or a second wildcard for *.b.example.com.
The server has multiple vhosts and the default one answers because SNI is not configured. Configure the correct server_name / ServerName for the hostname so SNI selects the right certificate instead of falling through to the default vhost.
ERR_CERT_COMMON_NAME_INVALID on specific platforms
ERR_CERT_COMMON_NAME_INVALID on Cloudflare — Cloudflare's universal certificate covers example.com and *.example.com only — a second-level subdomain such as api.staging.example.com is…
ERR_CERT_COMMON_NAME_INVALID on AWS S3 — An S3 static site served over the bucket's default HTTPS endpoint presents a certificate for *.s3.amazonaws.com, which never matches a…
ERR_CERT_COMMON_NAME_INVALID on Chrome — Chrome ignores the legacy commonName field entirely and validates only Subject Alternative Names, so certificates that still work in older…
How to stop it happening again
Cover both apex and www on every certificate as a default.
Monitor each hostname separately — a certificate valid for one is not evidence for the other.
Check your own domain
The SSL check reports which names the served certificate actually covers, which is the whole answer to this error in one line.
Frequently asked questions
Does a wildcard certificate cover sub-subdomains?
No. *.example.com covers api.example.com but not api.eu.example.com. Wildcards match exactly one label.
Why does example.com work but www.example.com fail?
They are separate hostnames and need separate coverage on the certificate. Reissue with both names in the SAN list.