# SSL_ERROR_BAD_CERT_DOMAIN: certificate not valid for this name

> Firefox shows SSL_ERROR_BAD_CERT_DOMAIN when the certificate does not list the hostname you visited. Fix the SAN list, SNI or CDN binding.

Source: https://ssl.sh/errors/ssl-error-bad-cert-domain/
Last updated: 2026-11-10

**SSL_ERROR_BAD_CERT_DOMAIN means the site's certificate was issued for a different hostname than the one you are visiting.** The certificate itself may be valid; it does not cover this name. This is almost always fixed on the server.

## Is it the site or your device?

Almost always the site; a captive portal or proxy is the rare local cause. Look at the certificate's names with the [SSL checker](https://ssl.sh/tools/ssl-checker/):

```bash
curl ssl.sh/example.com
```

If the hostname is missing from the SAN list, the site owner must fix it. If the checker shows the right certificate but Firefox does not, suspect your network: a public Wi-Fi login page, a DNS filter, a hosts-file entry, or a proxy that answers on behalf of other sites. Also check for typos and old bookmarks pointing to a retired hostname.

## Causes

### 1. www or bare domain missing

The certificate covers `example.com` but not `www.example.com`, or the reverse. Inspect the names:

```bash
echo | openssl s_client -connect example.com:443 -servername www.example.com 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName
```

### 2. Wildcard does not match

`*.example.com` covers one label only. It does not match `example.com` or `dev.api.example.com`.

### 3. Shared hosting or SNI falls back to the default site

When no server block matches the requested name, the server presents its default certificate, which belongs to another site. This often happens after adding a domain to DNS before configuring the web server.

### 4. CDN or load balancer without a certificate for the name

Edge servers return a generic certificate when none is bound to the hostname. Attach a certificate covering each accelerated name.

### 5. Visiting by IP address or internal name

Typing `https://203.0.113.10` or a short intranet name rarely matches a certificate. Use the full hostname the certificate was issued for.

## What it looks like in each browser

| Browser | What you see |
|---|---|
| Firefox | "Warning: Potential Security Risk Ahead" and "uses a certificate that is not valid for example.com" |
| Chrome / Edge | [NET::ERR_CERT_COMMON_NAME_INVALID](https://ssl.sh/errors/net-err-cert-common-name-invalid/) |
| Safari | "This Connection Is Not Private" |
| curl | `no alternative certificate subject name matches target host name` |

## How site owners fix it

A certificate that lists every hostname, mapped to the right server block, fixes it.

**1. Include every hostname in one certificate.** Request all names your visitors use:

```bash
sudo certbot certonly --nginx -d example.com -d www.example.com
```

If you need a CSR for a commercial CA, the [CSR generator](https://ssl.sh/tools/csr-generator/) adds the SAN entries for you.

**2. Map each name to the right server block.**

```nginx
server {
    listen 443 ssl;
    server_name example.com www.example.com;
    ssl_certificate     /etc/nginx/ssl/example.com.fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;
}
```

**3. Check every endpoint** after the change with `curl ssl.sh/example.com` and `curl ssl.sh/www.example.com`, then add a 301 redirect to your preferred hostname.