How to Fix ERR_SSL_UNRECOGNIZED_NAME_ALERT

What the error means

When a browser opens an HTTPS page, it sends the website's host name, for example www.example.com, at the very start of the TLS handshake. This is called Server Name Indication (SNI), and it lets one server with one IP address host many sites, each with its own certificate (see Dedicated IP vs SNI).

If the server has no site for that name, the TLS standard (RFC 6066, section 3) lets it either continue the handshake or abort it with a fatal unrecognized_name alert (alert number 112). Chrome shows this error when it receives that fatal alert. The handshake stops before any certificate is sent, so the page cannot load at all.

A server that continues the handshake instead sends a default certificate issued for another name, and the browser then shows NET::ERR_CERT_COMMON_NAME_INVALID. Both errors have the same root cause: the server is not configured for the name you opened. Other handshake failures, such as wrong protocol versions or broken SSL setups, show up as ERR_SSL_PROTOCOL_ERROR instead.

Solutions for website visitors

These checks rule out the causes on your side:

1. Check the address for typos. A misspelled subdomain, for example ww.example.com, can reach a server that has no site for that name.
2. Try with and without www. Many sites set up only one of the two names. If example.com fails, try www.example.com, and the other way round. An old bookmark may also point to a name the site no longer uses.
3. Turn off VPN and proxy. A VPN, proxy or filtering service can route you to a different server. Try again without it, or on another network such as mobile data.
4. Try again later. If the site was just moved or set up, its owner may still be configuring the server or waiting for DNS to update.

Clearing the browser cache rarely helps with this error. Chrome does not offer a "Proceed anyway" option either, because there is no certificate to accept. If the site fails on every device and network, only its owner can fix it, so let them know.

Website owners: find out which server answers

First check which server the name points to and what it answers for that name. Run these commands from any Linux or macOS terminal (or Windows with OpenSSL installed), replacing www.example.com with your domain:

nslookup www.example.com
openssl s_client -connect www.example.com:443 -servername www.example.com

Compare the IPv4 (A) and IPv6 (AAAA) addresses nslookup returns with the address of the server or service that should host the site. If openssl ends with an unrecognized name alert, the server at that address does not know the name. To test a specific server, connect to its IP address and keep the domain in -servername, for example -connect 203.0.113.10:443 -servername www.example.com. Test every name, with and without www. Once the handshake works, check the certificate with our free SSL Checker.

Add the host name to the web server

Every name of the site needs an HTTPS virtual host (port 443) that lists it. A host name that is only in the port 80 configuration does not count.

Nginx (list all names in server_name):

server {
    listen 443 ssl;
    server_name example.com www.example.com;
    ssl_certificate     /etc/ssl/example.com.crt;
    ssl_certificate_key /etc/ssl/example.com.key;
}

Nginx itself sends the unrecognized_name alert when the request falls through to a default server that has ssl_reject_handshake on; (available since nginx 1.19.4). The setting stops the server from handing out another site's certificate, but every real host name must then appear in a server_name line. sudo nginx -T prints the full configuration.

Apache (the main name in ServerName, the others in ServerAlias):

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com
    SSLEngine on
    SSLCertificateFile /etc/ssl/example.com.crt
    SSLCertificateKeyFile /etc/ssl/example.com.key
</VirtualHost>

Current Apache versions do not send the alert themselves: for an unknown name they serve the first virtual host on that IP address and port, which leads to a certificate name error instead. sudo apachectl -S lists the virtual hosts and shows which one is the default.

IIS: in IIS Manager select the site, click Bindings, then add or edit an https binding. Enter the host name, tick Require Server Name Indication and select the certificate. Add a separate binding for each name, for example with and without www.

Test the configuration and reload the server:

sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2

On Red Hat based systems the Apache service is called httpd instead of apache2.

Make sure the certificate covers the name

Load balancers and proxies often pick the site by certificate: HAProxy with strict-sni, for example, aborts the handshake with this alert when none of its certificates matches the requested name. On any server, the certificate in the virtual host must list every name in its Subject Alternative Name (SAN) field, so that visitors do not get a certificate error once the handshake works.

• Two names of one site (example.com and www.example.com): most certificates include both.
• Many subdomains: a Wildcard SSL certificate covers *.example.com.
• Several different domains on one server: a Multi-Domain SSL certificate lists them all. Read more about SAN certificates.

If a name is missing, reissue the certificate with the extra name and install it on every server that serves the site.

Check the hosting panel, CDN and DNS

1. Hosting panel. On shared hosting the server only knows domains that are added in the control panel. Add the domain, or the www name, as a domain or alias of the site, then issue or install the SSL certificate for it.
2. CDN, proxy or load balancer. If the domain points to a CDN or cloud load balancer, the host name must be added to that service and covered by its certificate. A domain that was removed from the service, or a new subdomain that was never added, can trigger the alert.
3. DNS pointing to the wrong server. After a move to new hosting, an old A or AAAA record may still send visitors to the previous server, which no longer has the site. Update or delete the old records. Because many devices prefer IPv6, a forgotten AAAA record can break the site for some visitors only.

DNS changes take effect as the old records expire (their TTL). Meanwhile, test the new server by IP address as shown in step 3.