SNI Explained: HTTPS Hostnames & Privacy Leaks

TLS SNI allows multiple TLS certificates to be served from a single IP address by letting the client specify which hostname it’s trying to reach before the TLS handshake is fully established.

Let’s see this in action with Nginx. Imagine you have two websites, example.com and anothersite.org, both needing secure connections but hosted on the same server.

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;

    # ... other directives for example.com
    root /var/www/example.com;
    index index.html;
}

server {
    listen 443 ssl;
    server_name anothersite.org;

    ssl_certificate /etc/nginx/ssl/anothersite.org.crt;
    ssl_certificate_key /etc/nginx/ssl/anothersite.org.key;

    # ... other directives for anothersite.org
    root /var/www/anothersite.org;
    index index.html;
}

When a browser connects to https://example.com, it initiates a TCP connection to the server’s IP on port 443. Instead of immediately sending its certificate, the client sends a "Client Hello" message that includes the hostname it’s targeting. Nginx inspects this server_name field in the Client Hello and, based on that, selects the appropriate ssl_certificate and ssl_certificate_key to present back to the client for the rest of the TLS handshake. If the server_name isn’t found, Nginx will typically fall back to a default certificate (if configured) or present an error.

This mechanism solves the problem of needing a unique IP address for every single HTTPS site. Before SNI, each domain requiring SSL/TLS needed its own dedicated IP address because the server had no way to know which certificate to present during the handshake. With SNI, the server can efficiently host hundreds or even thousands of distinct HTTPS sites on a single IP, drastically reducing the need for IP address exhaustion and simplifying server management. The "Server Name Indication" extension is a part of the TLS protocol itself, specifically designed for this purpose.

The primary levers you control are the server_name directive in your web server configuration and ensuring that the corresponding certificate files are correctly linked. Your certificate authority issues certificates for specific domain names, and SNI’s job is to ensure the correct domain-specific certificate is served.

If your client’s TLS library doesn’t support SNI (which is rare for modern browsers but can happen with older clients or custom applications), it will likely connect to the first certificate configured on the server, leading to certificate name mismatch errors for any other domains hosted on that IP.

The next concept you’ll typically encounter when dealing with TLS is the Certificate Transparency log, which aims to provide a public, auditable record of all issued TLS certificates.