How to Fix the ERR_SSL_UNRECOGNIZED_NAME_ALERT Error

ERR_SSL_UNRECOGNIZED_NAME_ALERT is one of the few SSL errors that has nothing to do with your certificate. The connection fails so early that no certificate is ever examined, which is why the usual checklist of expiry dates, certificate authorities, and browser trust stores leads nowhere.

This guide explains what the server is actually reporting when it sends this alert, why it is a virtual host and SNI problem rather than a certificate problem, and how to find and fix the mismatch on Apache, nginx, and the proxies in front of them.

Quick answer:

ERR_SSL_UNRECOGNIZED_NAME_ALERT means the server deliberately ended the TLS handshake by sending alert 112, unrecognized_name, because the hostname the browser requested through SNI (Server Name Indication) matches no virtual host configured on that server. The handshake stops before any certificate is sent, so the certificate’s expiry date, issuer, and trust status are not the cause and replacing it will not help.

Fix it on the server: add the hostname to a virtual host with ServerName or ServerAlias on Apache, or server_name on nginx, and check that a catch-all default server running ssl_reject_handshake on is not rejecting it.

Table of Contents

1. What Is the ERR_SSL_UNRECOGNIZED_NAME_ALERT Error?
2. Common Causes of the ERR_SSL_UNRECOGNIZED_NAME_ALERT Error
3. How to Fix the ERR_SSL_UNRECOGNIZED_NAME_ALERT Error as a Website Owner
4. How to Fix the ERR_SSL_UNRECOGNIZED_NAME_ALERT Error as a Website Visitor
5. Frequently Asked Questions

What Is the ERR_SSL_UNRECOGNIZED_NAME_ALERT Error?

ERR_SSL_UNRECOGNIZED_NAME_ALERT is Chrome’s name for a specific message it received from the server. In Chromium’s network error list the code is -159, described as “the SSL server sent us a fatal unrecognized_name alert”. Firefox reports the same condition as SSL_ERROR_UNRECOGNIZED_NAME_ALERT, worded as “SSL peer has no certificate for the requested DNS name”.

Both browsers are relaying a decision made by the server, not making one of their own. The browser did not fail to recognize anything. The server told it to go away.

Where the handshake breaks

To understand the error you need one detail of the TLS handshake. A single IP address can host hundreds of websites, so before the server can pick a certificate it has to know which site the visitor wants. The browser supplies that in the very first message it sends, the ClientHello, in an extension called Server Name Indication. It is a plain text field carrying a hostname, for example example.com.

The server reads that hostname and looks for a matching virtual host. If it finds one, it sends back that site’s certificate and the handshake continues. If it finds none, RFC 6066, section 3 gives it two choices: continue the handshake anyway, or “abort the handshake by sending a fatal-level unrecognized_name(112) alert”. ERR_SSL_UNRECOGNIZED_NAME_ALERT is what you see when the server takes the second option.

The sequence is worth spelling out, because it determines everything about the fix:

1. The browser opens a TCP connection and sends a ClientHello containing the hostname in SNI.
2. The server searches its virtual hosts for that hostname and finds no match.
3. The server sends a fatal alert 112 and closes the connection.
4. The browser shows ERR_SSL_UNRECOGNIZED_NAME_ALERT.

No certificate is transmitted at step 3. The server never got far enough to choose one. This is why an expired certificate, a revoked certificate, a broken intermediate chain, or a self-signed certificate cannot produce this particular error. Each of those failures happens later in the handshake and raises a different message, which we list further down.

Fatal alerts versus warning alerts

Alert 112 comes in two severity levels, and the difference explains a lot of confusing behavior.

A fatal alert 112 ends the connection immediately. Every browser shows an error page. This is the case you are troubleshooting when you see ERR_SSL_UNRECOGNIZED_NAME_ALERT.

A warning-level alert 112 lets the handshake continue. Browsers ignore it and the page loads, so you never learn it happened. RFC 6066 discourages sending one at all, noting that it is “NOT RECOMMENDED” because “the client’s behavior in response to warning-level alerts is unpredictable”. That unpredictability is not theoretical: Java clients from JDK 7 onward began sending SNI by default and treated a warning-level 112 as fatal, producing the well-known SSLProtocolException: handshake alert: unrecognized_name against servers that browsers loaded without complaint. Current Java releases still refuse it, wording the failure as SSLHandshakeException: received handshake warning: unrecognized_name.

