SSL_ERROR_BAD_CERT_DOMAIN in Firefox: How to Fix a Certificate Name Mismatch

During certificate validation Firefox compares the hostname you opened with the DNS names (or IP addresses, for an IP URL) in the certificate's subjectAltName extension. If none matches, it stops with SSL_ERROR_BAD_CERT_DOMAIN and explains: "Firefox does not trust this site because it uses a certificate that is not valid for" the hostname, often followed by the names the certificate is valid for. A wildcard such as *.example.com covers exactly one label: www.example.com matches, example.com and a.b.example.com do not.

This is an identity check at the TLS layer, not a DNS failure, although DNS often causes it by sending you to a server that holds another site's certificate. When a certificate is both expired and issued for the wrong name, Firefox reports the name problem first. The Chrome and Edge counterpart is NET::ERR_CERT_COMMON_NAME_INVALID.

Typical triggers: the certificate covers www.example.com but not example.com (or the reverse); a wildcard expected to cover the apex or a second-level subdomain; a new subdomain added without reissuing; a hostname with no TLS server block of its own, so the server falls back to its default certificate; an old A or AAAA record still pointing to a previous host or shared hosting; opening the site by IP address or by an internal short name.

Certificates that carry the name only in the Common Name field no longer work: Chrome stopped reading the Common Name in version 58, and Apple did the same in iOS 13 and macOS 10.15. The name must be in the SAN list. On captive Wi-Fi, the login portal can answer for every hostname with its own certificate, which also looks like a name mismatch.

• Cloudflare. Universal SSL covers the apex and first-level subdomains of a proxied zone. A multi-level name such as test.dev.example.com gets no edge certificate at all, so Firefox shows SSL_ERROR_NO_CYPHER_OVERLAP rather than BAD_CERT_DOMAIN; it needs an advanced or custom certificate. BAD_CERT_DOMAIN on a Cloudflare zone usually means the record is DNS only and the origin's own certificate lacks the name.
• nginx. When the SNI name matches no server_name, nginx answers with the default_server block and its certificate. Since nginx 1.19.4 you can refuse unknown names instead of sending the wrong certificate:

server {
    listen 443 ssl default_server;
    ssl_reject_handshake on;   # unknown names get an alert, not a wrong certificate
}
server {
    listen 443 ssl;
    server_name example.com www.example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

Visitors to an unknown name then see an unrecognized-name alert, which points straight at the missing server block. HAProxy and cloud load balancers behave like nginx: no SNI match means the default certificate.

1. List the names on the certificate the server actually sends:

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

2. Let OpenSSL check the name for you: add -verify_hostname www.example.com to s_client. A mismatch prints Verify return code: 62 (hostname mismatch).
3. Check where each name resolves: dig +short example.com A, dig +short www.example.com A and the same with AAAA. An IPv6 address pointing at an old host is a frequent culprit.
4. Reissue with every name you serve: sudo certbot --nginx -d example.com -d www.example.com (add --expand to grow an existing certificate). A Let's Encrypt wildcard needs DNS-01 validation and still does not cover the apex, so list both.
5. Make sure the right server block owns each name, then sudo nginx -t && sudo systemctl reload nginx.

• Check the address for a typo, a missing or extra www, or an old bookmark to a retired subdomain. If Firefox names the one hostname the certificate is valid for, it links to it; use that link if it is the site you meant.
• On public Wi-Fi, complete the login page first, then reload.
• If the error appears on every network for one site, only the owner can fix it.
• "Accept the Risk and Continue" is offered unless the site uses HSTS. Skip it on any page where you log in or pay.

Clearing the cache or cookies does not change the result: the certificate is checked on each new connection, and it is not stored in the HTTP cache.

for h in example.com www.example.com; do
  echo | openssl s_client -connect $h:443 -servername $h -verify_hostname $h 2>/dev/null \
    | grep "Verify return code"
done
# → Verify return code: 0 (ok) for each name

curl -sS -o /dev/null https://www.example.com/ && echo OK
# mismatch: curl: (60) SSL: no alternative certificate subject name matches target hostname

Then check each hostname from outside your network with the enterno.io SSL checker, which lists the SAN names on the served certificate.

• NET::ERR_CERT_COMMON_NAME_INVALID (Chrome counterpart)
• SEC_ERROR_UNKNOWN_ISSUER
• MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT
• SSL certificate name mismatch
• Wildcard vs SAN certificates