Why a Secure Site Will Not Open
A TLS handshake fails when the client and the server cannot agree on how to secure the connection. The side that gives up usually says why, with a fatal alert: no common TLS version or cipher suite, a certificate it does not trust, or a host name it does not serve. The handshake travels before encryption starts, so a packet capture shows the attempt and the alert even for HTTPS.
For users it is only "this site can't provide a secure connection" in one application or one browser, often after an update on one side. The network is fine, other HTTPS sites open, and the fix belongs to whoever runs the server or the client software.
One portal or API fails with a secure-connection error, while other HTTPS sites work.
A client hello, then a fatal TLS alert and a close, on every attempt to that server.
What the PcapAI Report Shows
In the sample capture, two laptops try to open a supplier portal at portal.example.net and also visit another HTTPS
site on the same path. PcapAI reports one problem and places it on the server:
- ✦TLS handshakes fail: 8 of 8 handshakes with the portal ended with a fatal alert, handshake_failure from the server: no common cipher suite or parameters.
- ✦The network is not at fault: TCP connections, packet loss and latency are clean, and the other HTTPS site completes its handshakes.
- ✦Who fixes it: the server or application owner, acting on the alert reason. For handshake_failure that means aligning cipher suites; a version alert means enabling TLS 1.2 or 1.3 on both sides; certificate alerts mean installing the right intermediate and root certificates; unrecognized_name means fixing the server name (SNI) configuration.
- ✦How to confirm the fix: the TLS handshake with the portal completes.
The sample capture behind this page was built in a lab: every server uses a documentation address (RFC 5737) and a documentation name (RFC 2606), and the PDF is the unedited report PcapAI wrote for it.
How It Looks in a Capture (Check It Yourself)
In Wireshark, the first filter shows fatal alerts, the second the client hellos they answer:
tls.alert_message.level == 2 tls.handshake.type == 1
From the command line, who sent each alert and which one:
tshark -r capture.pcap -Y tls.alert_message -T fields -e ip.src -e tls.alert_message.desc
Common TLS Alerts and What They Point At
| Alert | Usually means | Usually fixed by |
|---|---|---|
| handshake_failure | No common cipher suite or parameters | Server owner, sometimes the client software |
| protocol_version | No common TLS version | Whichever side only offers old versions |
| unknown_ca, bad_certificate, certificate_unknown | The certificate chain is not trusted | Server owner: install the intermediate certificates |
| unrecognized_name | The server does not serve the requested host name | Server owner: fix the virtual host or SNI setup |
PcapAI also checks TLS handshakes that hang, connections cut right after the client hello, slow handshakes, servers that still use TLS older than 1.2, and expired or self-issued certificates where TLS 1.2 still shows them.
Common Causes of TLS Handshake Failures
- ✦The server was hardened and no longer accepts the cipher suites an older client offers.
- ✦The client only supports TLS versions the server has turned off.
- ✦The server sends its certificate without the intermediate certificate.
- ✦The host name the client asks for is not set up on the server (SNI).
- ✦A TLS-inspecting proxy or firewall on the path ends handshakes it cannot inspect.
The alert in the capture tells these apart, and the report turns it into the fix for the right side.
From Capture to Fix
- Capture on the client while it tries to open the failing site.
- Upload the capture: the free summary names the server and the alert.
- From a host you control, repeat the handshake read-only:
openssl s_client -connect portal.example.net:443 -servername portal.example.netprints the negotiation and the alert. - After the change, capture again: the report's own check is a completed handshake.
Frequently Asked Questions
What does a TLS handshake_failure alert mean?
The side that sent it found no acceptable combination of cipher suite and parameters in what the other side offered. It is a configuration mismatch between client and server, not a network fault.
Can a packet capture show why HTTPS fails if the traffic is encrypted?
Yes. The client hello, the server hello and any alert during the handshake travel before encryption starts, so the capture shows the versions and cipher suites offered and the alert that ended the attempt. Only the content after a completed handshake is encrypted.
Why does the site work in one browser but not in another application?
Each TLS client offers its own list of versions and cipher suites. An older application or a hardened server can leave no overlap for one client while a modern browser still finds one. The capture shows exactly what the failing client offered.
Related Pages
Check your own capture
Capture the failing connection and upload it: the free summary shows in about two minutes which server ends the TLS handshake and with which alert, and the $9 PDF adds the attempts, the evidence and the fix for its owner.
Sample Report: Executive Summary
