Fixing SSL_ERROR_UNRECOGNIZED_NAME_ALERT: A Practical SNI Troubleshooting Guide

The Scenario

You’ve just finished installing a fresh SSL certificate. On paper, everything looks perfect. However, the moment you point Firefox to your domain, you hit a wall: SSL_ERROR_UNRECOGNIZED_NAME_ALERT. While Chrome might shrug and show a vague 'Connection is not private' warning, Firefox is much more helpful—it specifically flags a failure during the TLS handshake.

This usually happens on VPS or dedicated servers hosting 5, 10, or 100 different domains. The server gets confused. It receives a request but doesn't know which specific certificate to hand back to the browser.

Why This Error Occurs

Think of Server Name Indication (SNI) as the digital equivalent of an apartment number. In the old days, one IP address meant one website. Today, a single IP might host hundreds of sites. SNI is the TLS protocol extension that lets the browser tell the server, "I'm looking for example.com," right at the start of the connection.

When you see this alert, the server is essentially saying: "I heard your request for example.com, but I don't have a configuration block or a certificate that matches that name." Rather than guessing and sending the wrong one, the server terminates the connection with an 'Unrecognized Name' alert.

Step 1: Audit Your Nginx Configuration

Nginx is strict. If your server_name directive doesn't exactly match the host header from the browser, the handshake will likely fail.

Check the Server Block

Locate your site configuration—usually tucked away in /etc/nginx/sites-available/. Look specifically at your SSL block:

server {
    listen 443 ssl;
    server_name example.com; # Does this match your browser's URL bar?

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

Missing subdomains are a frequent culprit. If you visit www.example.com but your config only lists the root, the server won't recognize the request. Fix it by listing both:

server_name example.com www.example.com;

Watch Out for Default Server Traps

Nginx falls back to a "default" server when it can't find a direct match. If that default block lacks SSL or is configured to reject unknown names, your site won't load. Always ensure your specific domain block has the highest priority for its unique hostname.

Step 2: Correcting SNI on Apache

Apache users face similar hurdles within the VirtualHost container. Precision matters here. Your ServerName and ServerAlias must align perfectly with the domain triggering the error.

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

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

Modern Apache (2.4+) handles SNI automatically. However, if you're maintaining a legacy system, ensure NameVirtualHost *:443 is defined in your global config to allow multiple certificates on one IP.

Step 3: Hunt Down Port Conflicts

Sometimes, a stray configuration file "steals" traffic on port 443 before it ever reaches your domain block. This is common if you've recently migrated sites or changed hostnames. Use grep to scan your config directories for every instance of port 443:

# For Nginx
grep -r "443" /etc/nginx/

# For Apache
grep -r "443" /etc/apache2/

Look for default or 000-default files. If they are listening on 443 without valid certificates, they will act as a black hole for your TLS traffic.

The "Strict" SNI Setting

Advanced Nginx setups often use ssl_reject_handshake on;. This is a powerful security feature that kills any connection not matching a known server_name. While it prevents IP-based scanning, it makes the SSL_ERROR_UNRECOGNIZED_NAME_ALERT inevitable if you have even a minor typo in your config.

Double-check that your domain block is loaded and active before this rejection rule takes effect.

Verification: How to Test Your Fix

Browsers are notorious for aggressive caching. To see what the server is actually doing, move to the command line.

Using OpenSSL

This command is the gold standard for testing SNI issues. It simulates exactly what a browser does during the handshake:

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

The -servername flag is the secret sauce here; it sends the SNI header. Check the output for Verification: OK and ensure the Certificate chain actually belongs to your domain. If you see an 'unrecognized name' error here, the server-side config is still broken.

Using Curl

For a quicker, high-level check, use curl's verbose mode:

curl -Iv https://example.com

Scan for the line indicating a successful connection, such as SSL connection using TLSv1.3. If curl connects without complaining about hostnames, you've solved the puzzle.

Summary Checklist

- Does your `server_name` (Nginx) or `ServerName` (Apache) match the URL exactly?
- Did you include both the root domain and the `www` subdomain?
- Have you restarted the service? Use `systemctl restart nginx` or `apache2`.
- Is a default configuration block intercepting port 443 requests?
- Are your `.pem` or `.crt` file paths valid and readable by the web server?