This error means the certificate presented doesn't include the exact hostname in its SAN field — most commonly a www vs non-www mismatch, or a certificate issued for one domain being served on a different one.
The fix
Check the certificate's SAN list (via the browser's certificate details, or an SSL checker tool) against the exact hostname in the address bar. If they don't match, either reissue the certificate to include the correct hostname, or fix your server's configuration to serve the correct certificate for that hostname.
Why this error specifically points to the SAN field, not the certificate's validity
This error means the certificate is otherwise valid and trusted, but doesn't list the exact hostname you're visiting in its Subject Alternative Name field — a different, unrelated problem from an expired or untrusted certificate, and one that requires reissuing the certificate with the correct hostname included rather than any other fix.
How this commonly happens after a domain or subdomain change
Adding a new subdomain, or changing which domain a service is accessed through, without reissuing the certificate to cover the new hostname is the most common cause — the old certificate remains perfectly valid for its original hostname, just not for the new one you're now trying to reach.
What to check in the certificate's SAN field to confirm this exact diagnosis
Viewing the certificate's details and specifically checking the Subject Alternative Name list against the exact URL in your address bar confirms whether the hostname genuinely isn't covered — a subtle difference like www versus non-www, or an extra subdomain, is enough to trigger this error even though the domains look similar at a glance.
How to fix this permanently as the site owner rather than just diagnosing it
The permanent fix is reissuing the certificate with a SAN list that includes every hostname visitors actually use to reach your site — if you support both www and non-www versions, or multiple subdomains, each one needs to be explicitly listed rather than assumed to be covered.
Why this error sometimes appears intermittently rather than consistently
If your infrastructure has multiple servers or a CDN with inconsistent certificate deployment, some requests might hit a correctly configured endpoint while others hit one still serving an outdated or mismatched certificate, producing an intermittent rather than constant version of this error.
A final note for visitors versus site owners
As a visitor encountering this error on a site you don't control, there's no client-side fix available — the certificate genuinely doesn't cover the hostname you're visiting, and the only real remedy is the site owner reissuing with the correct coverage. Proceeding despite the warning is generally not recommended unless you have specific, independent confidence in the site's legitimacy.
How this error relates to the SAN field versus the older Common Name field
Modern browsers ignore the certificate's Common Name field entirely for hostname matching purposes, relying exclusively on the Subject Alternative Name list — despite the error's historical naming convention still referencing 'common name,' the actual check happening today is entirely against the SAN field.
What tools can quickly show you every hostname a specific certificate actually covers
Beyond manually checking in a browser, running an SSL scan tool or a direct OpenSSL command against the domain shows the complete SAN list clearly, letting you quickly confirm exactly which hostnames are and aren't covered without needing to guess based on the error alone.
A quick closing checklist
A quick closing checklist covers checking the actual SAN list directly, confirming which exact hostname the error affects, and, if you're the site owner, reissuing with every hostname visitors actually use explicitly listed rather than assumed.
Why testing with both www and non-www versions catches a common specific case
If your certificate covers only one variant, www.yourdomain.com but not the bare yourdomain.com or vice versa, visitors reaching the uncovered variant hit this exact error — explicitly testing both versions, not just the one you normally use yourself, catches this specific, easily-missed gap.