Server Name Indication (SNI)
SNI lets a TLS client send the target hostname in the handshake, so one IP address can serve many HTTPS sites with different certificates before the request is decrypted.
Definition
Server Name Indication is an extension to the TLS handshake in which the client states the hostname it intends to reach, allowing the server to select the matching certificate before any HTTP data is exchanged.
Context and scope
It is the reason shared hosting and large content platforms can terminate thousands of HTTPS domains on a small pool of IP addresses.
Common misconceptions
- SNI encrypts or hides the hostname from observers
- a single wildcard certificate can replace SNI for unrelated domains
Anti-patterns
- relying on one IP per certificate and exhausting address space
- assuming SNI is always present when talking to legacy clients
Related concepts
Related examples
Authoritative source
Definition
Server Name Indication is an extension to the TLS handshake in which the client states the hostname it intends to reach, allowing the server to select the matching certificate before any HTTP data is exchanged.
It is the reason shared hosting and large content platforms can terminate thousands of HTTPS domains on a small pool of IP addresses. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.
When to use it
A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.
How it works
Without SNI the server must choose a certificate before it knows which site the client wants, which historically forced one dedicated IP address per HTTPS domain.
Because the hostname travels in cleartext in the ClientHello, network observers can see which site is requested even though the content stays encrypted, which motivated Encrypted Client Hello as a successor.
Trade-offs and alternatives
Servers must still define a default certificate for clients that omit SNI, and automation that provisions certificates per domain must keep the name set in sync with the SNI-selected virtual hosts. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.
Common misconceptions
A persistent misconception is that SNI encrypts or hides the hostname from observers. Another is that a single wildcard certificate can replace SNI for unrelated domains. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.
Anti-patterns to avoid
Two recurring anti-patterns are to relying on one IP per certificate and exhausting address space and to assuming SNI is always present when talking to legacy clients. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include Application-Layer Protocol Negotiation (ALPN), PROXY Protocol for Client Address Preservation, Server-Timing Metrics Header.