A single web server, sitting behind a single IP address, routinely hosts dozens or hundreds of separate HTTPS websites — each with its own SSL certificate. That raises an awkward question: when a browser opens an encrypted connection to that shared IP, how does the server know which certificate to send back, before it even knows which site the visitor wants? The answer is a small but load-bearing piece of the TLS handshake called Server Name Indication, or SNI. This guide explains what SNI does, why the web couldn't scale without it, the privacy problem baked into its design, and how Encrypted Client Hello is finally fixing that problem.
In short
SNI is a TLS extension (RFC 6066) that lets a client name the hostname it wants in the first handshake message, so one IP can serve many HTTPS sites with different certificates. It's universally supported. Its catch: that hostname is sent in plaintext, so anyone on the network can see which site you're visiting even over HTTPS. Encrypted Client Hello (ECH) — the successor to ESNI — closes that gap by encrypting the whole handshake greeting using a key the site publishes in DNS.
What SNI is and why it exists
Server Name Indication is an extension to the TLS protocol, defined in RFC 6066, that adds one field to the client's opening message: the hostname it intends to reach. When your browser connects to https://www.example.com, it includes www.example.com in that first packet — the ClientHello — so the server on the other end knows which of its many sites is being requested.
To see why that field is necessary, you have to remember the sequence of events in a TLS connection. The server must present its certificate almost immediately, as one of the first things it does — long before any HTTP request, with its Host: header, is sent. But the certificate is the thing that proves the server's identity for a specific hostname. So the server faces a chicken-and-egg problem: it needs to choose a certificate for the right site, but the only clue about which site the visitor wants — the HTTP Host header — arrives later, inside the encrypted channel the certificate is supposed to establish. SNI breaks the deadlock by moving the hostname up front, into the unencrypted handshake, where the server can read it in time to pick the matching certificate. If you want the full picture of where this sits in the handshake, our guide on how SSL works walks through the exchange step by step.
Life before SNI: one certificate per IP
In the original TLS design there was no way to tell the server which site you wanted during the handshake, which meant a server could only present one certificate per IP address and port. For plain HTTP this was never an issue — name-based virtual hosting had worked for years using the Host header — but that header lives inside the request, which for HTTPS only exists after the encrypted channel is up. The practical consequence was stark: every HTTPS site needed its own dedicated IP address.
That was tolerable when secure sites were rare, but it became untenable as HTTPS went from a checkout-page luxury to the default for the entire web. Hosting providers cramming thousands of small sites onto shared servers simply did not have an IPv4 address to spare for each one; IPv4 exhaustion made dedicated-IP-per-site an expensive dead end. SNI is the fix that let HTTPS scale the same way HTTP already had — many secure sites sharing one IP — and it's a large part of why universal HTTPS became economically realistic at all.
Why this still matters to you: if your site lives on shared hosting, a reseller plan, or behind a CDN, it is almost certainly sharing its IP with many other sites and relying on SNI to be served correctly. That's completely normal and secure. It's also why a visitor on a genuinely ancient client that can't speak SNI might land on the wrong site's certificate — a scenario we cover under troubleshooting below.
How SNI works in the handshake
Mechanically, SNI is a single extension carried inside the ClientHello — the first message the client sends to begin a TLS connection. Here's the sequence:
- Client opens the connection. The browser sends a ClientHello and includes a
server_nameextension containing the hostname it wants — for instanceshop.example.com. Crucially, this happens before any keys are agreed, so the field is unencrypted. - Server reads the name and selects a certificate. The server looks up which virtual host matches that hostname and chooses the corresponding certificate and private key — picking the right one out of potentially hundreds configured on the same IP.
- Server responds with the matching certificate. It sends its ServerHello and the chosen certificate chain, and the handshake proceeds normally from there to establish the encrypted session.
- The encrypted request follows. Only now, inside the secure channel, does the browser send the actual HTTP request with its Host header — which by design should match the SNI hostname it advertised earlier.
One detail worth knowing: even in TLS 1.3, which encrypts far more of the handshake than TLS 1.2 did — including the server's certificate — the SNI field in the ClientHello stays in the clear. TLS 1.3 closed many metadata leaks but not this one, precisely because the server needs to read the name before it can set up encryption. Plugging that last gap is a separate effort, and it's where ECH comes in later in this guide.
SNI vs multi-domain and wildcard certificates
SNI gets confused with multi-domain and wildcard certificates because all three deal with "serving more than one name." But they operate at different layers, and seeing the distinction clears up a lot of purchasing decisions.
| Mechanism | What it does |
|---|---|
| SNI | A handshake feature that lets one server present different certificates for different hostnames on a single IP. It's about routing the connection to the right certificate — not about what's inside any certificate. |
| Multi-domain (SAN) | A single certificate that lists many hostnames in its Subject Alternative Name field, securing several distinct domains at once. |
| Wildcard | A single certificate that covers every direct subdomain of one domain, such as *.example.com. |
The practical rule: SNI decides which certificate to send; SAN and wildcard decide what a certificate covers. If every site on your server has its own separate certificate, SNI is what keeps them apart at connection time. If you'd rather cover several names with a single certificate, that's a job for a multi-domain certificate or a wildcard certificate. They aren't competitors — a server commonly uses SNI to route to a virtual host that is itself secured by a SAN or wildcard certificate. If you're unsure which certificate shape fits your setup, our step-by-step chooser walks through it.
The privacy hole: SNI travels in plaintext
SNI solved a real scaling problem, but it created a privacy one. Because the hostname has to reach the server before encryption is established, it is sent in the clear. The page you load is encrypted; the name of the site you're loading is not. Anyone positioned to watch your traffic — your ISP, the operator of a public Wi-Fi network, a corporate middlebox, a national firewall — can read the SNI field and learn exactly which sites you visit, even though they can't see a single byte of the actual content.
What HTTPS still reveals
It's a common misconception that HTTPS hides where you go. It hides the contents of your conversation, but the destination hostname has historically leaked twice over: once in the plaintext SNI field of the TLS handshake, and once in DNS lookups (unless you use encrypted DNS). This is why SNI became a favorite hook for network filtering and censorship — blocking by hostname is trivial when the hostname is sitting in plaintext in the very first packet.
For most everyday browsing this gap is more a privacy concern than an immediate security threat — the encryption protecting your data is unaffected. But for people under censorship or surveillance, a plaintext hostname is the difference between "they know you used the internet" and "they know precisely which sites you read." Closing it required encrypting the handshake greeting itself, which is exactly what the next two iterations set out to do.
From ESNI to Encrypted Client Hello
The first attempt to plug the leak, around 2018, was Encrypted SNI (ESNI). The idea was direct: encrypt just the SNI field so eavesdroppers couldn't read the hostname. It was deployed experimentally — Cloudflare and Firefox among the early adopters — but analysis soon showed that encrypting only one field wasn't enough. Other parts of the ClientHello still leaked enough information to fingerprint the destination, and the design had practical and security shortcomings. ESNI was a promising prototype that proved the concept needed to go further.
In 2020 the work was reworked into Encrypted Client Hello (ECH), which takes the more thorough approach of encrypting the entire ClientHello rather than one field. The mechanism, in outline:
- The site publishes an ECH key in DNS. A website (typically via its CDN) advertises a public ECH configuration in a DNS
HTTPSresource record, so clients can fetch it ahead of connecting. - The client encrypts its real ClientHello. Using that key, the browser encrypts the sensitive inner ClientHello — including the true SNI — and wraps it inside an outer ClientHello that names only a generic, shared "public" hostname.
- An eavesdropper sees only the cover name. A passive observer reads the outer hostname, which on a large CDN is shared by thousands of sites, so it reveals little. Only the server holding the matching private key can decrypt the inner hello and learn the real destination.
ECH leans on shared infrastructure to work: its privacy comes from many sites hiding behind one cover identity on the same servers and IPs. It also depends on private DNS — fetching the ECH key over an unencrypted lookup would just move the leak — so it's designed to be used alongside DNS over HTTPS. ECH builds directly on the encrypted-handshake foundations of TLS 1.3, and it's the privacy piece TLS 1.3 itself left unfinished.
Browser and server support today
SNI — universal
SNI support is effectively total. Every current browser, operating system, and TLS library sends it, and has for many years. The only clients that ever lacked it were Internet Explorer on Windows XP and a handful of very old mobile platforms — all long past end of life. For practical purposes you can assume every real visitor speaks SNI.
ECH — growing, but still emerging
Encrypted Client Hello is supported in current versions of the major browsers — Firefox enabled it by default starting with version 119, and Chrome, Edge, and Safari support it as well — but it only activates when both the website publishes an ECH configuration in DNS and the user has encrypted DNS available. On the server side, large CDNs such as Cloudflare offer ECH, while self-hosted support is still maturing. ECH also remains an IETF draft rather than a finalized standard, so expect continued refinement. The upshot: ECH is real and deployed at scale through CDNs, but it isn't yet something every site turns on by flipping a single switch.
Note too that managed environments often disable ECH (and DNS over HTTPS) on purpose, because both reduce the visibility that corporate security tooling relies on. That tension — privacy for users versus inspection for network operators — is part of why ECH rollout has been gradual rather than instant.
Common SNI problems
Because SNI is so universally supported, problems with it are almost always a server-side misconfiguration rather than a client that can't speak it. The usual suspects:
- Wrong default certificate served. When a request arrives without a recognized SNI hostname — or for a name the server has no virtual host for — the server falls back to its default site's certificate, producing a name-mismatch error. The fix is to make sure every hostname you serve has a properly configured virtual host with the right certificate. This is one of several causes behind the broader family of SSL certificate errors.
- Testing tools that omit SNI. Some command-line checks won't send SNI unless told to, so they appear to get the "wrong" certificate. With OpenSSL, pass the hostname explicitly:
openssl s_client -connect example.com:443 -servername example.com. Our OpenSSL cheat sheet covers more of these diagnostic commands. - Reverse proxies and load balancers stripping SNI. When TLS is terminated at a proxy or balancer and re-originated to a backend, the SNI value has to be passed through or set correctly, or the backend serves the wrong certificate. Check your proxy's SNI / host-passing configuration if backends behind it misbehave.
What this means for you
For most site owners, SNI is something that simply works in the background. A few practical takeaways:
- You don't need a dedicated IP for HTTPS. SNI means many secure sites can share one IP, which is why shared hosting and CDNs work. Don't pay for a dedicated IP on the assumption that SSL requires one — it hasn't for a long time.
- Choose the certificate shape, not the routing. SNI handles routing for you. Your real decision is what each certificate should cover — a single name, several names via a SAN certificate, or all subdomains via a wildcard.
- Remember the hostname is visible — unless you use ECH. Standard HTTPS hides your data but not the site name. If hostname privacy matters for your audience, serving behind a CDN that supports ECH, paired with encrypted DNS, is the current way to close that gap.
- If a certificate looks "wrong," suspect virtual-host config first. SNI itself rarely fails; a missing or mismatched default site almost always does. Verify with an explicit-SNI test before assuming the certificate is bad.
SNI is one of those quiet pieces of plumbing that made the modern, HTTPS-everywhere web possible — and ECH is the overdue patch to the one corner it left exposed. If you want to go a layer deeper into the handshake SNI rides on, start with how SSL works and TLS 1.3.