What is SNI? Run Multiple SSL Certificates on One IP Address

In the early days of HTTPS, a server could only have one SSL Certificate per IP address. Hosting multiple HTTPS domains on one server required multiple IPs. SNI solved this problem completely. This article explains what SNI is, how it works, and why it matters for modern web hosting.

What is SNI?

SNI stands for Server Name Indication. It is an extension of the TLS protocol that allows a client (browser) to specify the hostname it wants to connect to during the TLS Handshake — before the SSL connection is established.

In simple terms, SNI tells the server which domain the browser is connecting to, so the server can return the correct Certificate even when multiple domains share the same IP address.

The Problem Before SNI

The issue was that the SSL/TLS Handshake occurs before the browser sends an HTTP Request containing the domain name in the Host Header. The server had no way to know which Certificate to return.

Before SNI, web hosting required:

• One dedicated IP per SSL-enabled domain
• Making SSL on shared hosting difficult due to limited IPs
• Providers charging extra for additional IP addresses per SSL domain

How SNI Solves the Problem

SNI adds a "server_name" field to the TLS Client Hello message — the very first message the client sends during a TLS Handshake. This field tells the server which domain the client wants to connect to.

The SNI workflow:

1. The browser starts a TLS Handshake and includes the domain name in the Client Hello
2. The server reads the SNI field and selects the correct Certificate
3. The server sends the Certificate back to the browser
4. The browser verifies the Certificate and establishes the HTTPS connection

Browser Support for SNI

All modern browsers fully support SNI:

• Chrome — Supported since Chrome 6 (2010)
• Firefox — Supported since Firefox 2 (2006)
• Safari — Supported since Safari 3 (2007)
• Edge / IE — IE8+ on Windows Vista and above, all Edge versions
• Mobile — iOS Safari and Android Chrome fully supported

Legacy browsers without SNI support (such as IE6 on Windows XP) have negligible market share today.

Configuring SNI on Your Server

Apache

Apache supports SNI since version 2.2.12 using NameVirtualHost on port 443:

<VirtualHost *:443>
    ServerName domain1.com
    SSLEngine on
    SSLCertificateFile /etc/ssl/domain1.crt
    SSLCertificateKeyFile /etc/ssl/domain1.key
</VirtualHost>

<VirtualHost *:443>
    ServerName domain2.com
    SSLEngine on
    SSLCertificateFile /etc/ssl/domain2.crt
    SSLCertificateKeyFile /etc/ssl/domain2.key
</VirtualHost>

Nginx

Nginx supports SNI since version 0.5.23 using separate server blocks:

server {
    listen 443 ssl;
    server_name domain1.com;
    ssl_certificate /etc/ssl/domain1.crt;
    ssl_certificate_key /etc/ssl/domain1.key;
}

server {
    listen 443 ssl;
    server_name domain2.com;
    ssl_certificate /etc/ssl/domain2.crt;
    ssl_certificate_key /etc/ssl/domain2.key;
}

SNI on AsiaGB Shared Hosting

AsiaGB Hosting runs DirectAdmin with full SNI support. Customers can install multiple SSL Certificates for different domains and subdomains on a shared IP without any extra configuration. This works for both free Let's Encrypt and paid SSL Certificates.

Limitations of SNI You Should Know

While SNI solves the core IP-per-domain problem, a few edge cases are worth understanding before designing your infrastructure.

1. Older Clients Without SNI Support

Examples include Java Virtual Machines older than Java 7, legacy versions of curl linked against old OpenSSL builds, and SSL libraries on some embedded or industrial devices. If you must strictly support these clients, a dedicated IP for that domain may still be required.

2. SNI Is Not a Wildcard

SNI lets the server identify the correct Certificate for each domain — but it does not mean one Certificate covers all domains. You still need separate Certificates per domain, or a Wildcard Certificate that covers all subdomains of a single apex domain.

3. SNI and Encrypted Client Hello (ECH)

A known limitation of standard SNI is that the domain name is sent as plaintext in the TLS Client Hello, meaning network observers can see which domain the user is connecting to. Encrypted Client Hello (ECH) addresses this by encrypting the hostname — modern browsers are increasingly supporting it. This does not change how SNI functions at the server side.

SNI vs. Wildcard SSL: Which Should You Choose?

When you have multiple subdomains on one apex domain, there are two main approaches: separate Certificates per subdomain (relying on SNI for routing) or a single Wildcard Certificate covering all subdomains.

AsiaGB Wildcard SSL Certificates start at 5,000 THB/year (RapidSSL Wildcard), making them highly cost-effective for sites with multiple subdomains.

Testing Whether Your Server Supports SNI

Before migrating multiple domains onto one IP, confirm that your server correctly handles SNI using any of these methods.

Method 1: OpenSSL

# Test SNI with OpenSSL — includes domain name in Client Hello
openssl s_client -connect YOUR_SERVER_IP:443 \
  -servername domain1.com \
  -verify_return_error

# Check "subject" in the output — must match domain1.com
# Repeat for domain2.com to confirm a different certificate is returned

Method 2: curl

# curl supports SNI from version 7.18.1 onward
curl -vI --resolve domain1.com:443:YOUR_IP https://domain1.com 2>&1 | grep -E "subject|issuer|SSL"
curl -vI --resolve domain2.com:443:YOUR_IP https://domain2.com 2>&1 | grep -E "subject|issuer|SSL"

Method 3: Online Tool

SSL Labs (ssllabs.com/ssltest/) provides a detailed breakdown of the Certificate your server delivers to browsers, including whether SNI is working correctly across multiple test IPs.

SNI with Load Balancers and Reverse Proxies

In more complex infrastructure — such as a load balancer in front of web servers, or Nginx acting as a reverse proxy — SNI continues to work correctly as long as it is configured at the layer that terminates the SSL connection.

Nginx Reverse Proxy with SNI

# Nginx terminates HTTPS with SNI, then forwards plain HTTP to backends
server {
    listen 443 ssl;
    server_name shop.example.com;
    ssl_certificate     /etc/ssl/shop.crt;
    ssl_certificate_key /etc/ssl/shop.key;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

server {
    listen 443 ssl;
    server_name api.example.com;
    ssl_certificate     /etc/ssl/api.crt;
    ssl_certificate_key /etc/ssl/api.key;

    location / {
        proxy_pass http://127.0.0.1:8090;
        proxy_set_header Host $host;
    }
}

Nginx reads the SNI field in the Client Hello, selects the correct Certificate, and forwards the request to the appropriate backend — all on port 443 from a single IP address. This pattern is the standard architecture for hosting multiple services, APIs, and frontends on one server.