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

When a client reaches the expected IP address but gets the wrong certificate or a TLS hostname error, start with the ClientHello server name and the certificate or alert that follows it. A PCAP can show whether the visible client offered an SNI hostname, which address and port it contacted, whether the server selected TLS parameters, and where the connection closed. It cannot, by itself, reveal an encrypted HTTP Host header, every TLS 1.3 certificate detail, or the internal routing rule that a proxy applied.

That is the practical boundary for a TLS SNI mismatch PCAP analysis. The goal is not to look for a magic packet labelled “wrong certificate.” It is to establish a defensible chain of facts:

1. Which hostname did the user intend to reach?
2. Which IP address and port did the client actually contact?
3. What SNI value, if any, did the visible ClientHello offer?
4. What certificate, TLS alert, reset, or timeout followed at the capture point?
5. Which proxy or origin log can confirm the routing decision that the trace cannot prove?

This workflow applies to browser errors, API clients, service meshes, embedded devices, load balancers, CDNs, reverse proxies, and internal HTTPS services. It also explains why a connection can work by IP, fail by hostname, or appear to use the right DNS answer while still reaching the wrong TLS virtual host.

SNI, hostname, and HTTP Host are different signals

Server Name Indication (SNI) is a TLS extension in the client’s early handshake. It lets a client identify the hostname it wants before the server selects a certificate. A shared IP address can therefore host many TLS names, each with a different certificate and backend route.

HTTP Host is different. It belongs to the HTTP request, which normally travels after the TLS session is established and is therefore encrypted in a normal HTTPS capture. Changing HTTP Host cannot repair an earlier certificate-selection failure, because the server must decide which certificate to present before it can read an HTTPS request.

Value	Where it appears	What it influences	What a normal PCAP may show
URL hostname	Application configuration, browser address, or logs	The name the user expected to reach	Not necessarily present in the capture itself.
DNS query and answer	DNS traffic, if captured	Which address the client may select	Often visible, but DNS may use another resolver path or be encrypted.
Destination IP and port	TCP/IP headers	The network endpoint reached	Visible unless the capture is too late in a tunnel or translation path.
TLS SNI	ClientHello, when not protected by ECH	Certificate and virtual-host selection	Often visible; not a safe assumption with Encrypted Client Hello.
HTTP Host/:authority	HTTP after TLS setup	Application-layer virtual-host routing	Usually encrypted and unavailable without lawful decryption.

A good investigation records each value separately. “The name is wrong” is too vague: DNS can be correct, SNI can be missing, certificate selection can use a default virtual host, and the HTTP request may never have been sent.

The shortest path to a useful conclusion

For one failing attempt, isolate a single TCP connection and write down these packet markers before changing proxy configuration:

Marker	Why it belongs in the evidence note
DNS query/answer, if available	Shows the name and address context that preceded the connection.
SYN, SYN/ACK, and ACK	Confirms whether TCP succeeded before TLS began.
ClientHello	Provides the visible SNI and the client's TLS offer.
ServerHello or immediate response	Shows whether the server accepted part of the TLS proposal.
Certificate-related stage, if visible	Connects the client error to server authentication timing.
TLS alert, FIN, or RST	Records how the observed handshake ended.
Capture location	Prevents a missing packet from being misreported as a packet that never existed.

If TCP does not establish, stop calling the case an SNI mismatch. Investigate reachability first with the TCP SYN retransmission PCAP workflow. If the client never sends ClientHello, the TLS library or a local proxy may have failed before the traceable SNI stage.

Inspect ClientHello without overreading it

In a conventional TLS capture, the ClientHello may include:

• the offered TLS versions;
• cipher suites;
• supported groups and signature algorithms;
• application protocol choices through ALPN; and
• the server_name value used for SNI.

Compare that SNI value to the hostname the client was configured to use. Do not compare it only to the destination IP: one IP can correctly serve hundreds of names. A mismatch can take several forms:

