What's the difference between this and ERR_CERT_COMMON_NAME_INVALID?

They fail at different points in the handshake, and that's the whole diagnosis. ERR_SSL_UNRECOGNIZED_NAME_ALERT happens *before* the server ever sends a certificate — the client puts the hostname in the SNI field of the ClientHello, the server looks for a matching virtual host, finds nothing, and aborts with a TLS `unrecognized_name(112)` alert. ERR_CERT_COMMON_NAME_INVALID happens *after*: the server did send a certificate, the handshake completed, and only then did the browser notice the name on the cert doesn't cover the hostname. One is 'the server won't talk to you about that name'; the other is 'the server talked, but showed the wrong cert.'

The site works in my browser but my script or health check gets this error. Why?

Almost always because the script isn't sending SNI, or is sending a different name. Modern browsers always put the hostname in the SNI extension. Older TLS libraries, some `curl` builds addressed by IP, Java clients on old JDKs, and monitoring agents can connect without SNI or with the wrong name — and a server configured with a strict default virtual host answers that with an unrecognized_name alert instead of a certificate. Test with `openssl s_client -connect host:443 -servername yourdomain.com` and compare against `-servername` omitted; if adding the name fixes it, the client was the problem.

Is this a problem on my server or the client I'm connecting from?

Check one thing: does every other client fail the same way? Open the hostname in a normal browser and run an external TLS check. If those succeed and only one client fails, the client is sending wrong or missing SNI — fix it there. If every client fails on that exact hostname while other hostnames on the same IP work, the server has no virtual host or certificate for the name you're requesting, and the fix is server-side: add the vhost, add the name to the cert, or point DNS at a server that actually serves it.

Views: 27

ERR_SSL_UNRECOGNIZED_NAME_ALERT: Fix the SNI Alert

ERR_SSL_UNRECOGNIZED_NAME_ALERT means the server rejected your SNI hostname before any cert. Check vhost, cert names, and SNI. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Chrome shows ERR_SSL_UNRECOGNIZED_NAME_ALERT and refuses to load the page. The instinct is to blame the certificate, and that instinct is wrong. No certificate has been rejected here — none was ever presented. This error fires earlier than any cert check, at the very first exchange of the TLS handshake, and it means the server received your hostname and answered: I don’t have anything configured under that name.

Here’s the mechanism. When your client opens a TLS connection it sends a ClientHello, and inside it is the Server Name Indication (SNI) field carrying the hostname you asked for — www.example.com. One IP address usually fronts many sites, so the server uses SNI to pick which virtual host and which certificate to answer with. If it can’t find a match, RFC 6066 §3 gives it two choices: quietly continue with a default, or abort the handshake by sending a fatal unrecognized_name(112) alert. When the server picks the second option, Chrome translates that alert into ERR_SSL_UNRECOGNIZED_NAME_ALERT. So the error isn’t about a bad certificate. It’s about a name the server doesn’t recognize.

Symptoms

Chrome (and Chromium-derived browsers) show ERR_SSL_UNRECOGNIZED_NAME_ALERT; Firefox may show SSL_ERROR_UNRECOGNIZED_NAME_ALERT for the same underlying alert.
The failure is intermittent for some visitors and total for others — a strong hint that different clients are sending different SNI.
Other hostnames on the same IP load fine; only one specific name trips the error.
openssl s_client fails when you pass the hostname with -servername but a wrong name, and the server never gets as far as printing a certificate chain.

Top 3 Causes

The hostname has no virtual host on the server - You pointed DNS at a server (or a new load balancer, or a fresh Cloudflare/CDN origin) that has no configuration for that exact name. A common variant: a wildcard or apex works, but www — or a brand-new subdomain — was never added. The server sees an SNI it can’t map to any site and sends the alert instead of guessing.
A strict default virtual host rejects unknown names - On Apache, SSLStrictSNIVHostCheck on tells the server to refuse any SNI that doesn’t match a configured ServerName/ServerAlias rather than fall back to the default vhost. That’s the setting that turns a missing name into a hard unrecognized_name alert. The name resolves, the TCP connection opens, and the handshake dies on principle.
The client sends the wrong SNI, or none - Less common but nastier to chase. A curl addressed by IP without --resolve, an old Java or Python TLS stack, or a monitoring agent can send an empty or mismatched SNI. The server does exactly what it was told to do — reject the unrecognized name — and the “broken” thing is the client, not the site. This is why the error can hit your uptime monitor while every human visitor is fine.

Diagnose with DechoNet

SSL Check against the failing hostname tells you whether the server presents a valid certificate for that name at all. If DechoNet retrieves a good chain, the server does recognize the name — and your problem is a client sending bad SNI. If it can’t complete the handshake either, the name genuinely has no home on that server.
DNS Check shows where the hostname actually points. Nine times out of ten the alert traces back to DNS aiming a name at an IP that was never configured to serve it — a stale A record, a migration half-finished, a CNAME to the wrong origin.

Resolution Checklist

Confirm which side is wrong. Load the hostname in a plain browser and run an external TLS check. All clients failing → server-side. One client failing → that client’s SNI.
If it’s the server, add the exact hostname as a virtual host and make sure its certificate covers that name (SAN entry, not just the apex). Reload the config and retest.
On Apache, decide deliberately about SSLStrictSNIVHostCheck. Leaving it on is defensible — it just means every name you intend to serve must be explicitly configured. Turning it off makes the default vhost answer unknown names, which hides the misconfiguration rather than fixing it.
If it’s the client, force the correct SNI: curl --resolve yourdomain.com:443:1.2.3.4 https://yourdomain.com, or set the server name explicitly in your TLS library. Upgrade ancient stacks that can’t send SNI.
Verify with openssl s_client -connect HOST:443 -servername yourdomain.com. A clean handshake and a printed certificate chain means the name is now recognized.

When to Escalate

If the SSL check retrieves a valid certificate for the name but one specific client still trips the alert, the argument is over: that client is sending wrong SNI. Hand it to whoever owns the client — a webhook sender, a third-party monitor, an SDK — with the -servername test as proof.
If you added the virtual host and cert and the alert persists, check for a proxy or load balancer in front of your server terminating TLS with its own, separate SNI config. The name has to be recognized at whichever hop actually completes the handshake — and that’s frequently not the box you were editing.
If the error appears only from certain networks or regions, suspect an intercepting middlebox rewriting or stripping SNI. That’s no longer a server bug; it’s the path, and you diagnose it by comparing SNI on the wire from a good network versus a bad one.