HTTPS, SSL & Security
What is SNI?
SNI, Server Name Indication, is a TLS extension that allows a client to specify which domain it is connecting to at the beginning of the TLS handshake, before the server has presented its SSL certificate. This allows a single server with a single IP address to host SSL certificates for multiple different domains, presenting the correct certificate for whichever domain the client is connecting to.
Without SNI a server can only present one SSL certificate per IP address. When a browser initiates a TLS handshake the server must immediately present a certificate, but without knowing which domain the browser intends to connect to the server cannot know which certificate to present if multiple domains are hosted on the same IP. The server must choose one certificate to present regardless of which domain the client actually wants, which only works if there is exactly one domain per IP address.
SNI solves this by including the target domain name, the server name, in the Client Hello message that opens the TLS handshake. The server reads the SNI value before presenting a certificate and selects the appropriate certificate for the requested domain. One IP address can serve hundreds or thousands of domains over HTTPS, each getting its own certificate, because SNI tells the server which certificate to present for each connection.
SNI is fundamental to how modern web infrastructure works. Shared hosting, CDNs, redirect management platforms, and virtually every multi-tenant HTTPS service depends on SNI to serve different certificates to different clients on shared infrastructure. Without SNI the economics of HTTPS hosting at scale would be completely different, every domain would require a dedicated IP address.
Why SNI was needed
Before SNI the relationship between IP addresses and SSL certificates was one-to-one, each domain requiring HTTPS needed its own dedicated IP address. Understanding why this limitation existed clarifies what SNI actually solved.
The TLS handshake ordering problem: in standard TLS the server presents its certificate before the client sends any application-layer data. The server has no information about which domain the client wants to connect to at the moment it must select a certificate. The client’s intention, which domain it wants, is communicated in the HTTP Host header, but the Host header is part of the HTTP request which comes after the TLS handshake completes. The server must choose a certificate before it knows which domain is being requested.
For a server hosting only one domain this is not a problem, there is only one certificate to present. For a server hosting example.com, example.net, and example.org the server cannot know which certificate to present when the TLS handshake begins, it must guess or present only one.
The IPv4 address scarcity problem: requiring a dedicated IP address per HTTPS domain was particularly problematic as IPv4 addresses became scarce. Every domain needing HTTPS had to consume a separate IP address, an increasingly expensive and difficult resource. Large hosting providers serving thousands of customer domains over HTTPS needed thousands of IP addresses, a significant cost and operational challenge.
Virtual hosting limitations: HTTP virtual hosting, serving multiple domains from one IP using the Host header, worked well for HTTP because the Host header is received before any domain-specific processing. For HTTPS the certificate selection had to happen before any HTTP headers were available, making virtual hosting incompatible with multi-certificate HTTPS on the same IP without SNI.
SNI as the solution: SNI resolves the ordering problem by moving the domain indication from the HTTP layer, the Host header, to the TLS layer, the Client Hello. The SNI extension in the Client Hello carries the target domain name, example.com: before the server needs to select a certificate. The server reads the SNI value and presents the certificate for the indicated domain. Virtual hosting works for HTTPS just as it does for HTTP.
How SNI works in the TLS handshake
SNI is an extension to the TLS Client Hello message, the first message sent by the client in a TLS handshake. The extension adds a server name list containing the hostname the client intends to connect to.
Client Hello with SNI: when a browser initiates an HTTPS connection to example.com it sends a Client Hello message to the server. The Client Hello includes a list of TLS extensions, including the SNI extension with the server name example.com. The TLS handshake has not yet begun cryptographic processing, the Client Hello is sent in plaintext before any encryption is established.
Server certificate selection: the server receives the Client Hello and reads the SNI extension, extracting the requested hostname example.com. The server selects the SSL certificate associated with example.com from its certificate store and uses that certificate for the TLS handshake.
If the server has no certificate for the indicated hostname it either presents a default certificate, potentially causing a certificate name mismatch error, or terminates the connection with an unrecognised_name alert. Well-configured servers handle unknown SNI values gracefully, redirect management platforms provision certificates for every connected domain to ensure the correct certificate is always available.
Handshake continuation: after selecting the certificate the server continues the TLS handshake normally, presenting the certificate, performing key exchange, and establishing the encrypted session. From the client’s perspective the handshake is identical to a non-SNI handshake, the SNI value was included in the Client Hello and the server handled it transparently.
Encrypted SNI, ESNI and ECH: a significant privacy implication of SNI is that the server name in the Client Hello is transmitted in plaintext, observable by network intermediaries even though the subsequent connection is encrypted. An ISP, a Wi-Fi operator, or a network surveillance system can see which domain a client is connecting to through the plaintext SNI value even though the actual content of the connection is encrypted.
Encrypted Client Hello, ECH, is the solution being developed and deployed by browser and CDN vendors. ECH encrypts the Client Hello, including the SNI value, using a public key published in the domain’s DNS records. Network observers see only an encrypted blob rather than the target domain name. ECH is supported by recent versions of Chrome and Firefox and by Cloudflare’s CDN infrastructure, deployment is ongoing.
SNI and redirect management
SNI is foundational infrastructure for redirect management at scale, enabling the economic and operational model that makes managed redirect services viable.
Multi-domain redirect infrastructure: a redirect management platform handles requests for potentially thousands of customer domains, each with its own SSL certificate. Running dedicated IP addresses and dedicated server instances for each customer domain would be economically impractical. SNI enables shared infrastructure, one server cluster with a pool of IP addresses handles all customer domains, presenting the correct SSL certificate for each domain using the SNI value to identify which certificate is needed.
When a visitor makes an HTTPS request to a domain connected to a redirect management platform the TLS handshake includes the SNI extension with the customer’s domain name. The redirect platform reads the SNI value, retrieves the appropriate SSL certificate for that domain, completes the TLS handshake, receives the decrypted HTTP request including the Host header, and applies the appropriate redirect rules for the domain.
Certificate selection pipeline: redirect management infrastructure maintains a certificate store with certificates for every connected domain. The SNI value from incoming connections is used to look up the appropriate certificate, the process must be fast enough to handle thousands of concurrent connections. Certificate stores are typically cached in memory for performance, loading certificates from disk or a database for every TLS handshake would be too slow.
Wildcard certificates and SNI: wildcard SSL certificates reduce the number of certificates needed in a redirect management platform’s certificate store. A wildcard certificate for *.customer-domain.com covers all subdomains of that domain, SNI values for any subdomain of customer-domain.com can be served with the same certificate. This reduces certificate management complexity for platforms serving many subdomains of each customer domain.
HTTPS connection failure without matching certificate: when a client sends an SNI value for which the server has no certificate the server cannot complete the TLS handshake correctly. The client receives a certificate error, ERR_SSL_UNRECOGNIZED_NAME_ALERT in Chrome, or a certificate mismatch error. For redirect management platforms this occurs when a domain is connected to the platform, DNS records updated to point to the platform, but no certificate has yet been provisioned for the domain.
Redirect management platforms address this by provisioning certificates before or immediately upon domain connection, typically using Let’s Encrypt ACME automation triggered when the platform detects DNS pointing to its infrastructure. The window between DNS connection and certificate provisioning during which HTTPS fails should be minimised.
SNI and shared hosting
SNI transformed shared web hosting, enabling modern shared hosting economics by allowing thousands of customer domains to share HTTPS infrastructure.
Pre-SNI shared hosting limitations: before SNI shared hosting providers faced a dilemma. Hosting many customers on shared infrastructure was economically attractive, one server serving many websites. HTTP virtual hosting worked well, customers shared an IP address and the Host header identified which site to serve. But HTTPS required dedicated IP addresses per domain, dramatically increasing the cost and complexity of providing HTTPS to shared hosting customers.
Many shared hosting providers either did not support HTTPS at all or charged significant premiums for SSL-capable hosting that required dedicated IP address allocation.
Post-SNI shared hosting: SNI enabled shared hosting providers to serve HTTPS for thousands of customer domains from a single IP address pool, the same economics as HTTP virtual hosting. Let’s Encrypt combined with SNI made free automatic HTTPS on shared hosting practical, providers could provision free certificates for all customer domains automatically without IP address constraints.
Modern shared hosting providers offer free automatic HTTPS for all hosted domains, a service that would have been economically impractical without SNI.
SNI and CDNs
CDNs were among the first infrastructure at scale to leverage SNI, and remain the most prominent example of SNI-dependent multi-domain HTTPS infrastructure.
CDN edge SSL at scale: a CDN serves traffic for potentially millions of customer domains from shared edge infrastructure. Each edge location has a pool of IP addresses, not one per customer domain. SNI allows the CDN edge to receive connections for any customer domain, identify the requested domain from the SNI value, present the appropriate certificate, and process the request according to the customer’s configuration.
Cloudflare serves traffic for millions of domains from a relatively small pool of IP addresses per edge location, entirely enabled by SNI. Each of these millions of domains gets its own SSL certificate, provisioned automatically and stored for selection based on incoming SNI values.
Shared certificate pools: some CDNs use shared SSL certificates, certificates covering multiple customer domains as SANs, to reduce the total certificate count and simplify management. SNI identifies which domain is being requested but the certificate presented covers multiple domains. This approach trades some certificate isolation, different customers share certificate infrastructure, for reduced certificate management complexity.
Cloudflare’s Universal SSL uses a shared certificate model, customer domains on free plans share certificates with other Cloudflare customers under the sni.cloudflaressl.com domain. Paid plans receive dedicated certificates for their domains. SNI in both cases identifies the target domain and enables the correct certificate to be selected.
SNI compatibility
SNI support is required by modern browsers and clients, but very old or unusual clients may not support it.
Browser support: all modern browsers support SNI without exception. Chrome, Firefox, Safari, Edge, and all Chromium-based browsers have supported SNI for many years. SNI support in browsers is essentially universal for any browser version that could realistically be in active use today.
Operating system TLS libraries: SNI support depends on the TLS library used by the operating system or application. Modern versions of OpenSSL, SChannel, Windows, and SecureTransport, macOS and iOS, all support SNI. Legacy environments using very old TLS library versions may lack SNI support.
Legacy clients without SNI: very old operating systems, Windows XP with Internet Explorer 6, do not support SNI. Clients using these obsolete systems cannot connect to SNI-dependent HTTPS infrastructure, they receive certificate errors or connection failures. For the vast majority of web properties the proportion of visitors using SNI-incompatible clients is negligible, measured in fractions of a percent if at all. Legacy clients are an irrelevant concern for new infrastructure design.
Non-browser HTTP clients: HTTP clients used in APIs, automation, and server-to-server communication vary in SNI support. Modern HTTP client libraries, libcurl, Python requests, Go’s net/http, all support SNI. Older or minimal HTTP clients may not. When integrating with third-party services that make HTTPS connections to redirect infrastructure SNI support in the client is a prerequisite for successful connection.
Checking SNI behaviour
Verifying that SNI is working correctly, the server presents the appropriate certificate for a requested domain, is achievable with standard tools.
OpenSSL SNI test: testing that a specific domain gets the correct certificate using OpenSSL with the -servername flag to specify the SNI value:
This command connects to the IP address 203.0.113.42: the shared server, with the SNI value example.com. The certificate presented in the response should be valid for example.com. Changing the -servername to a different domain hosted on the same IP should return a different certificate, confirming SNI-based certificate selection is working.
curl SNI test:
The --resolve flag sends the request to the specified IP address while setting the SNI and Host header to example.com: simulating a DNS-resolved connection with explicit certificate verification.
Browser developer tools: the Security tab in browser developer tools shows the certificate served for the current connection, confirming the correct certificate was selected based on the SNI value of the connection.