Client behavior	Likely visible ClientHello result	Plausible consequence
Connects to api.example.test normally	SNI api.example.test	Correct certificate and backend are possible if proxy configuration matches.
Connects by numeric IP	SNI may be absent	Default certificate or default virtual host may be selected.
Uses an internal alias but expects a public certificate	SNI is the internal alias	Certificate name mismatch or an unexpected backend is possible.
Application overrides an upstream name incorrectly	SNI differs from the user-facing hostname	The proxy-to-upstream leg may fail despite a healthy client-facing leg.
Legacy client omits SNI	No usable name extension	Name-based TLS routing cannot select the intended host from SNI.
Encrypted Client Hello is in use	Intended inner SNI may not be visible	The outer name cannot be treated as the final routing name without endpoint context.

The word “possible” is deliberate. A ClientHello gives high-quality input evidence, but the receiving endpoint’s configuration decides what it does with that input. Confirm the selected certificate and virtual-host decision in proxy or server logs where available.

Encrypted Client Hello changes what an observer can see

Modern TLS deployments can use Encrypted Client Hello (ECH), which protects the intended name from a passive observer. In that situation, an outer ClientHello may contain a public-facing name while the inner ClientHello carries the intended service name. Do not conclude that the visible outer name is an SNI mistake merely because it differs from the URL or certificate.

This is another reason to state capture limits explicitly: “the passive trace does not expose the intended inner name” is a technically useful result. The next evidence should come from the client TLS library, the ECH-capable edge, or controlled test configuration—not from guesses about encrypted fields.

Wrong certificate: distinguish observation from cause

Users often report “wrong certificate,” but that phrase can mean different things. The client may have received a valid certificate for another hostname, an incomplete chain, a certificate outside its validity window, an interception certificate from an enterprise device, or a certificate that the local trust store does not accept.

A packet capture can help separate these cases, but the visibility depends on TLS version and capture position. In TLS 1.2, certificate-related handshake messages are often readable in an ordinary capture. In TLS 1.3, much of the handshake after ServerHello is encrypted, so a trace may show timing and an alert boundary without exposing the certificate details. That is expected behavior, not a failed decoder.

Evidence pattern	What it supports	What to verify next
SNI is service.example, certificate visibly names another host	The selected certificate does not match the visible intended SNI.	Default-vhost order, certificate bindings, reverse-proxy route, and whether wildcard coverage is valid.
SNI is absent, certificate names a default host	The endpoint likely had no SNI name to use for selection.	Client configuration, IP-based URL use, legacy-device TLS support, and a default certificate policy.
Correct SNI, but client emits certificate/trust alert	The client rejected the authentication phase of the observed handshake.	Trust store, chain delivery, name verification, clock, pinning, or TLS interception.
Correct SNI and no readable certificate details in TLS 1.3	The trace does not expose enough certificate content to diagnose the exact validation reason.	Client error logs and edge/server certificate telemetry.
Server resets after ClientHello	A connection termination occurred after the offer.	Load balancer, firewall, endpoint, and second capture-point evidence before labelling it a certificate problem.

For a certificate validity investigation, the expired TLS certificate handshake guide provides the right capture and log checklist. For general alert/reset boundaries, use the TLS handshake failure PCAP analysis.

Reverse proxies create two different TLS conversations

This is where many “SNI is correct” investigations stall. A reverse proxy that terminates TLS may create two independent sessions:

client ── TLS session A ──> edge/reverse proxy ── TLS session B ──> upstream service

Session A has the client’s SNI and certificate selection at the public edge. Session B has the proxy’s own upstream destination, SNI policy, trust settings, and certificate validation. A successful public certificate does not prove the proxy can authenticate to its upstream, and an upstream wrong-certificate error does not prove the public edge served the wrong certificate.

Symptom	Where to capture or log	Common boundary
Browser gets the wrong public certificate	Client and edge proxy	Session A certificate selection / public virtual host.
Browser gets a valid certificate but request returns an upstream TLS error	Proxy and upstream	Session B SNI or upstream certificate validation.
Client sees a reset right after ClientHello	Client plus load balancer/firewall	May be before proxy routing or at a policy device.
Edge logs correct SNI but origin logs no connection	Edge-to-origin path	Session B absent, blocked, or routed elsewhere.
Origin sees an unexpected name	Proxy and origin	Proxy’s upstream SNI override/configuration.

