Error guide / ERR_SSL_UNRECOGNIZED_NAME_ALERT
ERR_SSL_UNRECOGNIZED_NAME_ALERT
ERR_SSL_UNRECOGNIZED_NAME_ALERT is Chrome's message for a server that stopped the secure connection because it did not recognise the site name it was asked for. At the very start of HTTPS, before any certificate is sent, the browser tells the server which hostname it wants (this is called SNI). The server looked through the sites it hosts, found none with that name and answered with a fatal unrecognized_name alert. Firefox reports the same thing as SSL_ERROR_UNRECOGNIZED_NAME_ALERT. The handshake ends before a certificate is even exchanged, so an expired or wrong certificate is not the cause, and clearing the browser cache does not help.
Check your site
What causes it
The name you typed reaches a server that has no configuration for it. Most often DNS points to the wrong server: a new hosting account where the domain was never added, an old server after a move, or a shared IP from which the site was removed. Next comes a missing alias: the site is set up for example.com but not for www.example.com or a subdomain, so only one form fails. On Apache that means the name is in neither ServerName nor ServerAlias of an HTTPS virtual host, on nginx it is not in server_name and the default server rejects unknown names (ssl_reject_handshake on), and on IIS the HTTPS binding requires SNI for a different hostname. A CDN, load balancer or reverse proxy in front of the site does the same when the hostname was never added to it. If the error appears on one computer only, the cause is local: a hosts file entry, a stale DNS cache, a VPN or an antivirus that intercepts HTTPS.
How to fix it
- Run the check on this page for the exact name that fails, with www or the subdomain if that is what you open. Our server sends that name in SNI, just like Chrome. If the check cannot complete a TLS connection for this name but works for the other form, www or the bare domain, the server simply does not know this name. If the check succeeds and shows a valid certificate, the server works for everyone else and the problem is on the computer or network where you see the error.
- Check where the name points. The DNS check on this site shows the A and AAAA records for the failing name; compare the IP with the one your hosting panel or server lists. A different IP means DNS sends visitors to a server that has never heard of the site: fix the record or add the domain on that server. Look at AAAA too: if an IPv6 address points to an old server, only visitors on IPv6 get the error.
- Add the name on the server. On Apache, put it in ServerName or ServerAlias of the virtual host on port 443 and reload. On nginx, add it to server_name in the server block that listens on 443 with ssl. In cPanel and similar panels, add it as an alias, addon domain or subdomain of the site, whichever it is. On IIS, add an HTTPS binding for this hostname. Then issue a certificate that covers the new name, otherwise the error turns into a certificate warning.
- If a CDN or proxy sits in front, add the hostname there as well. In Cloudflare it has to be a proxied DNS record in the zone; on other CDNs and load balancers it must be listed in the site or listener configuration together with its certificate. The check on this page sees what the CDN answers, so rerun it after the change.
- From a terminal you can confirm the server's behaviour directly: openssl s_client -connect SERVER-IP:443 -servername failing-name.com. "alert number 112" or "unrecognized name" in the output is this refusal; a certificate chain means the server accepts the name.
- If only your computer shows the error, look for the domain in the hosts file, flush the DNS cache (ipconfig /flushdns on Windows), switch off the VPN and HTTPS scanning in your antivirus, and try another network. If the error disappears, the site was never the problem.