NET::ERR_SSL_UNRECOGNIZED_NAME_ALERT

What’s actually happening

The page dies before any HTML loads, usually on one specific hostname while a sibling subdomain on the same box works fine. During the handshake the server sends a TLS alert (level warning, description 112, unrecognized_name) saying it has no SSL config for the name the client put in the SNI extension. Older Chrome builds tolerated this alert; current ones treat it as fatal and bail. curl often still connects, which throws people off.

Common causes

• No SSL virtual host on the server matches the SNI hostname, so it falls through to a default that rejects the name
• The vhost's ServerName/server_name doesn't include the exact host being requested (e.g. www vs apex, or a new subdomain never added)
• Apache with no default SSL vhost: the first matching :443 block answers and emits the warning when the name doesn't line up
• A certificate installed for one domain while the request comes in for a different, uncovered domain on a shared IP
• Load balancer or CDN origin routing the request to a backend that has no TLS config for that host

How to fix it

1. Confirm it's actually the SNI alertRun openssl s_client -connect example.com:443 -servername example.com and watch for 'TLS alert, unrecognized name (112)'. Then try -servername with a name you KNOW works. If the known-good name connects and the broken one alerts, it's a vhost/SNI gap, not a cert problem.
2. Add the hostname to a real SSL vhostOn nginx, put the host in server_name on a server {} block listening on 443 ssl with a matching cert. On Apache, add it as ServerName or ServerAlias inside a <VirtualHost *:443> that has SSLCertificateFile pointed at a cert covering that name.
3. Define an explicit default :443 vhostGive Apache a default-ssl vhost (or nginx a default_server on 443) so unmatched SNI lands somewhere with a valid cert instead of triggering the warning. This stops one stray hostname from breaking the whole listener.
4. Make sure the cert covers the nameCheck the SAN list: openssl x509 -in cert.pem -noout -text | grep -A1 'Subject Alternative Name'. If the requested host isn't in there, reissue with it included (or add a SAN cert for that vhost). A vhost with the right server_name but the wrong cert still fails.
5. Reload and retest both namesnginx -t && systemctl reload nginx, or apachectl configtest && systemctl reload apache2. Re-run the s_client check on the previously-broken host. The alert line should be gone and you should see the cert chain instead.