Your browser throws a wall of red: ERR_SSL_UNRECOGNIZED_NAME_ALERT. There's no "certificate expired" message, no "click to proceed anyway" link — Chrome just refuses to load the page at all. If you've already checked that your SSL certificate is valid and not expired, this one can feel like a dead end. It usually isn't. It almost always comes down to one thing: the server your domain is pointing at doesn't have a certificate — or even a website — configured for that exact hostname.
What's Actually Happening
When your browser connects over HTTPS, it doesn't just open a TCP connection and ask for "whatever site is here." Modern TLS uses something called SNI (Server Name Indication) — during the handshake, the browser tells the server "I'm looking for example.com," before any certificate is exchanged. The server is supposed to look up that exact hostname and hand back the matching certificate.
ERR_SSL_UNRECOGNIZED_NAME_ALERT means the server received that SNI hostname and flat-out doesn't recognize it. It's not "wrong certificate" (that gives you a different, more common error — NET::ERR_CERT_COMMON_NAME_INVALID). This is the server saying "I have no configuration at all for this name," and sending back a TLS alert instead of a handshake.
The Usual Suspects
On shared and reseller cPanel hosting, this shows up more often than you'd think. Here's what typically causes it, roughly in order of how often we see it:
- The domain isn't actually added to the hosting account yet. The DNS A record points at the right IP, but nobody's added the domain as an addon domain (or the primary domain) in cPanel. Apache has no
<VirtualHost>block — and therefore no SNI entry — for that hostname, even though the IP is reachable. - A leftover DNS record from a cancelled or migrated account. Someone points a domain at an old shared IP, forgets to update it after moving hosts, and the new tenant on that IP has no idea a stranger's domain is aimed at their server.
- Cloudflare (or another proxy/CDN) pointed at the wrong origin. The orange cloud is proxying traffic to an IP or hostname that has no certificate — or no site — for your domain. The browser talks to Cloudflare fine, but Cloudflare's connection to your actual server fails the same way.
- www vs. non-www mismatch on a fresh SSL install. AutoSSL or Let's Encrypt issued a cert for
example.combut notwww.example.com(or vice versa), and there's no vhost alias covering the missing one. - A load balancer or reverse proxy in front of multiple backends that isn't passing SNI through correctly, so the backend never sees which hostname was actually requested.
How to Confirm It's an SNI Problem
Before changing anything, verify the diagnosis with openssl from your own machine or a VPS:
openssl s_client -connect yourdomain.com:443 -servername yourdomain.comLook at the certificate that comes back. If it's a certificate for a completely different domain (someone else's site, a hosting company's default cert, or a self-signed placeholder), you've confirmed the server has no matching vhost for your hostname. Compare that against:
openssl s_client -connect yourdomain.com:443 -servername wrong-name-on-purpose.comIf both commands return the exact same unrelated certificate, that's the server's default/fallback vhost answering for every name it doesn't recognize — strong confirmation this is a "domain not configured here" issue, not a certificate problem.
The Fix
Match the fix to the cause you found above:
| Cause | What to do |
|---|---|
| Domain not added in cPanel | WHM/cPanel > Domains > Create A New Domain — add it as an addon domain, then re-run AutoSSL for the account |
| Old DNS pointing at your IP by mistake | Nothing to fix server-side; the domain's owner needs to update their DNS. You can confirm this isn't your account's domain via WHM > List Accounts |
| Cloudflare pointed at the wrong origin | DNS tab in Cloudflare > check the A/CNAME record's target IP matches your actual hosting IP; also check SSL/TLS mode isn't set to "Full (strict)" against a self-signed origin cert |
| www / non-www not both covered | cPanel > SSL/TLS Status > run AutoSSL, or re-issue Let's Encrypt with both the bare domain and www as SANs |
| Load balancer not forwarding SNI | Enable SNI passthrough / TLS passthrough mode instead of terminating and re-encrypting without the hostname |
After adding the domain or fixing DNS, give AutoSSL a few minutes to issue the certificate — cPanel checks domain ownership via HTTP validation, so the DNS/vhost fix has to be live first, or the SSL request itself will fail silently and you'll be back to square one.
If You're Behind Cloudflare
Set SSL/TLS mode to Full (not Flexible) once your origin has a valid certificate — Flexible mode hides real origin errors like this behind Cloudflare's own edge certificate, which makes debugging much harder because visitors never see the real handshake failure. Test the origin directly by temporarily editing your local hosts file to bypass Cloudflare's proxy and hitting the server IP directly with the right Host header.
Prevention
A few habits that keep this from happening again:
- Add the domain in cPanel before pointing DNS at the server, not after — that way AutoSSL has something to validate against the moment DNS resolves.
- When you retire or move a domain off SkyServer, remove it from the account rather than leaving it parked — stops it silently breaking for whoever's IP it lands on next.
- If you manage certs manually, always list both
example.comandwww.example.comas Subject Alternative Names on the same certificate. - Check
WHM > SSL/TLS Statusperiodically — it flags domains with no valid certificate before a customer stumbles on the error first.
Frequently Asked Questions
Is ERR_SSL_UNRECOGNIZED_NAME_ALERT the same as a certificate mismatch error?
No. A certificate mismatch (ERR_CERT_COMMON_NAME_INVALID) means the server found a certificate but it's for a different name than what you requested. ERR_SSL_UNRECOGNIZED_NAME_ALERT means the server rejected the SNI hostname outright, usually because there's no site or certificate configured for it at all.
Why does this only happen on some devices or browsers?
It generally doesn't vary by browser — SNI support has been universal for over a decade. If it "only happens on some devices," it's more likely a DNS caching difference: some devices are still resolving an old IP where the domain was actually configured, while others hit the new IP where it isn't.
Could this be caused by an expired SSL certificate instead?
An expired certificate gives a different warning (NET::ERR_CERT_DATE_INVALID) with an option to proceed anyway. ERR_SSL_UNRECOGNIZED_NAME_ALERT is more severe — the browser can't even get to the "proceed anyway" screen because the handshake itself was rejected.
I just added the domain in cPanel — how long until the error clears?
Usually within a few minutes once AutoSSL issues a certificate, but allow up to 15-20 minutes for the cron-triggered AutoSSL check to run, or trigger it manually from WHM > SSL/TLS Status > Run AutoSSL for the account.
Does this affect email (IMAP/SMTP) as well as the website?
It can, if mail services are also using SNI-based certificate selection and the mail hostname isn't covered by a valid certificate. Check with the same openssl s_client command against port 993 or 465 using -servername mail.yourdomain.com.
