SNI explained: many SSL certificates on one IP address

Thousands of HTTPS sites can share a single IP address, each with its own certificate, thanks to SNI (Server Name Indication). Before SNI, every HTTPS site needed a dedicated IP. Understanding SNI explains why the wrong certificate sometimes appears and why a dedicated IP is no longer required for SSL.

Before you start

• Basic idea of TLS certificates: SSL certificate types.
• openssl or curl for testing.

The problem SNI solves

With plain HTTP, the server reads the Host header to choose the site. With HTTPS, the TLS handshake happens before any HTTP is sent, and the server must present a certificate during that handshake. Without extra information it cannot know which domain the visitor wants, so historically it could serve only one certificate per IP and port.

How SNI works

1. The browser opens a connection to the IP on port 443.
2. In its first TLS message (ClientHello) it includes the hostname, e.g. shop.example.com, in the SNI extension.
3. The server looks up the virtual host for that name and replies with its certificate.
4. The handshake completes, and the HTTP request (with the same Host header) follows.

Every modern browser, operating system, programming language library and command-line tool supports SNI. Only very old clients (Internet Explorer on Windows XP, Android 2.x) lacked it.

How web servers use SNI

On MdmHost cPanel hosting, AutoSSL issues a certificate per domain and LiteSpeed serves the right one via SNI, all on shared IPs.

The default certificate problem

If the SNI name doesn't match any configured site, or the client sends none, the server falls back to a default certificate: the first or default_server site in Nginx, the first vhost in Apache. Visitors then see a name-mismatch warning. Common causes:

• DNS for a domain points at the server but no HTTPS vhost exists for it.
• A new alias (www) wasn't added to the vhost or certificate.
• Visiting the server by IP address, which sends no SNI.

In Nginx you can refuse handshakes for unknown names instead of showing a wrong certificate:

server {
    listen 443 ssl default_server;
    ssl_reject_handshake on;
}

Test SNI

1. Ask for a specific name and show the certificate's subject and SANs:
   Copy

   openssl s_client -connect 203.0.113.5:443 -servername shop.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName

2. Compare with no SNI (shows the default certificate):
   Copy

   openssl s_client -connect 203.0.113.5:443 -noservername </dev/null 2>/dev/null | openssl x509 -noout -subject

3. Test a site before DNS points to the server:
   Copy

   curl -sI --resolve shop.example.com:443:203.0.113.5 https://shop.example.com/

SNI and privacy

Classic SNI is sent unencrypted, so network observers can see which hostname you visit (but not the URL path or content). Encrypted Client Hello (ECH) encrypts it; support is rolling out in browsers and CDNs and relies on the HTTPS DNS record (HTTPS and SVCB records).

Do you still need a dedicated IP?

Not for SSL. Reasons for a dedicated IP today are other: IP-based allow-lists at partners, running services by IP, or separating email reputation. MdmHost's top VIP Master Reseller plan includes a dedicated IP for such needs.

Troubleshooting

• Wrong certificate for one domain: its vhost has no SSL configured, so the default answered. Check the vhost and that the certificate covers that exact name.
• Works in browsers, fails in an old script: the client doesn't send SNI. Update the library or tool.
• Monitoring tool reports wrong certificate: it's checking by IP; configure it to use the hostname.

FAQ: SNI

Does SNI slow down HTTPS?

No. It's a few bytes in the first message.

Can SNI work with wildcard and SAN certificates?

Yes. SNI picks the vhost; the certificate can cover many names.

Is SNI required for HTTP/2 and HTTP/3?

Browsers always send it, and servers rely on it to select certificates.

Next steps

• Wildcard vs SAN certificates
• TLS termination explained
• Fix SSL certificate verify failed