So if a hostname works in a browser but fails from a Java application, a monitoring agent, or a script, you are probably looking at a warning-level alert that only the stricter client refuses to accept. The underlying misconfiguration is the same, and so is the fix.

Common Causes of the ERR_SSL_UNRECOGNIZED_NAME_ALERT Error

Every cause below is a variation on the same theme: the name in the ClientHello does not reach a virtual host that claims it. What differs is where the name gets lost.

1. The hostname is missing from the server configuration

This is the plain version of the problem and the most common one on a single server. The site’s virtual host declares example.com but not www.example.com, or a new domain was pointed at the server before anyone added a block for it. Mismatches like this are especially common in shared hosting, where many hostnames share one IP address and one small typo in a name leaves a site unreachable.

A related variant: the hostname is configured on port 80 but not on port 443, so plain HTTP works and HTTPS does not.

2. An nginx catch-all server is rejecting the handshake

This is the single most common modern source of a fatal alert 112, and it is deliberate behavior rather than a bug.

nginx 1.19.4 introduced the ssl_reject_handshake directive. Administrators put it on the default server so that requests for hostnames they do not host are refused outright instead of being served someone else’s site. The nginx documentation gives exactly this pattern:

server {
    listen               443 ssl default_server;
    ssl_reject_handshake on;
}

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

Any hostname other than example.com falls through to the default server and is rejected. Internally nginx sets the alert to SSL_AD_UNRECOGNIZED_NAME at fatal level, which is precisely the alert 112 the browser reports. The configuration is working as designed. The error simply means your hostname is not on the list of servers nginx recognizes.

Note that this also rejects clients that send no SNI at all, including anything connecting to the server by raw IP address.

3. A reverse proxy or load balancer forwards the wrong name

When a proxy re-encrypts traffic to a backend, it opens its own TLS connection and chooses its own SNI value. If it sends the name the visitor typed rather than the backend’s own hostname, or sends no SNI at all, the backend rejects it and the proxy passes the failure on.

On nginx the give-away is in the error log, where the alert number appears in plain text:

SSL_do_handshake() failed (SSL: error:0A000458:SSL routines::tlsv1
unrecognized name:SSL alert number 112) while SSL handshaking to upstream

The phrase “while SSL handshaking to upstream” tells you the failing leg is proxy to backend, not visitor to proxy. Nginx Proxy Manager, Traefik, HAProxy, and cloud load balancers all produce their own version of this when the SNI they forward does not match the backend’s virtual hosts.

4. DNS points at a server that does not host the site

If an A or AAAA record still points at an old host after a migration, the browser sends the right hostname to the wrong machine. That machine has never heard of the site, so it rejects the name. The configuration on your new server is perfect and completely irrelevant, because nothing is reaching it.

Suspect this first when the error appears in some locations and not others, which is the signature of a DNS change that has not finished propagating.

5. The connection uses an IP address or sends no SNI

Browsing to https://203.0.113.10 sends either no SNI or an IP literal, neither of which matches a name-based virtual host. Old clients that predate SNI support hit the same wall. Any server with a strict catch-all will reject these connections.

6. A middlebox rewrites the handshake

Corporate TLS inspection appliances, some antivirus products with HTTPS scanning, and captive portals terminate and rebuild TLS connections. If the device drops or alters the SNI field on the way through, the origin server sees a name it cannot match. This is the one cause that can make a site fail on a single office network while working everywhere else.

What does not cause this error

Because the handshake ends before certificate validation, certificate problems raise their own distinct errors. If you are seeing one of these instead, you are on the wrong page, and the linked guide is the one you want:

