What is SNI and why does it matter here?

Server Name Indication is the hostname the browser sends at the start of the TLS handshake so one IP address can host many HTTPS sites. If the server does not recognise that name, it can abort with unrecognized_name, which is exactly this error.

The site works with www but not without it. Why?

Only one of the names is configured on the server or CDN. Add the missing hostname to the virtual host (and to the certificate), or redirect it from a configured server block.

Can my hosts file cause this?

Yes. An old hosts entry or a DNS filter can send you to a server that no longer hosts the site. Remove the override and flush your DNS cache, then retry.

ERR_SSL_UNRECOGNIZED_NAME_ALERT: server rejects the hostname

ERR_SSL_UNRECOGNIZED_NAME_ALERT means the server received the hostname you asked for (through 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:

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:

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; one that answers with plain HTTP produces 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.

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