Server Name Indication (SNI) is a TLS extension where the client states which hostname it wants before the server picks a certificate. If the client sends no name, for example when connecting by IP address, the server falls back to a default certificate, which often belongs to another site.
The problem SNI solves
TLS starts before any HTTP request is sent, so a server cannot read a Host header yet. RFC 6066 puts it plainly: TLS does not provide a mechanism for a client to tell a server the name of the server it is contacting. That is a problem when many virtual servers share one network address. The server_name extension fixes it, letting the client include the hostname in its first message so the server can choose the matching certificate.
Why the wrong certificate appears
- Connecting by IP address. A client dialing an IP has no hostname to send, so the server returns the default.
- Tool defaults. Some tools and test scripts do not send the name unless told to.
- No default configured for the name. The server has the certificate but the virtual host mapping does not match the requested name.
- A proxy or load balancer in front that does not pass the name along, or terminates TLS with its own default.
- Very old clients that predate the extension.
How to diagnose
Compare what the server returns with and without a name:
# without SNI
openssl s_client -connect 203.0.113.10:443 </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
# with SNI
openssl s_client -connect 203.0.113.10:443 -servername app.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
If the two outputs differ, the server chooses by name, and your client or your test was not sending it. If both show the wrong subject, check the server's virtual host and certificate mapping. The detail on reading output is in reading a certificate with openssl.
Fixes
- Test and monitor by hostname, never by raw IP.
- Make sure the default (catch all) certificate is one you are willing to show to scanners, because that is what an unnamed connection sees.
- In code, pass the server name to your TLS client. Most libraries do this automatically when you connect with a hostname.
- At a proxy, confirm the name is forwarded to upstream TLS. See TLS termination at the proxy.
SNI and privacy
The server name in a normal handshake travels unencrypted, so network observers can see which host you contacted. A newer extension, Encrypted Client Hello, addresses that. See what SNI leaks and how ECH helps.
Where Safeguard fits
Safeguard's asset discovery helps you keep an inventory of the hosts and services you run, so you know which names should have which certificates. Safeguard scans dependencies and SBOMs for known vulnerabilities, including those in the TLS and crypto libraries your projects pull in, and you can try it with the free scan at gold.safeguard.sh/scan.
Quick check
Why does openssl s_client show a different certificate than my browser?
You probably did not pass the servername option, so the server returned its default certificate.
Is SNI encrypted?
Not in a normal handshake. Encrypted Client Hello is the mechanism designed to hide it.
Sources
Last reviewed: 19 October 2026.
