How to Fix ERR_SSL_UNRECOGNIZED_NAME_ALERT in 2026

When connecting to a web server or REST API, encountering ERR_SSL_UNRECOGNIZED_NAME_ALERT (or in Java and Android environments: javax.net.ssl.SSLHandshakeException: Received fatal alert: unrecognized_name) halts client communications immediately. Unlike ordinary certificate authority trust issues or domain name mismatches, this error signals a protocol-level rejection during Server Name Indication (SNI) negotiation.

In Pakistani multi-tenant web hosting, cPanel installations, and microservice clusters, this error frequently trips up mobile apps, automated payment gateways, and strict HTTP clients. It occurs when a client explicitly requests a specific hostname during the TLS handshake, but the web server has no configured virtual host or SSL certificate matching that hostname—and fails to provide a valid default fallback.

In this deep-dive guide, we break down TLS Alert 112 under RFC 6066, reproduce the failure with OpenSSL, and implement robust server-side configurations across Nginx, Apache, and cPanel.

---

1. Cryptographic Mechanics: TLS Alert 112 and RFC 6066

In early versions of SSL, a web server could only host a single SSL certificate per physical IP address because the cryptographic handshake occurred before any HTTP Host header was transmitted.

Server Name Indication (SNI) (formalized in RFC 6066) solved this by having the client declare the destination hostname directly inside the TLS ClientHello message:

    Client (Browser / Java / cURL)                       Server (Nginx / Apache / cPanel)
┌─────────────────────────────────────┐               ┌─────────────────────────────────────┐
│ 1. Sends ClientHello                │               │                                     │
│    - SNI: "api.yourdomain.pk"       │──────────────►│ 2. Evaluates Virtual Host Registry  │
│    - TLS Version: 1.3               │   (TCP:443)   │    - Host "api.yourdomain.pk"?      │
└─────────────────────────────────────┘               └──────────────────┬──────────────────┘
                                                                         │
                                                             Is hostname recognized?
                                                                         │
                                                       ┌─────────────────┴─────────────────┐
                                                       ▼                                   ▼
                                                  YES (Match)                          NO (Unknown)
                                                       │                                   │
                                                       ▼                                   ▼
                                             [ Serves Vhost Cert ]                [ Emits Alert 112 ]
                                             (Handshake Completes)                (unrecognized_name)
                                                                                           │
                                                                                           ▼
                                                                           ERR_SSL_UNRECOGNIZED_NAME_ALERT

According to RFC 6066 Section 3:

“If the server understood the client hello extension but does not recognize the server name, the server SHOULD send an ‘unrecognized_name’ fatal alert (112).”

While lenient desktop browsers sometimes ignore Alert 112 and fall back to whatever default certificate the server presents, strict clients (Java HttpClient, Android OkHttp, cURL, Python urllib3, and modern Chrome builds) strictly enforce the standard and terminate the connection immediately.

---

2. Diagnosing Alert 112 via Command Line

To confirm whether your server is emitting Alert 112:

# Test connection with explicit SNI hostname
openssl s_client -connect yourdomain.pk:443 -servername yourdomain.pk -tlsextdebug

If the server rejects the hostname, OpenSSL output will explicitly state:

SSL3 alert write:fatal:unrecognized name
140124892:error:14094458:SSL routines:ssl3_read_bytes:tlsv1 alert unrecognized name:../ssl/record/rec_layer_s3.c:1543:SSL alert number 112

---

3. Resolving the Error in Nginx

In Nginx, Alert 112 occurs when an incoming request hits an IP address where no server block matches the SNI hostname, and no explicit default_server is defined.

Solution A: Modern Clean Rejection (Nginx 1.19.4+)

If you do not want arbitrary domains or raw IP scanning bots connecting to your server, you can explicitly configure Nginx to reject handshakes cleanly without throwing broken alerts:

# /etc/nginx/conf.d/00-default.conf
server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    server_name _;
    
    # Modern Nginx directive to reject undefined SNI requests gracefully
    ssl_reject_handshake on;
}

Solution B: Graceful Fallback Certificate

If you run an API gateway or multi-tenant SaaS platform where unexpected subdomains must receive a valid certificate:

server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    server_name _;

    # Provide a generic wildcard or fallback certificate
    ssl_certificate /etc/ssl/certs/fallback-wildcard.crt;
    ssl_certificate_key /etc/ssl/private/fallback-wildcard.key;

    # Return 404 or redirect rather than dropping TLS
    location / {
        return 404 "Unrecognized domain host header.";
    }
}

Ensure your primary application server block explicitly defines all valid domains:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name yourdomain.pk www.yourdomain.pk api.yourdomain.pk;

    ssl_certificate /etc/letsencrypt/live/yourdomain.pk/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.pk/privkey.pem;
    
    # ... application directives ...
}

---

4. Resolving the Error in Apache and cPanel

Apache Configuration

In standalone Apache installations, define a catch-all VirtualHost at the very top of your SSL configuration (e.g., /etc/httpd/conf.d/ssl.conf):

<VirtualHost _default_:443>
    ServerName default.local
    DocumentRoot /var/www/html
    
    SSLEngine on
    SSLCertificateFile /etc/pki/tls/certs/localhost.crt
    SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
</VirtualHost>

<VirtualHost *:443>
    ServerName yourdomain.pk
    ServerAlias www.yourdomain.pk
    DocumentRoot /home/user/public_html
    
    SSLEngine on
    SSLCertificateFile /var/cpanel/ssl/installed/certs/yourdomain.crt
    SSLCertificateKeyFile /var/cpanel/ssl/installed/keys/yourdomain.key
</VirtualHost>

cPanel / WHM Resolution

If you manage servers via cPanel/WHM:

1. Log into WHM as root.
2. Navigate to SSL/TLS > Manage SSL Hosts.
3. Locate the primary shared IP address of your server.
4. If no domain is flagged as the primary SSL host for that IP, select your server’s primary fully qualified domain name (FQDN) or your company website and click Make Primary.
5. This ensures that any client connecting without a matching SNI record receives the primary domain’s valid certificate rather than emitting Alert 112.

---

5. Corroborating TLS Handshake Anomalies

To troubleshoot other cryptographic handshake hurdles across Pakistani networks, review our companion guides on Resolving ERR_SSL_VERSION_OR_CIPHER_MISMATCH and Fixing SSL_ERROR_BAD_MAC_READ in Browsers & Linux.

For fintech startups, high-traffic portals, and software development firms in Pakistan requiring pristine SNI routing and dedicated IP allocations, Nextgen provides enterprise-grade bare-metal Dedicated Servers and locally routed Dedicated Servers in Pakistan.