sfw/fix
SSL_ERROR_BAD_CERT_DOMAIN high

SSL_ERROR_BAD_CERT_DOMAIN (Firefox)

Firefox rejects the cert because the hostname you visited isn't listed in its Common Name or Subject Alternative Names.

What you see

Warning: Potential Security Risk Ahead

example.com uses an invalid security certificate. The certificate is only valid for www.example.com.

Error code: SSL_ERROR_BAD_CERT_DOMAIN

What’s actually happening

Firefox shows "Potential Security Risk Ahead" and the message usually names what the cert is valid for. The cert chain may be perfectly trusted and in-date — it just doesn't cover this exact name. Classic giveaway: https://www.example.com loads clean while the bare https://example.com fails, or vice versa, because only one of the two is in the SAN list.

Common causes

  • Serving the apex (example.com) on a cert issued only for www.example.com, or the reverse — both names need to be in the SAN
  • Hitting the server by IP (https://203.0.113.10) when the cert is issued for a hostname, not the IP
  • Shared hosting returns the server's default vhost certificate for an unconfigured domain, so you get someone else's cert
  • A wildcard cert (*.example.com) used on the naked apex — wildcards don't cover the bare domain, only one label below it
  • DNS or a CDN points the hostname at an origin whose cert was issued for a different name

How to fix it

  1. List the names the cert actually coversecho | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName. The DNS: entries under subjectAltName are the only hostnames this cert is valid for. If the name in your URL isn't there, that's the whole problem.
  2. Reissue the cert to include every hostname you serveAdd both apex and www to the SAN. Let's Encrypt: certbot --nginx -d example.com -d www.example.com. Most lapses are someone requesting only www and forgetting the apex (or vice versa). Reload the server after.
  3. Point clients at the hostname, not the IPIf you reached the box by raw IP, switch to the DNS name in the cert. Certs are bound to hostnames, not addresses — browsing to the IP will always mismatch unless the cert explicitly lists an IP SAN, which is rare.
  4. Check SNI / vhost on shared or multi-site originsGetting a default or wrong-domain cert means the server isn't matching SNI to the right vhost. Confirm with the -servername flag above; if the wrong cert comes back, fix the vhost-to-cert binding (nginx server_name, Apache ServerName/ServerAlias) so the requested host gets its own cert.

Stop it recurring

Issue one cert covering every hostname visitors use (apex + www + any subdomains in the SAN) and redirect to a single canonical host so you only depend on one name being valid.

Related errors