Server Name Indication

A commerce platform hosts storefronts on 200,000 merchant-owned domains, each needing its own certificate, all arriving at one edge address. Before this extension, a server had to choose a certificate before it knew which name the client wanted, so each certificate needed its own IP address. At the roughly $0.005 per public IPv4 address per hour that major clouds introduced in 2024, about $3.60 a month each, 200,000 addresses is over $8 million a year in addresses alone.

Server Name Indication (RFC 6066, 2011) puts the requested hostname in the ClientHello, the first TLS message, in cleartext. The server reads the name, selects the matching certificate and completes the handshake. One address, any number of certificates.

Because the name sits in the first packet unencrypted, it doubles as a routing primitive. A layer-4 proxy can read the SNI and forward the whole TLS session to the right tenant or region without holding a private key and without seeing plaintext, which is what makes per-tenant key custody and regional residency workable at an edge.

Why it matters

Three separate things rest on this one field: the economics of multi-tenant TLS, the ability to route encrypted traffic without terminating it, and the privacy exposure of announcing your destination in cleartext on every connection. Any decision about where TLS terminates touches at least one of them, and it is also the most common cause of certificate errors that affect only a subset of clients.

Implementation patterns

• Deterministic certificate selection: exact match, then wildcard, then default. Keep the default certificate as a diagnostic, not as a fallback that quietly serves the wrong name.
• Require SNI and fail closed with a distinct error, because a handshake completed with the wrong certificate becomes a warning the user may click through.
• Route on SNI at layer 4, authorise on the Host header at layer 7. The two can disagree and only the second belongs to the request.
• On-demand issuance for custom domains, keyed by the SNI of the first request, guarded by an allow-list of names that already resolve to your edge and a rate limit, since issuance quota is shared. Scope session tickets per hostname too, so resumption cannot cross tenants.
• Encrypted Client Hello where the hostname must be hidden: the real name is encrypted inside an outer public name, with keys published in DNS beside HTTPS and SVCB records (RFC 9460, 2023). Client support is still uneven.

Industry example

A platform issuing certificates for hundreds of thousands of customer domains runs this as a pipeline rather than a feature: a domain is validated, a certificate is issued, and it is distributed to every terminating node, where an in-memory map turns an incoming SNI into a certificate in microseconds. The binding constraint is distribution rather than cryptography, because every node needs every certificate it might be asked for, and with the 47-day public certificate lifetime arriving in 2029 a 200,000-domain estate renewing at two thirds of life turns over roughly 6,000 certificates a day.

Failure scenarios

• A client that sends no SNI - old stacks, embedded devices, anything connecting to an IP with the hostname only in the Host header - gets the default certificate, so that subset sees a name mismatch while every browser works.
• HTTP/2 connection coalescing. A client may reuse one connection for a second hostname when one certificate covers both names and they resolve to the same address, so requests for domain B arrive on a connection whose SNI said domain A, and a layer-4 router keyed on SNI delivers them to the wrong backend.
• SNI and Host disagreeing deliberately. A firewall that permits traffic on SNI while the server answers on Host is an access-control bypass, which is the mechanism behind domain fronting.
• A wildcard chosen over an exact match, serving a tenant a valid certificate that is not theirs, which breaks pinning and confuses audits; and cleartext SNI used against you as a blocking signal on the path.

Trade-offs

When not to use it

Do not route on SNI when the decision needs anything from the request, such as a path, header or token: terminate and route at layer 7 and accept the key custody that comes with it. Do not rely on SNI for a client population you do not control if part of it predates widespread support; give those clients a dedicated address, and measure its traffic before withdrawing it. And never treat SNI as a security control, because the client chooses its value freely.

Decision rule: SNI decides which certificate and which backend; the Host header decides what the request may do. Do not collapse the two.

Interview question

Q: You terminate TLS for 200,000 customer domains at a shared edge and route sessions on SNI without decrypting. A customer reports that a small fraction of requests for their domain reach another customer's backend. How is that possible, and how would you fix it without giving up layer-4 routing?

What a strong answer covers: HTTP/2 connection coalescing, where a client reuses a connection whose SNI named a different host because one certificate covered both names and the addresses matched; that SNI is a property of the connection while the authority is a property of the request, so routing on one and serving on the other is unsound; the fix, a layer-7 check of the :authority header against the connection's routing decision, with mismatches rejected rather than re-routed; and avoiding certificates that span tenants so coalescing cannot apply.

Quick check

Quiz: Why can a layer-4 proxy route a TLS session with no private key? The hostname travels in the cleartext ClientHello, so the proxy reads the destination before encryption is established and forwards the session untouched. ECH removes that ability by design.

Flashcard: One edge address serves 200,000 domains. Which field makes that possible, and which failure does it create? — The SNI extension in the ClientHello; clients that send no SNI get the default certificate and a name mismatch, so the error hits only part of the client population.