# Server returns the wrong certificate: SNI, SAN and the default virtual host

Diagnose server returns the wrong certificate: SNI, SAN and the default virtual host. Evidence to collect, a worked operational example and recovery checks.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/tls-sni-san-wrong-certificate/
Language: en

A wrong certificate can indicate SNI selecting another virtual host or a mismatch between the expected name and SAN. These are different TLS stages. Establish the name sent by the client and the certificate actually returned, keeping verification enabled.

## Separate address from identity

The DNS name, destination IP, HTTP Host and TLS server name have different roles. A client using a literal IP may omit expected SNI, causing selection of the default HTTPS configuration. Adding an HTTP Host header after TLS establishment cannot repair the certificate already selected. Record the exact URL and resolution method. If a proxy or balancer terminates TLS, identify that boundary and its chain owner.


[Official reference 1](https://nginx.org/en/docs/http/configuring_https_servers.html).

## Inspect virtual-host selection

For NGINX, compare listen, default_server, server_name and ssl_certificate for the relevant address. SNI permits selection before the HTTP request. One IP can serve several names with different certificates. Do not edit an arbitrary server block: effective configuration includes imported files and multiple listen sockets. Reconstruct the complete applicable configuration and identify which block should answer the test client's name.


[Official reference 2](https://www.rfc-editor.org/rfc/rfc9525.html).

## Examine a SAN mismatch

RFC 9525 defines service-identity matching, including distinct DNS-ID and IP-ID rules. A certificate for api.example.org does not validate an arbitrary IP merely because DNS points there. In an example, connecting by name receives the correct SAN while a literal-IP connection fails identity validation. That difference is expected without a suitable IP-ID. It does not establish expiration or a missing trusted CA.

| Observation | Stage to investigate |
| --- | --- |
| Unexpected leaf certificate | SNI and virtual-host selection |
| Correct leaf, rejected name | SAN and reference identity |
| Untrusted chain | CA store and intermediates |
| Certificate outside validity | Clock and validity interval |

## Correct naming and selection

Use the intended DNS name, repair client server-name configuration or correctly deploy the certificate and virtual host. Disabling verification removes the very criterion that establishes the intended peer. For a replacement certificate, compare fingerprint and SAN, then inspect the published chain. Reload NGINX only after configuration validation and through the environment's authorized maintenance process.

## Preserve a safe diagnostic record

Retain the URL without secret query parameters, destination IP, transmitted name, SAN and fingerprint. The private key is unnecessary for inspecting a server response and must not enter the report. Repeat with the same client and an independently configured tool. If their results differ, compare client configuration. This record keeps SNI routing separate from trust and time failures instead of treating every certificate error as one cause. Reuse the same naming test after changing a proxy or TLS termination point.

Related operational reading: [network and uptime](/journal/network-and-uptime/); [hardware security](/journal/hardware-security/).