What Is SNI and Why Does a Server Serve the Wrong Certificate?

If you request example.org and the browser receives a certificate for example.com, the problem is often not the certificate file itself.

It is the server-selection step that happens during the TLS handshake.

That is where SNI, or Server Name Indication, matters.

The short definition

SNI is a TLS extension that allows the client to send the requested hostname during the TLS handshake.

That matters because the server has to choose a certificate before it sees the normal HTTP request.

Without the requested hostname during the handshake, a multi-domain HTTPS server would have no reliable way to know which certificate to present.

Why the wrong certificate gets served

Current NGINX documentation explains the underlying behavior clearly:

• the TLS connection is established before the HTTP request arrives
• without the right server-name information, the server can present the default certificate
• on a shared IP, multiple HTTPS sites need SNI or some other strategy to select the right certificate

This is why wrong-certificate issues often show up in multi-domain environments rather than on a single standalone site.

What the default-certificate problem looks like

In a name-based HTTPS setup on one IP address, NGINX documents that the browser can receive the default server’s certificate regardless of the requested server name if the right hostname is not available at the right stage.

That creates symptoms like:

• one hostname works but another gets the wrong certificate
• the certificate looks correct on one port or node but not another
• the browser says the certificate is valid for a different domain
• an IP-address test shows one certificate while a hostname test shows another

Why this happens in real systems

1. The request lands on the default HTTPS server

If the configuration for a listen socket has a default server and the TLS handshake is not matched to the intended virtual host, the default server’s certificate may be sent first.

That is not unusual behavior. It is how the protocol timing works.

2. The wrong hostname is matched

Current NGINX documentation also explains that virtual-server name matching follows precedence rules:

• exact names first
• then wildcard names
• then regular expressions

So a catch-all or wildcard pattern can accidentally capture traffic in ways the operator did not intend.

3. The client is not sending usable SNI

NGINX notes that only domain names can be passed in SNI and that you should not rely on clients using a literal IP address to behave correctly for name-based certificate selection.

So tests made against an IP address can produce misleading conclusions about which certificate the hostname really gets.

4. The edge or load balancer is the real certificate owner

Sometimes the origin server has the right certificate, but a reverse proxy, ingress, or CDN node in front of it serves a different one.

That means the wrong-certificate issue is not on the app host at all. It is on the TLS termination layer in front of it.

Why this belongs in the domain-lookup workflow

A domain lookup often reveals that the hostname resolves to:

• a shared reverse proxy
• a CDN edge
• a load balancer
• a multi-tenant platform

That is exactly the kind of environment where wrong-certificate problems are more likely to be about host routing and certificate selection than about one broken PEM file on one server.

This is why certificate interpretation belongs in the same workflow as DNS and hosting analysis.

The clean mental model

Think about certificate selection in this order:

1. Which public hostname is being requested?

The hostname matters because SNI is hostname-based.

2. Which public IP or edge layer receives the connection?

If the hostname resolves to a shared or layered edge, that layer may be the one choosing the certificate.

3. Which virtual host wins during TLS selection?

If the listen socket, server-name rules, or default server do not line up with the hostname, the wrong certificate can be served before HTTP routing even starts.

Common mistakes

"The certificate file is wrong"

Sometimes it is.

But in many multi-domain setups, the real issue is that the wrong virtual host is being selected, not that the intended certificate file is missing.

"The browser asked for the right hostname, so the right certificate should always be served"

Only if the edge layer, SNI support, and virtual-host selection are all configured coherently.

"Testing by IP address tells me what real users will see"

Not reliably.

Name-based HTTPS and SNI behavior are tied to hostnames, not just IPs.

When to suspect SNI or virtual-host selection immediately

Suspect it when:

• the wrong certificate belongs to another domain on the same server or edge
• one subdomain gets the right certificate and another does not
• the origin appears correct but the public hostname still shows the wrong certificate
• the environment uses one IP or edge cluster for many HTTPS names

FAQ

What is SNI in simple terms?

It is the hostname the client sends during the TLS handshake so the server can choose the right certificate before the HTTP request is processed.

Why does a server serve the default certificate instead of the requested one?

Because TLS certificate selection happens before normal HTTP routing, and without the right hostname or virtual-host match, the default HTTPS server can win.

Can one IP address host multiple HTTPS certificates correctly?

Yes. That is a common modern pattern, but it depends on proper SNI-aware certificate selection and correct virtual-host matching.

Should I test certificates by hostname or IP address?

By hostname first. IP-only tests can be misleading in name-based HTTPS setups.