Capture both legs with synchronized time if possible. Packet numbers cannot be compared across interfaces, but timestamps, endpoint tuples, and log correlation IDs can. Keep the two conversations in separate evidence sections so their names and certificates do not get mixed together.

A practical step-by-step SNI mismatch workflow

Use this sequence for a reproducible support or engineering investigation.

1. Record the intended URL and test conditions

Write the exact hostname, port, client version, time, network, and whether the test used a proxy, custom DNS, or numeric IP. “Works on my machine” is not enough to compare a TLS handshake; a different resolver, SNI setting, or enterprise inspection path can change the result.

2. Preserve DNS context where it is available

If DNS is included in the capture, record the query name, answer, TTL, and selected address. Do not claim that the resolver returned the shown answer when DNS was not captured: browsers may cache answers, use encrypted DNS, or obtain the address from another component. The TCP destination is still useful evidence of the address actually contacted.

3. Confirm TCP setup and select one stream

Find SYN, SYN/ACK, ACK, then the first client payload. Retransmissions and parallel Happy Eyeballs attempts can make several similar connections appear at once. Select the stream that corresponds to the application error rather than reading the first TLS packet you find.

4. Extract the visible ClientHello fields

Record SNI, offered TLS versions, and ALPN. Include “not visible because ECH is in use” or “not present” when that is the fact. Do not replace an absent field with the hostname from a ticket; that would turn a hypothesis into supposed packet evidence.

5. Identify the server response boundary

Mark the first ServerHello, certificate-related stage where visible, alert, FIN, RST, or timeout. Measure the time between ClientHello and this boundary. An immediate fatal alert suggests a different next check than a fifteen-second silence with retransmissions.

6. Compare only the values that are actually comparable

Compare the visible SNI to the intended hostname. If a certificate is visible, compare its subject alternative names to the expected hostname according to the client’s validation rules. A wildcard is not automatically wrong; its validity depends on the exact hostname pattern. If TLS 1.3 hides the certificate details, do not pretend the PCAP supplied them.

7. Correlate at the routing owner

Ask the edge or proxy owner for the virtual host selected, certificate identifier, SNI received, and upstream target at the marked timestamp. Ask the upstream owner for the SNI and validation outcome of session B if the proxy opens TLS upstream. This is the step that converts packet observations into a confirmed configuration cause.

8. Retest one variable at a time

Use a controlled test hostname, correct SNI override, known-good network path, or corrected proxy binding—not several changes at once. Preserve a before/after capture with the same evidence markers. That prevents a successful retest from being attributed to the wrong change.

Common misdiagnoses and how to avoid them

Misdiagnosis	Why it is unsafe	Better statement
“The server is down.”	TCP may work and only name-based TLS selection may be failing.	“TCP completed; the visible TLS exchange stopped after the ClientHello.”
“DNS is wrong.”	A correct DNS answer can still reach a shared IP with wrong SNI routing.	“The client contacted this address; compare the configured hostname and visible SNI.”
“The HTTP Host header is wrong.”	HTTP is normally unavailable until after TLS certificate selection.	“Inspect SNI first; check HTTP authority only after TLS succeeds or with authorized decryption.”
“A reset proves the origin rejected the certificate.”	A proxy or network device may terminate the TCP flow.	“A reset was observed at this capture point; correlate with edge/origin logs.”
“No certificate appears, so the server never sent one.”	TLS 1.3 encryption, capture loss, and capture placement can hide details.	“The current capture cannot establish whether the certificate was exposed here.”
“The SNI shown in a passive trace is definitely the final name.”	ECH can protect the intended inner name.	“The outer visible name needs endpoint confirmation when ECH is possible.”

Create a small, useful PCAP for handoff

A whole-day production trace usually exposes too much and makes review harder. The evidence file should be limited to the failing connection and the context required to explain it: DNS when relevant, TCP setup, ClientHello, server response, alert/reset/close, retransmissions, and a small timing window on both sides.

PCAP Surgery is a local desktop workbench for classic PCAP and basic PCAPNG files. It supports reviewing decoded packet evidence, narrowing a conversation or time range, applying controlled redaction, repairing checksums where appropriate, and exporting a focused capture. It does not decrypt TLS, reconstruct missing packets, or replace confirmation from the proxy and endpoint owners.

