2026-06-02

TLS SNI Mismatch PCAP Analysis: Wrong Certificate, Wrong Host, Proxy Routing, and Handshake Failure

How to diagnose TLS SNI mismatch, wrong certificate, hostname mismatch, reverse proxy routing errors, ClientHello SNI, certificate validation failures, and packet evidence.

tls sni mismatch, wrong certificate, hostname mismatch, clienthello, reverse proxy, pcap analysis

TLS SNI mismatch is a common cause of confusing HTTPS, API, MQTT, gRPC, and WebSocket failures. The client connects to the right IP, but the server returns the wrong certificate. The browser says the certificate is for another host. A proxy routes the request to the wrong backend. An application reports certificate verify failed, hostname mismatch, or handshake failure. Users search for "TLS SNI mismatch pcap", "wrong certificate packet capture", "ClientHello SNI Wireshark", and "reverse proxy certificate mismatch" because DNS and TCP may look correct while TLS fails.

PCAP Surgery is useful because the decisive evidence often appears in the TLS ClientHello and the server's response timing.

What SNI does

Server Name Indication lets a TLS client tell the server which hostname it wants:

ClientHello
SNI: api.example.com

A server or load balancer uses SNI to choose the certificate and backend. Without SNI, or with the wrong SNI, it may present a default certificate.

Common causes

SNI mismatch can happen when:

  • Client connects by IP address.
  • Client uses internal hostname but expects public certificate.
  • Reverse proxy routes based on SNI and receives the wrong value.
  • CDN or load balancer default certificate is served.
  • Application overrides Host header but not SNI.
  • TLS termination config is missing the hostname.
  • Backend certificate does not match upstream SNI.

HTTP Host and TLS SNI are related but not identical. The Host header is inside HTTP after TLS starts; SNI appears during TLS handshake.

Packet evidence

In a pcap, preserve:

  • DNS answer.
  • TCP destination IP and port.
  • TLS ClientHello.
  • SNI value.
  • TLS alert or reset.
  • Certificate metadata where visible.
  • Timing of failure.

For TLS 1.3, much is encrypted after early handshake, but ClientHello SNI is often still visible unless encrypted client hello is used.

Proxy and upstream SNI

Reverse proxies can have two TLS legs:

  • Client to proxy.
  • Proxy to upstream.

The first SNI may be correct while the upstream SNI is wrong. Capture at the proxy or upstream side if the client-side trace is not enough.

Checklist

Use this workflow:

  1. Preserve DNS lookup.
  2. Inspect ClientHello SNI.
  3. Compare SNI to URL hostname.
  4. Compare SNI to certificate hostname.
  5. Check whether client connects by IP.
  6. Check reverse proxy routing rules.
  7. For upstream TLS, capture proxy-to-backend leg.
  8. Look for TLS alert sender.
  9. Correlate with application certificate error.
  10. Preserve handshake packets when trimming.

Final diagnosis

TLS SNI mismatch is a hostname-routing failure in the TLS handshake. The packet evidence can show the SNI value, destination, certificate behavior, alert/reset timing, and proxy routing context.

PCAP Surgery helps isolate the TLS handshake so wrong-certificate failures can be explained by concrete ClientHello and routing evidence.