TLS checker
Check which TLS versions a site accepts, its certificate and how long the handshake takes. One domain, about 5 seconds.
What this TLS check tells you
Every HTTPS visit starts with a TLS handshake. Which protocol version the server allows decides both how secure that is and how many network round trips it costs before the first byte of your page can travel. This checker looks at the four things that matter for speed and for browser errors:
- Versions: TLS 1.3 and 1.2 should be on, TLS 1.1 and 1.0 off. We try each one separately, so you see the server's real policy, not just its first choice.
- Handshake time: about one round trip with TLS 1.3, two with TLS 1.2. We show it next to the TCP connect time so you can see the ratio. See the messages step by step.
- HTTP/2 and HTTP/3: negotiated inside the handshake (ALPN) or advertised in the Alt-Svc header.
- Certificate: expiry, hostname match, issuer and chain. A missing intermediate certificate is a classic cause of "works in Chrome, fails in curl or on Android".
TLS 1.2 vs TLS 1.3
| TLS 1.2 (RFC 5246, 2008) | TLS 1.3 (RFC 8446, 2018) | |
|---|---|---|
| Round trips for a new connection | 2 | 1 |
| Resumed connection | 1 (session ticket) | 0 with 0-RTT early data |
| Key exchange | RSA or (EC)DHE | (EC)DHE only: forward secrecy always on |
| Cipher suites | Dozens, including weak CBC and RC4-era options | Five, all AEAD |
| Certificate sent | In the clear | Encrypted |
How to fix common TLS problems
- TLS 1.3 missing: on nginx add
ssl_protocols TLSv1.2 TLSv1.3;(needs OpenSSL 1.1.1+); on ApacheSSLProtocol -all +TLSv1.2 +TLSv1.3. Most CDNs have a "minimum TLS version" setting and enable 1.3 by default. - Old versions still on: the same directive: list only TLSv1.2 and TLSv1.3.
- Untrusted chain: serve the full chain file (your certificate plus intermediates), e.g.
fullchain.pemfrom Let's Encrypt, notcert.pem. - Slow handshake: TLS 1.3, HTTP/2 connection reuse, an ECDSA certificate and a CDN edge close to visitors all cut it. Check the effect on time to first byte.
TLS checker questions
How do I check which TLS version a website uses?
Enter the domain above. We open a fresh connection and report the version your server picks when a modern client offers everything (normally TLS 1.3), then make one connection per version, each allowed to use only TLS 1.3, 1.2, 1.1 or 1.0, to show exactly which ones the server accepts. In a browser you can also open DevTools, go to the Security tab (Chrome/Edge) and read the "Connection" line.
Is TLS 1.2 still OK?
Yes. TLS 1.2 with modern AEAD cipher suites (AES-GCM, ChaCha20-Poly1305) is still considered secure and is required by most compliance standards as the minimum. TLS 1.3 is faster (one round trip instead of two for a new connection) and removes legacy options, so enable both: 1.3 for modern browsers, 1.2 for older clients.
Should I disable TLS 1.0 and 1.1?
Yes. RFC 8996 (2021) formally deprecated TLS 1.0 and 1.1, and current Chrome, Firefox, Safari and Edge refuse them. Leaving them on adds risk without helping real visitors. PCI DSS has required disabling early TLS for card data since 2018.
What does "SSL handshake failed" mean?
The client and server could not agree on a secure connection. The most common causes are: the server only allows protocol versions or cipher suites the client does not support (or the reverse), an expired, self-signed or wrong-hostname certificate, a missing intermediate certificate, a server that needs SNI but did not get it, or a firewall/proxy interrupting the connection. Run the check above: it shows which versions are accepted and whether the certificate is valid for the hostname.
What is ALPN and why does it show h2?
Application-Layer Protocol Negotiation lets the browser and server pick the HTTP version inside the TLS handshake, without an extra round trip. "h2" means the server agreed to HTTP/2, which multiplexes many requests over one connection. "http/1.1" means HTTP/2 is not enabled on this host.
How do I know if my site supports HTTP/3?
HTTP/3 runs over QUIC (UDP), so browsers first learn about it from an Alt-Svc response header such as h3=":443" sent over HTTP/1.1 or HTTP/2. We read that header and report whether HTTP/3 is advertised. We do not open a QUIC connection ourselves.
What is X25519MLKEM768?
It is a hybrid key exchange that combines the classic X25519 elliptic-curve exchange with ML-KEM-768, the post-quantum algorithm standardised by NIST in FIPS 203. Recent browsers and CDNs negotiate it by default in TLS 1.3, so seeing it here means your server supports post-quantum key agreement.
Why is the handshake time different in my browser?
The handshake costs round trips, so it depends on the distance between client and server. We measure from one data-centre region (shown with the result). A visitor on another continent or on mobile pays more per round trip; one close to your CDN edge pays less.