• An expired certificate raises NET::ERR_CERT_DATE_INVALID.
• A certificate from an untrusted issuer raises NET::ERR_CERT_AUTHORITY_INVALID. Certificates from a publicly trusted certificate authority such as Sectigo or DigiCert are already in the browser trust stores, so they avoid that error.
• A self-signed certificate raises MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT in Firefox and an authority error in Chrome.
• A revoked certificate raises NET::ERR_CERT_REVOKED.
• A certificate that does not cover the hostname raises NET::ERR_CERT_COMMON_NAME_INVALID.
• Incompatible protocol versions or cipher suites raise ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

Two more things that will not fix it, since both are commonly suggested. Buying or reissuing a certificate changes nothing, because no certificate is involved in the failure. Adding an HTTP to HTTPS redirect changes nothing either: a redirect is an HTTP response, and HTTP responses are only sent after a handshake succeeds. The handshake here never succeeds, so the redirect is never reached.

How to Fix the ERR_SSL_UNRECOGNIZED_NAME_ALERT Error as a Website Owner

Work through these in order. The first two steps are diagnosis and take about a minute, and they tell you which of the remaining steps you actually need.

1. Confirm the alert with OpenSSL

Before changing any configuration, confirm the server really is sending alert 112. Connect once with your hostname in SNI:

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

A server that rejects the name answers with the alert number rather than a certificate chain:

CONNECTED(00000003)
40B7B4C7017F0000:error:0A000458:SSL routines:ssl3_read_bytes:tlsv1
unrecognized name:ssl/record/rec_layer_s3.c:1590:SSL alert number 112

Seeing SSL alert number 112 confirms the diagnosis. Now run the same connection with SNI suppressed:

openssl s_client -connect example.com:443 -noservername

Compare the two results. If the second call returns a certificate while the first is rejected, the server has a working default site and is specifically refusing your hostname, which points at steps 3 and 4. If both are rejected, a strict catch-all is refusing everything it does not recognize, which points at step 4.

The -noservername flag matters. Since OpenSSL 1.1.1, s_client fills in SNI automatically from the hostname you pass to -connect, so simply leaving out -servername does not test the no-SNI case.

Run these on Linux, or with a current OpenSSL build. The openssl command that ships with macOS is LibreSSL, which does not recognize -noservername and prints a usage error instead of connecting.

To test a specific machine rather than whatever DNS resolves to, connect by IP address and set SNI by hand. This is also how you check a backend that sits behind a proxy:

openssl s_client -connect 203.0.113.10:443 -servername example.com

2. List the virtual hosts the server actually loaded

The configuration you think is running and the configuration the server loaded are not always the same file. Ask the server directly.

On Apache, print the full virtual host map:

sudo apachectl -S

The output lists every name-based virtual host per address and port, along with the file and line number where each is defined. Find the block serving port 443 and check whether your hostname appears there. Apache also records the fallback in its log at debug level, in a line worth searching for:

No matching SSL virtual host for servername example.com found
(using default/first virtual host)

On nginx, dump the complete configuration including every included file:

sudo nginx -T | grep -n "server_name\|listen\|ssl_reject_handshake"

Check that your hostname appears in a server_name line inside a block that also listens on 443 with ssl. Note any ssl_reject_handshake line and which server block it belongs to.

3. Add the hostname to a matching virtual host

This is the actual fix for the ordinary case. The hostname has to be declared on a virtual host that listens on port 443.

On Apache, ServerName sets the primary name and ServerAlias adds any others. List every hostname the site answers to, including the www and non-www forms:

<VirtualHost *:443>
    ServerName  example.com
    ServerAlias www.example.com shop.example.com

    SSLEngine on
    SSLCertificateFile    /etc/ssl/certs/example.com.crt
    SSLCertificateKeyFile /etc/ssl/private/example.com.key
</VirtualHost>

Test the configuration before reloading, so a syntax error cannot take the server down:

sudo apachectl configtest
sudo systemctl reload apache2

On Red Hat and its derivatives the service is named httpd, so reload with sudo systemctl reload httpd instead.

On nginx, every name goes on the server_name directive, separated by spaces:

server {
    listen              443 ssl;
    server_name         example.com www.example.com;

    ssl_certificate     /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;
}

sudo nginx -t
sudo systemctl reload nginx

