Server Name Indication (SNI): Use Multiple SSL Certificates on One IP

Understanding Server Name Indication for Multi-Domain SSL Hosting

As HTTPS became the standard for secure web communication, a new challenge emerged: how do you host multiple SSL-secured websites on a single IP address?

In the early days of HTTPS, each secure domain required its own dedicated IP, because servers couldn’t tell which SSL certificate to serve during the handshake. With only 4 billion IPv4 addresses available worldwide, hosting providers needed a way to serve multiple secure websites from a single IP.

Enter Server Name Indication, that solved this limitation. Before SNI emerged in 2003, each website requiring HTTPS needed its own dedicated IP address. Let’s learn more about it.

What Is Server Name Indication (SNI)?

Server Name Indication is a feature in the TLS protocol that allows a browser to tell the server which hostname it’s trying to connect to, right at the start of the handshake. This may sound like a small thing, but it makes a big difference as it allows one server with one IP address to serve multiple SSL certificates for different domains.

Before SNI, this wasn’t possible. If a server hosted multiple domains, it could only present a single certificate during the SSL/TLS handshake. That meant either using a wildcard or a SAN certificate or assigning a dedicated IP to each domain.

SNI has completely transformed that, and now browsers include the target hostname in the Client Hello message to give the server the information it needs for presenting the right certificate during the SSL connection process.

How SNI Works in HTTPS Connections

The first step for a browser trying to connect to a secure website is the Client Hello message. This message initiates the TLS handshake by telling the server, “I want to start a secure session”. Earlier, this handshake did not mention which domain it was trying to reach. The server had to respond with a certificate without knowing which one was appropriate if multiple sites were hosted on the same IP.

With SNI, the browser includes the intended hostname right inside the Client Hello message. This minor change made it possible for the server to return the right SSL certificate for the requested domain. So, the server could be assured enough to present the proper certificate rather than going back to a default certificate or mismatched one.

The following diagram below shows how server uses SNI to select the appropriate certificate for requested domain during the handshake procedure.

In practice, it changes in milliseconds, but it is what enables shared infrastructure, such as the use of virtual hosts, CDNs, and reverse proxies, to support HTTPS correctly, despite serving a large number of domains behind a single IP address.

Why SNI Matters for Hosting Multiple SSL Certificates on One IP

Before SNI, if you wanted to host multiple HTTPS-enabled domains, each one needed its IP address. That wasn’t just inconvenient, but it was also expensive and unsustainable, especially with the growing shortage of IPv4 addresses.

Now, a single server with one IP can serve the correct SSL certificate for each domain it hosts. Many industries use SNI for their core business, such as:

1. Shared hosting providers often run hundreds or thousands of domains on a single machine.
2. CDNs need to dynamically serve SSL for many customer domains across a distributed network.
3. Organizations, like SaaS companies or e-commerce platforms, manage multiple brand domains or subdomains under one infrastructure.

By removing the need for a dedicated IP per site, SNI significantly reduces infrastructure costs and IP consumption. It also simplifies scaling; you can spin up new secure domains without reconfiguring your network or requesting more IPs.

Providers like GoDaddy or Shopify rely heavily on SNI to host millions of domains securely. Without it, mass HTTPS adoption at scale wouldn’t be feasible or affordable.

SNI vs SAN Certificates: Which Is Better for Hosting Multiple Domains?

When it comes to hosting multiple HTTPS-enabled domains, SNI and SAN certificates are two of the most common approaches. They both solve the same problem of enabling secure connections across multiple domains but in very different ways.

SNI (Server Name Indication) allows a server to use multiple SSL certificates on one IP address. It’s flexible, and each domain can have its certificate, and it scales well for setups where domains are added or removed often.

SAN (Subject Alternative Name) certificates, often called multi-domain certificates, allow a single certificate to cover multiple domains (e.g., example.com, blog.example.com, anotherdomain.com).

Use SNI if you want flexibility, per-domain control or if you’re hosting many unrelated sites.

Use SAN certificates if your domains are tightly coupled (e.g., product sites under one brand) or if you need to support older browsers or legacy devices.

In most modern setups, SNI is preferred and paired with automation tools which can issue and renew certificates per domain.

