SNI: Browser Support, How It Works, Limitations

What is SNI?

SNI is an extension to the Transport Layer Security (TLS) protocol that lets a client include the destination hostname inside the very first ClientHello message. It is defined by the IETF in RFC 6066, section 3, and lets a single IP address host many HTTPS sites with separate certificates.

Which browsers does SNI support?

SNI is universally supported in modern browsers. Every desktop and mobile browser shipped in the last decade enables it by default, and only Internet Explorer on Windows XP and the stock Android Browser before Android 3.0 never added it.

How does SNI work in the TLS handshake?

SNI piggybacks on the TLS ClientHello, the first message a client sends after the TCP or QUIC connection opens. Without SNI, the server has only the destination IP address to decide which certificate to present, so a single IP serving many HTTPS hostnames cannot match a domain to its certificate.

• Client opens the transport: The browser connects on TCP port 443, or on UDP port 443 with QUIC, and prepares a TLS handshake against the destination IP address.
• ClientHello carries the hostname: The browser writes a server_name extension into the ClientHello with the hostname it intends to reach. On TLS 1.2 and earlier the value travels in plain text; on TLS 1.3 with ECH it can be encrypted.
• Server selects the certificate: The server reads the server_name value, picks the matching certificate from its virtual host configuration, and sends a ServerHello with that certificate chain.
• TLS finishes normally: The client validates the certificate against the hostname it sent. The rest of the handshake completes, and HTTP traffic flows over the encrypted connection.

The same mechanism powers HTTP/2 and HTTP/3. QUIC reuses the TLS 1.3 ClientHello format, so the server_name extension travels in the QUIC Initial packet on HTTP/3 the same way it travels in a TCP segment on HTTP/2.

What are the known issues with SNI?

SNI is universal in modern browsers, but the design has real gaps that show up on legacy systems and on networks that inspect TLS metadata.

• Internet Explorer on Windows XP never works: IE 6, IE 7, and IE 8 on Windows XP do not support SNI in any patch level. A site that requires SNI returns the wrong certificate or a name mismatch error to those users, and many enterprises still ship locked-down XP clients for legacy line-of-business apps.
• Old Android default browser is out: Android 2.3 (Gingerbread) and earlier ship a default browser that cannot send the server_name extension. Chrome for Android replaces the stock browser on Android 4.4 and later, so the gap only matters for very old devices.
• Plain-text hostname leaks the destination: SNI on TLS 1.2 sends the hostname in clear text. Network operators, internet service providers, and middleboxes can read the server_name field and log or block the destination, even though the rest of the handshake is encrypted.
• ECH adoption is uneven: Encrypted Client Hello (ECH) hides the SNI value, but it is only enabled by default in Firefox 119 and later and Chrome 117 and later, and only when the destination publishes the right HTTPS DNS record. Safari has not enabled ECH by default in any shipping version.
• Some HTTP clients still skip SNI: Older curl builds, Java 7, and the default browser on KaiOS feature phones can omit the server_name extension. Test outside the browser too if your service supports those clients.
• In my experience: the SNI bug that bites the longest is not Windows XP. It is a corporate proxy that strips the server_name extension to enforce category-based blocking, leaving the user with a generic certificate and a name mismatch they cannot debug. Always verify that server_name reaches the origin from inside customer networks, not just from a public network.

How do you check if a browser supports SNI?

The fastest check is a public test page that requires SNI. If the page loads without a certificate warning, the browser sent the server_name extension. For deeper checks, DevTools and OpenSSL each show what the client put on the wire.

• Open an SNI test page: Visit https://sni.velox.ch in your browser. The site hosts many domains on one IP and serves a unique certificate per hostname. A clean page load proves the browser sent server_name with the correct value.
• Check the DevTools Security panel: In Chrome, Edge, or Firefox, press F12 to open DevTools and click the Security tab. Reload the page. The Certificate section confirms the certificate the server returned, which should match the URL you visited.
• Run an OpenSSL probe from the terminal: Use openssl s_client with and without the -servername flag against the same IP. If the second run returns a different default certificate, the server is selecting on SNI and the first run sent the extension.
• Confirm with the user agent baseline: SNI is on by default for every browser shipped in the last decade. If the user agent reports Chrome 6+, Edge 12+, Firefox 2+, Safari 2.1+, or Opera 9+, the browser sends server_name on every HTTPS connection.

The OpenSSL command for step 3 looks like this. Run it from any machine with the openssl binary installed.

# Probe a server with the server_name extension using OpenSSL.
# A successful run prints the certificate the server selected for that hostname.

openssl s_client -connect example.com:443 -servername example.com -tls1_2 < /dev/null

# Drop the -servername flag and re-run on the same IP.
# If the second run returns a different default certificate,
# the server is using SNI and your client sent server_name correctly.

openssl s_client -connect example.com:443 -tls1_2 < /dev/null

If both runs return the same certificate, the host is on its own IP and SNI is not in play. If the runs differ, the server is virtual hosting and the client must keep sending server_name.

Citations

All SNI version numbers and platform notes in this guide come from these primary sources:

• IETF RFC 6066 (TLS Extensions, SNI): datatracker.ietf.org/doc/html/rfc6066
• IETF RFC 8446 (TLS 1.3): datatracker.ietf.org/doc/html/rfc8446
• IETF RFC 3546 (original TLS Extensions): datatracker.ietf.org/doc/html/rfc3546
• IETF RFC 9000 (QUIC transport): datatracker.ietf.org/doc/html/rfc9000
• Wikipedia Server Name Indication: en.wikipedia.org/wiki/Server_Name_Indication
• MDN Transport Layer Security: developer.mozilla.org/en-US/docs/Web/Security/Transport_Layer_Security
• Microsoft Learn IIS 8 Server Name Indication: learn.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-server-name-indication-sni-ssl-scalability
• DigiCert SNI Browser Support Knowledge Base: knowledge.digicert.com/general-information/desktop-mobile-browsers-that-support-sni
• HTTPS-Only Standard, CIO.gov, Server Name Indication: https.cio.gov/sni
• Mozilla blog, Encrypted Client Hello in Firefox: blog.mozilla.org/security/2023/10/16/encrypted-client-hello-the-future-of-esni-in-firefox