One consequence to plan for: once the server stops rejecting the hostname, the certificate finally gets sent, and it now has to cover that hostname. If it does not, the alert 112 is replaced by a name mismatch error. Covering several hostnames on one certificate is what multi-domain (SAN) certificates are for, and adding each name to the certificate’s SAN list is the accompanying half of this fix. If you need to install a new one, follow our guides on installing an SSL certificate.

4. Check the catch-all default server

If step 1 showed that every hostname is rejected, including ones you know are configured, look at the default server rather than the site.

On nginx, find the block marked default_server and check whether it carries ssl_reject_handshake on. If it does, the directive is doing its job and the real problem is that your hostname never matched a named server block, so send it back to step 3. Removing ssl_reject_handshake is not the fix. It only replaces a clear error with a confusing one, because unmatched hostnames will then be served the default site’s certificate and visitors will get a name mismatch warning instead.

Apache behaves differently and it is useful to know how. Current versions of Apache do not send an alert when SNI does not match. They quietly fall back to the default or first virtual host, following the other branch RFC 6066 allows. So on Apache this error usually points to something in front of the server rather than the server itself, or to an older version still emitting a warning-level alert that a strict client is refusing.

5. Fix SNI on a proxy or load balancer

If the failure is on the proxy to backend leg, the proxy has to send a name the backend recognizes. On nginx, two directives control this:

proxy_ssl_server_name on;
proxy_ssl_name         backend.example.com;

proxy_ssl_server_name is off by default, which means nginx sends no SNI to an HTTPS backend at all unless you turn it on. That default alone explains a large share of these failures. proxy_ssl_name sets the name to send, defaulting to the proxied host, and you override it when the backend expects something different from the address you are connecting to.

On other systems, look for the equivalent setting: HAProxy uses sni on the server line, Traefik uses serversTransport, and most cloud load balancers expose it as an SNI or host header override in the backend or target group settings. Verify the result with the IP address form of the OpenSSL command from step 1, run from the proxy itself.

6. Verify DNS points where you think it does

Check which address the hostname resolves to and compare it against the server you have been editing:

dig +short example.com

If the answer is an old host, no amount of virtual host configuration on the new one will help. Correct the A or AAAA record and wait out the TTL.

7. Confirm the site is healthy once the handshake works

When the handshake completes, check what the server is now presenting. Run a scan with our free SSL Checker, which reports the certificate returned for your hostname, the names it covers, and the chain. For a deeper look at protocol versions and cipher configuration, the Qualys SSL Server Test is the more detailed option.

Neither tool can diagnose the alert itself, since both need a handshake to complete before they have anything to report. That is exactly why the OpenSSL check in step 1 comes first.

8. Contact your hosting provider

On shared or managed hosting you may not be able to see the virtual host configuration, let alone edit it. In that case your provider has to make the change, and a specific request gets a much faster answer than a description of the symptom.

Tell them the server is returning a fatal TLS alert 112, unrecognized_name, for your hostname on port 443, and ask them to confirm the hostname is present in a virtual host bound to that port. Include the output of the OpenSSL command from step 1, which shows the alert number and saves them reproducing it.

How to Fix the ERR_SSL_UNRECOGNIZED_NAME_ALERT Error as a Website Visitor

As a visitor there is not much you can do to resolve this, because it needs a configuration change on the website’s server. Clearing your cache, updating your browser, changing your DNS settings, or correcting your computer’s clock will not help, since none of them affect which virtual hosts the server has configured.

Three checks are still worth a minute of your time, because they cover the cases where the problem is on your side of the connection:

• Check the address you typed. A subdomain that does not exist, or an IP address entered instead of a domain name, produces this error by design.
• Try a different network. If the site loads on mobile data but fails on a corporate or campus network, a TLS inspection appliance on that network is likely altering the handshake. Your network administrator can add the site to its bypass list.
• Try another device on the same network. If only one machine fails, check whether antivirus software with HTTPS scanning is enabled on it and test with that feature turned off.

If the error appears everywhere, it is the site’s configuration. Contact the website owner and tell them the server is sending a TLS unrecognized_name alert for that hostname. That phrase points them straight at the cause, whereas “your site is down” sends them looking at their certificate.

Frequently Asked Questions

For more SSL error troubleshooting, check our detailed tutorials about fixing different SSL errors.