# ERR_SSL_UNRECOGNIZED_NAME_ALERT: server rejects the hostname

> ERR_SSL_UNRECOGNIZED_NAME_ALERT means the server rejected the hostname sent via SNI. Fix DNS, the virtual host, CDN binding or ssl_reject_handshake.

Source: https://ssl.sh/errors/err-ssl-unrecognized-name-alert/
Last updated: 2026-11-10

**ERR_SSL_UNRECOGNIZED_NAME_ALERT means the server received the hostname you asked for (through [SNI](https://ssl.sh/glossary/sni/)) and replied that it does not serve that name.** The connection is refused before any certificate is shown. It points to a mismatch between DNS and the server's configuration.

## Is it the site or your device?

Almost always the site. Check from outside with the [SSL checker](https://ssl.sh/tools/ssl-checker/):

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

If the checker gets the same alert, the server or CDN is missing the hostname. On the visitor side, rule out a typo, an outdated entry in your hosts file (`/etc/hosts` or `C:\Windows\System32\drivers\etc\hosts`), and DNS filtering software that redirects the domain.

## Causes

### 1. DNS points to a server that does not host the site

After a migration, the A record still points at the old server, which no longer has a virtual host for the name. Compare:

```bash
dig +short example.com
curl -sv --resolve example.com:443:203.0.113.10 https://example.com/ -o /dev/null 2>&1 | grep -i alert
```

### 2. Nginx default server with ssl_reject_handshake

Since Nginx 1.19.4, `ssl_reject_handshake on;` in a catch-all server makes Nginx refuse unknown SNI names with this alert. That is intended; the fix is to add a `server` block with the right `server_name` for the hostname.

### 3. Missing virtual host or binding

Apache without a `<VirtualHost *:443>` for the name, IIS with "Require Server Name Indication" enabled but no HTTPS binding for that host name, or HAProxy with `strict-sni` and no certificate for the name.

### 4. CDN or load balancer does not know the domain

The DNS CNAME points at the CDN, but the domain was never added to the CDN account, or it was removed. The edge rejects the unknown SNI name.

### 5. Client sends a different name than expected

This is rare in browsers, but a misconfigured proxy may rewrite or drop SNI. Test from another network.

## What it looks like in each browser

| Browser | What you see |
|---|---|
| Chrome / Edge | "This site can't provide a secure connection" with `ERR_SSL_UNRECOGNIZED_NAME_ALERT` |
| Firefox | "Secure Connection Failed", often with `SSL_ERROR_UNRECOGNIZED_NAME_ALERT` |
| curl | `tlsv1 unrecognized name` |
| Java clients | `javax.net.ssl.SSLHandshakeException: Received fatal alert: unrecognized_name` |

## How site owners fix it

DNS, the virtual host and the CDN must agree on the hostname. A server that answers with the wrong certificate instead of this alert produces [NET::ERR_CERT_COMMON_NAME_INVALID](https://ssl.sh/errors/net-err-cert-common-name-invalid/); one that answers with plain HTTP produces [ERR_SSL_PROTOCOL_ERROR](https://ssl.sh/errors/err-ssl-protocol-error/).

**1. Confirm DNS points to the right place.** The A/AAAA or CNAME record must target the server or CDN that hosts the site.

**2. Add a matching 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;
}

server {
    listen 443 ssl default_server;
    ssl_reject_handshake on;
}
```

The second block keeps rejecting unknown names, which is good practice; make sure every real hostname is covered by the first.

**3. Add the domain to the CDN or load balancer** and attach a certificate for it.

**4. Re-test** with `curl ssl.sh/example.com` and for each alias (for example `curl ssl.sh/www.example.com`).