SNI misconfigurations happen on servers hosting multiple sites or domains on a single IP address, where the server incorrectly matches an incoming request's hostname to the wrong certificate — resulting in a visitor seeing a certificate valid for an entirely different domain than the one they're actually visiting.
How SNI is supposed to work
During the TLS handshake, before encryption is established, the client includes the hostname it's trying to reach in the SNI field of its ClientHello message — the server then uses this to select the correct certificate from among several installed, before completing the handshake. When this matching logic is misconfigured, the server can end up presenting the wrong certificate, or fall back to an unintended default.
Common causes on Nginx
- Multiple
serverblocks with overlapping or ambiguousserver_namedirectives, where Nginx's own matching precedence rules don't select the block you expected - A newly added domain missing its own dedicated server block entirely, causing requests for it to fall through to whichever block Nginx treats as the default
- The default server block (marked with
default_server) unintentionally configured with the wrong certificate, catching any hostname that doesn't explicitly match another block
Common causes on Apache
Similarly, Apache selects a VirtualHost based on the requested hostname among those bound to the same IP/port — an incorrectly ordered or incomplete ServerName/ServerAlias configuration across VirtualHosts can cause the same category of mismatch, with Apache's own VirtualHost matching precedence rules determining which block in fact wins for an ambiguous or unmatched hostname.
Diagnosing which certificate is being served for a specific hostname
openssl s_client -servername specific-hostname.com -connect server-ip:443 -showcertsTesting directly against the server's IP with an explicit -servername flag for each hostname you're troubleshooting lets you confirm exactly what certificate comes back for each one individually — removing DNS as a confounding variable, since you're specifying both the IP and the intended hostname rather than relying on DNS already being correctly configured.
The fix
Review each server/VirtualHost block's hostname matching configuration explicitly, ensure every domain you intend to serve has its own correctly scoped block with the right certificate referenced, and pay particular attention to the default/catch-all block, since it's the one most likely to silently absorb requests for a domain that's missing its own explicit configuration.
The rare, genuinely different cause: very old SNI-incapable clients
A small, shrinking population of very old clients don't support SNI at all, and will always receive whatever certificate is configured as the server's default, regardless of the hostname they actually requested — this is a fundamentally different, client-capability-driven cause rather than a server misconfiguration, and isn't fixable server-side beyond choosing a sensible default certificate for that fallback case.
What testing without SNI specifically reveals about a server's default certificate behavior
Explicitly connecting without providing SNI (using OpenSSL's s_client without the -servername flag) shows exactly what certificate a server falls back to by default — useful for understanding what a non-SNI-aware client would in reality receive, and confirming whether that fallback behavior is intentional or a misconfiguration.
How virtual host ordering affects which certificate becomes the SNI-less default
Both Nginx and Apache select a default virtual host, used for any connection without SNI or with SNI not matching any configured host, based on which virtual host block is defined first (or explicitly marked as default) in your configuration — reordering or explicitly designating the default block controls this fallback behavior.
Why testing every hosted hostname individually catches a misconfiguration affecting only one site
On a server hosting multiple sites, an SNI misconfiguration sometimes affects only one specific hostname while others work correctly — testing each hosted hostname individually with OpenSSL's -servername flag, rather than assuming a working test for one site means every site is correctly configured, catches this kind of isolated, easy-to-miss misconfiguration.
What a wildcard certificate's interaction with SNI selection sometimes causes confusion about
A wildcard certificate covering multiple subdomains still requires correct SNI-based selection if it's one of several certificates configured on a server — having a wildcard doesn't bypass or simplify SNI configuration, a common point of confusion when troubleshooting a multi-certificate server.
How load balancers and CDNs add their own layer of SNI handling to troubleshoot
A CDN or load balancer sitting in front of your origin server introduces its own separate SNI handling layer — testing immediately against your origin bypassing the CDN, and separately testing through the normal CDN path, isolates whether an SNI issue originates at your origin's own configuration or at the intervening CDN layer.
Why SNI issues often only surface for a specific subset of visitors or clients
Because SNI support and behavior varies across different clients (some older systems, some specific API libraries, some IoT devices), an SNI misconfiguration can appear to work fine for the majority of modern browser traffic while in particular failing for a smaller, less common subset of clients — making this class of issue easy to miss during typical browser-based testing alone.
What happens technically when a client doesn't support SNI at all
A client with no SNI support sends no hostname indication during the handshake at all, meaning the server has no information to select an appropriate certificate and falls back entirely to whatever default is configured — this is a fundamentally different scenario from a client sending incorrect SNI, and understanding which one you're facing determines the appropriate fix.
How to configure a sensible default certificate for the small population of non-SNI clients
Explicitly configuring which certificate serves as the default for connections without SNI, rather than leaving it to whatever your server software selects automatically (often simply the first configured site), lets you deliberately choose which of your hosted sites, if any, should reasonably serve as the fallback for this small, shrinking population of clients.
Why modern infrastructure increasingly treats non-SNI support as an acceptable limitation
Given how small and shrinking the population of really non-SNI-capable clients has become, many modern platforms and CDNs now treat lack of SNI support as an acceptable limitation rather than a scenario requiring dedicated accommodation — a reasonable trade-off given SNI's near-universal support today, though worth confirming against your own specific audience if you have reason to believe otherwise.
A quick checklist for resolving most SNI misconfigurations
Confirm each hostname on a shared server serves its own correct certificate individually, check virtual host or server block ordering for an unintended default, and test with the -servername flag to isolate SNI-specific behavior — three checks resolving the majority of SNI misconfiguration cases.
Why SNI troubleshooting rewards patience over quick assumptions
Because SNI issues often affect only a subset of hostnames or clients, jumping to conclusions based on a single test can miss the actual scope of the problem — systematically testing every hosted hostname individually, rather than assuming one successful test means the whole server is correctly configured, catches issues a quicker check would miss.
See RFC 6066, the TLS extensions spec defining SNI.
Loading comments…