Chrome opens the site but Firefox says SSL_ERROR_BAD_CERT_DOMAIN. Why?

They're reporting the same defect with different strings — Chrome calls it NET::ERR_CERT_COMMON_NAME_INVALID. Both browsers check the Subject Alternative Name list, not the legacy Common Name. If one browser connects, it's usually reaching a cached certificate or a different SNI virtual host, not a genuine disagreement about the rules.

I have a wildcard certificate — doesn't it cover everything?

No. `*.example.com` covers exactly one label to the left: `www.example.com` yes, the apex `example.com` no, and `a.b.example.com` no. The apex and each nested name need their own SAN entry.

Views: 20

SSL_ERROR_BAD_CERT_DOMAIN in Firefox: Fix It

Q: The certificate's Common Name is exactly my domain. Why is it still a mismatch?

Because modern browsers stopped trusting the Common Name. Firefox and Chrome validate only the SAN list; Chrome dropped the Common Name fallback in Chrome 58 (2017) and the CA/Browser Forum has required a SAN since 2012. A CN that matches but a SAN that doesn't still fails.

SSL_ERROR_BAD_CERT_DOMAIN means the cert doesn't cover this hostname. Check the SAN list, www vs apex, and wildcard scope. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Firefox blocks the page with SSL_ERROR_BAD_CERT_DOMAIN.

Symptoms

Firefox shows a “Warning: Potential Security Risk Ahead” page citing SSL_ERROR_BAD_CERT_DOMAIN.
Chrome shows NET::ERR_CERT_COMMON_NAME_INVALID on the same server.
Only some hostnames fail — often www or a specific subdomain — while another name on the same site loads fine.

What This Error Actually Means

The certificate is real, trusted, and unexpired. It just wasn’t issued for the name you typed. Firefox loads the cert, compares the hostname in the address bar against the names the cert vouches for, finds no match, and stops. This is a name check, not a trust check — which is exactly what separates it from SEC_ERROR_UNKNOWN_ISSUER (a chain the browser doesn’t trust) or an expired-certificate error (the dates are wrong). Here the chain and the dates are fine; only the name is off.

The names that count live in the certificate’s Subject Alternative Name (SAN) list. Firefox reads nothing else. The old Subject Common Name field — the one that looks like it holds the domain — is ignored. This isn’t a Firefox quirk: Chrome dropped the Common Name fallback in Chrome 58 (2017), and the CA/Browser Forum Baseline Requirements have required a SAN since 2012. So a certificate whose Common Name reads example.com but whose SAN list omits the exact hostname you’re visiting fails in every current browser. It just fails with a different sentence in each one.

Top 3 Causes

The hostname isn’t in the SAN list - The classic case is a certificate covering example.com but not www.example.com (or vice versa). Each name is a separate SAN entry; issuing for one does not silently include the other.
Wildcard coverage was misunderstood - *.example.com covers a single label level. It does not cover the apex example.com, and it does not cover a.b.example.com. Assuming a wildcard is a blanket is the second most common way to land here.
The request reaches the wrong certificate - DNS, a proxy, a CDN edge, or a default virtual host terminates the connection and presents a different tenant’s certificate. The name you asked for never gets its own cert because you’re not hitting the server you think you are. Browsing by raw IP triggers the same thing.

Diagnose with DechoNet

SSL Check to read the certificate’s SAN list and confirm whether the exact hostname — apex, www, or subdomain — is actually listed.
DNS Lookup to confirm the name resolves to the server you intend, not a different origin, CDN, or parked host serving the wrong certificate.
HTTP Check to see where the request actually terminates when a proxy or redirect is in play.

Resolution Checklist

Run SSL Check and read the SAN list — confirm the failing hostname is present, character for character.
If it’s missing, reissue the certificate with every hostname you serve (apex and www, plus any subdomains) in the SAN list.
If you rely on a wildcard, verify the failing name is one label below the wildcard — not the apex, not a deeper subdomain.
Confirm DNS points at the right origin and that no proxy or CDN edge is presenting a different certificate.
Re-run SSL Check and confirm the hostname now matches a SAN entry.

When to Escalate

If the certificate is issued and correct but a CDN or load balancer keeps serving the wrong one, escalate to whoever owns that edge — the mismatch is a routing problem, not a certificate problem.
If you can’t reissue with the missing name (managed platform, third-party host), take the SAN list and the failing hostname to the platform owner; the fix is theirs to make.