SNI (Server Name Indication)

Server Name Indication is the server_name extension defined in RFC 6066. The client puts the DNS hostname it wants in the ClientHello, before any certificate is exchanged, and the server uses that name to pick the matching certificate and virtual host. RFC 6066 allows only DNS names in this field; literal IP addresses are not permitted.

Why it matters

Without SNI, a server learns the hostname only after the handshake, from the HTTP Host header, so it can present just one certificate per IP address and port. SNI is what makes shared hosting, CDNs and load balancers with thousands of HTTPS sites on one IP possible. If a client omits SNI or sends a name the server does not know, the server falls back to its default certificate, which usually surfaces as a name-mismatch error. SNI is also sent in plaintext, even in TLS 1.3, so anyone on the network path can see which hostname is requested; ECH is the standard way to hide it.

Example

Ask one IP address for a specific virtual host; -servername sets the SNI value:

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

Run it again without -servername. If a different certificate comes back, the server is choosing certificates by SNI and the second one is its default.

Common misconceptions

• Every HTTPS site needs its own IP address. That was true before SNI. All mainstream browsers and HTTP clients send SNI today, so many certificates can share one IP.
• TLS 1.3 encrypts the SNI. It does not. TLS 1.3 encrypts the server certificate but leaves SNI in the clear; hiding it requires ECH.
• SNI and the certificate's SAN are the same thing. SNI is the name the client asks for; the SAN list is what the certificate covers. The connection is valid only if the requested name matches a SAN entry.