Use the following handoff table before sending a sanitized file to support, security, or a vendor:

Handoff item	Example of a useful entry
Capture boundary	“Client-side capture; it may not observe edge-to-origin traffic.”
Target context	“Expected hostname api.example; destination 198.51.100.20:443; exact names redacted where required.”
Evidence markers	“ClientHello packet 42 at 09:18:03.442; fatal alert packet 49 at 09:18:03.468.”
Visible SNI status	“SNI api.example visible” or “inner name not observable because ECH is possible.”
Certificate visibility	“Certificate metadata visible / not visible after TLS 1.3 ServerHello.”
Observed result	“Client emits alert after server authentication stage” or “RST follows ClientHello.”
Explicit uncertainty	“Trace does not identify the proxy routing rule; edge log correlation requested.”
Original-capture policy	“Original retained securely; exported file is a reviewed subset.”

The capture-scope help explains how to choose a time range and retain the packets that make a focused artifact defensible. Keep the untouched original when policy permits; a redacted export is a communication tool, not a replacement for source evidence.

Frequently asked questions

Does no SNI always cause a wrong certificate?

No. A server can have a default certificate that happens to match, use a dedicated IP, or support another selection mechanism. But no SNI removes the normal hostname signal used by shared TLS virtual hosts, so it is a high-priority configuration check when the wrong certificate appears.

Is the certificate CN enough to prove a hostname mismatch?

No. Modern validation relies on subject alternative names, and wildcard rules matter. Treat the certificate fields in a capture as evidence to compare with the expected hostname, then confirm the client’s validation error and server/proxy certificate binding.

Why does HTTPS work in a browser but fail in an API client?

The clients may offer different SNI, TLS versions, cipher suites, ALPN values, trust stores, proxy settings, DNS paths, or client-certificate credentials. Capture a controlled attempt from each client and compare their visible ClientHello and response boundaries rather than assuming the browser is the reference for every setting.

Can I fix SNI by changing the HTTP Host header?

Usually no. Certificate selection occurs during TLS before encrypted HTTP headers are available. Configure the client or proxy’s TLS server name for the relevant leg instead, then retest with a fresh trace.

What if a PCAP shows the right SNI but the wrong certificate?

That is strong evidence that the visible SNI did not lead to the expected certificate selection. Check default virtual-host ordering, certificate binding, load-balancer listener configuration, wildcard coverage, and whether a proxy routed to a different TLS termination point. The PCAP locates the symptom; proxy/server telemetry confirms the rule responsible.

Can PCAP Surgery read encrypted HTTPS payloads to find the Host header?

No. PCAP Surgery helps isolate and prepare packet evidence; it is not a TLS decryption service. In an ordinary encrypted capture, use the visible handshake metadata and authorized endpoint logs rather than claiming that encrypted HTTP content has been read.

Conclusion: make SNI troubleshooting evidence-led

An SNI mismatch investigation is strongest when it names the exact visible boundary: the expected hostname, actual destination, ClientHello SNI status, certificate or alert timing, capture point, and required proxy/origin correlation. That approach catches genuine wrong-host and wrong-certificate problems without turning every reset, timeout, or encrypted TLS 1.3 record into a confident but unsupported diagnosis.

Once the evidence is reduced to a focused, reviewed capture and a concise timeline, teams can test the right fix: correct the client's TLS server name, bind the correct certificate to the matching virtual host, repair proxy-to-upstream SNI, or investigate the network device that interrupted the flow. That is the practical value of a rigorous TLS handshake PCAP analysis.

<!-- multilingual-related-reading:start -->

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic:

• TLS Certificate and Handshake Failure PCAP Analysis: Expired Certs, Alerts, SNI, and Connection Resets
• TLS Handshake Failure PCAP Analysis: ClientHello, ServerHello, Alerts, Resets, and Evidence
• SNI vs ALPN: TLS Handshake Analysis and HTTP/2 Negotiation in Wireshark PCAPs

<!-- multilingual-related-reading:end -->