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
- 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.
- 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.
- 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.
- 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