ERR_SSL_UNRECOGNIZED_NAME_ALERT: Server Does Not Know This Hostname

ERR_SSL_UNRECOGNIZED_NAME_ALERT is Chromium net error -159: “The SSL server sent us a fatal unrecognized_name alert.” In its first handshake message the browser names the site it wants through the SNI extension (Server Name Indication). The server looked that name up, found no virtual host for it, and ended the handshake with TLS alert 112 (unrecognized_name) at fatal level.

So the failure is at the TLS layer, but its cause is usually routing: the right name reached the wrong server, or the right server was not told about the name. It is not a certificate-name mismatch: in that case the server sends a certificate for another name and Chrome shows ERR_CERT_COMMON_NAME_INVALID. RFC 6066 lets a server either abort with a fatal unrecognized_name alert or continue the handshake, and calls a warning-level alert “NOT RECOMMENDED”; Chrome only raises this error for the fatal form.

• DNS points at the wrong machine. After a migration, the A or AAAA record still targets the old server, a shared IP of another tenant, or a default page. An outdated AAAA record is easy to miss: only visitors with IPv6 fail.
• The hostname is missing from the configuration. www.example.com works but example.com does not, or a new subdomain was added to DNS but not to the web server.
• A server set to refuse unknown names. nginx 1.19.4 and later support ssl_reject_handshake on; in the default server; any name not matched by another server_name gets exactly this alert.
• Visiting by IP address. Browsers do not send SNI for IP literals, so https://203.0.113.10/ lands in the default server, which may reject it.

A reverse proxy has the same problem in the other direction. nginx does not send SNI to an HTTPS upstream unless told to, so an upstream with ssl_reject_handshake refuses it. The browser then gets a 502 and nginx's error log shows tlsv1 unrecognized name:SSL alert number 112 while SSL handshaking to upstream.

# reject names this server does not host
server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    ssl_reject_handshake on;
}

# the real site: list every name you publish in DNS
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com www.example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        proxy_pass https://backend.internal;
        proxy_ssl_server_name on;   # send SNI upstream (off by default)
        proxy_ssl_name $host;
    }
}

With Cloudflare proxying the record, the browser negotiates with Cloudflare's edge, so it does not see this alert from your origin; an origin refusing the name appears as a Cloudflare 525 page instead. A hostname with no edge certificate on Cloudflare shows ERR_SSL_VERSION_OR_CIPHER_MISMATCH, not this error. HAProxy's strict-sni likewise refuses handshakes for names without a matching certificate, so check its certificate list covers every name.

1. Check where DNS points: dig +short example.com A and dig +short example.com AAAA, for the apex and www. Every address must be a server that hosts the site.
2. Test each address with the right name:

   openssl s_client -connect 203.0.113.10:443 -servername example.com -brief </dev/null
   curl -sv --resolve example.com:443:203.0.113.10 https://example.com/ -o /dev/null
   # "tlsv1 unrecognized name" -> this server has no vhost for example.com

3. Reproduce the no-SNI path (IP access, very old clients): openssl s_client -connect example.com:443 -noservername. OpenSSL 1.1.1 and later send SNI automatically when -connect names a host, so this flag is needed to test without it.
4. Add the name to server_name (nginx) or ServerName/ServerAlias in the <VirtualHost *:443> (Apache), make sure the certificate covers it, then nginx -t && systemctl reload nginx.
5. Fix or remove stale records, especially AAAA records left from a previous host.

• Use the domain name, not an IP address, and check for typos in the subdomain.
• Try mobile data or another network: if the site works there, your network's DNS may still hold an old address. Restarting the router or flushing the OS DNS cache can help after a recent migration.
• If you use Chrome's Secure DNS (Settings > Privacy and security > Security > Use secure DNS), compare with it on and off: a different resolver can return a different, outdated address.
• Check the hosts file for a stale entry for the domain.

Clearing the browser cache does not help. If the error appears from every network, the server or DNS is misconfigured and only the owner can fix it.

for ip in $(dig +short example.com A) $(dig +short example.com AAAA); do
  echo "== $ip"
  curl -s -o /dev/null -w '%{http_code}\n' --resolve "example.com:443:$ip" https://example.com/
done
# every address should return a normal status code

Check the records themselves with the DNS lookup tool, and the handshake and certificate for each name with the SSL/TLS checker.

• ERR_SSL_VERSION_OR_CIPHER_MISMATCH — often what a missing certificate looks like
• ERR_CERT_COMMON_NAME_INVALID — a certificate for the wrong name was sent
• ERR_SSL_UNRECOGNIZED_NAME — related SNI failure
• SNI — how one IP serves many HTTPS sites