Limitations and Security Concerns of SNI

While SNI solves a major problem in HTTPS hosting, it’s not without a few limitations, especially when it comes to compatibility and privacy.

1. Older Browsers and Operating Systems

   SNI isn’t supported by some legacy systems. For example:

   1. Internet Explorer on Windows XP (without Service Pack 3)
   2. Android 2.x and below
   3. Some very old Java clients or embedded devices

   Here, the browser or client does not send the hostname during the TLS handshake process. Thus, the server doesn’t know which certificate to present. If a connection is attempted to establish a connection from such legacy systems, the server may revert to a default certificate or terminate the connection.

2. Certificate Mismatch Risks

   If a client does not support SNI and if any fallback certificate is used, then it might not match the requested domain. This will directly result in an HTTPS warning, “Your connection is not private” which will instantly erode user trust.

3. Hostnames Are Not Encrypted

   The major security issue with SNI is that it sends hostnames as plaintext during the TLS handshake. This resulted in hostnames being visible to ISPs and attackers on the public network. Even though the traffic was encrypted after the handshake completion, the connection establishment process had weak security.

To address this, Encrypted SNI (ESNI) was introduced as part of TLS 1.3 and is evolving into Encrypted Client Hello (ECH). These efforts aim to keep even the initial hostname private.

SNI is still widely used and effective, but knowing where it falls short helps in designing around its limitations, especially when privacy or backward compatibility is critical.

SNI Compatibility: What Site Owners Need to Know

SNI is supported almost everywhere today. Unless you’re targeting users on outdated systems, you’re in the clear.

Unless and until you are dealing with a legacy enterprise system or an obscure IoT device, SNI is widely supported, and most developers can enable it and move on without worrying about compatibility.

How to Enable SNI on Your Web Server

Enabling SNI is usually just a matter of configuring your web server correctly. There are no special licenses or extra costs involved, as it’s supported by default in most modern setups.

Apache

In Apache (with mod_ssl enabled), SNI is handled automatically when you configure name-based virtual hosts with different SSL certificates.

<VirtualHost *:443>
ServerName example.com
SSLEngine on
SSLCertificateFile /path/to/example.crt
SSLCertificateKeyFile /path/to/example.key
</VirtualHost>

<VirtualHost *:443>
ServerName blog.example.com
SSLEngine on
SSLCertificateFile /path/to/blog.crt
SSLCertificateKeyFile /path/to/blog.key
</VirtualHost>

Nginx

In Nginx, the concept is similar. Use multiple server blocks with their own server_name and certificate:

server {
listen 443 ssl;
server_name example.com;

ssl_certificate /etc/ssl/example.crt;
ssl_certificate_key /etc/ssl/example.key;
}

server {
listen 443 ssl;
server_name blog.example.com;

ssl_certificate /etc/ssl/blog.crt;
ssl_certificate_key /etc/ssl/blog.key;
}

As long as your Nginx version supports TLS (most do), SNI is automatically used to choose the correct cert.

SNI also supports most modern load balancers and CDNs, which include AWS Application Load Balancer, Cloudflare, Fastly, Akamai and reverse proxies like HAProxy and Envoy. In such environments, enabling SNI involves uploading your SSL certificates and mapping them to the appropriate hostnames. The platform takes care of selecting the right certificate during the TLS handshake after successful configuration.

Conclusion

Server Name Indication might not be something most users ever think about, but it plays a crucial role in how the modern web works. We looked at how SNI makes it possible for multiple secure websites to share the same IP address. This was something that wasn’t feasible in the early days of HTTPS when each secure site needed its dedicated IP.

SNI changed that by letting the browser tell the server which domain it is trying to reach during the TLS handshake. This small change had a big impact on companies that manage hundreds or even millions of domains – CDNs, web hosting providers, or big platforms like GoDaddy. Without SNI, they’d need an impossible number of IPs to make HTTPS work at scale.

• What Is a SAN SSL Certificate and How Does It Secure Multiple Websites?
• Wildcard SSL vs Multi-Domain (SAN) SSL Certificate – Differences Explained
• SSL Certificates for Subdomains: Choose the Right SSL Certificate for Your Subdomain