TLS and SSL security checker
What an external TLS check covers — and what it cannot
What an external TLS and SSL check covers: certificate validity, hostname match, protocol versions, cipher suites, chains and redirect-to-HTTPS behaviour.
What this check reads
Transport security is the layer where external assessment is strongest, because everything it inspects is on the wire by definition. A TLS check completes a real handshake against your host, reads the certificate the server presents, and enumerates what the server will negotiate.
No credentials are involved and nothing is installed. It is also read-only in the strict sense: a TLS handshake is not a request against your application, and the scan never sends a single byte of an HTTP request while it is doing this.
The certificate
| Property | Why it matters |
|---|---|
| Validity window | An expired certificate produces a browser interstitial, and one near expiry will produce one at the worst possible moment. Expiry is the most common finding on otherwise well-run sites. |
| Hostname match | A certificate valid for www but not the apex, served
on both, fails on whichever the visitor used. The check tests each host
name it expects the site to answer on. |
| Chain of trust | A browser validates the chain itself and will refuse a certificate that names an intermediate it cannot fetch. A missing or incorrect intermediate is invisible to a casual visitor on a machine that happens to have cached it. |
| Trust | Self-signed and untrusted certificates are detected as such. Some are entirely deliberate — a certificate pinning setup will serve one — so this is reported as an observation about what is being trusted rather than as an automatic failure. |
| Key and algorithm | Weak key sizes and deprecated signature algorithms are still accepted by a large share of clients in the field. A weak key is not broken, but it is shorter than it needs to be. |
| What the certificate reveals | Certificate transparency logs are public by design, so the set of names a certificate has covered is discoverable by anyone. Internal hostnames appearing on a public certificate is a disclosure finding, not a cryptographic one. |
| Wildcard scope | A wildcard certificate covering more names than the site uses expands the blast radius if the private key is ever exposed. |
The negotiation
A certificate can be entirely correct while the server still negotiates badly. The check enumerates what the host actually offers rather than assuming a modern stack:
- Protocol versions. Whether deprecated protocol versions are still accepted. A server that still offers them is not necessarily vulnerable, but it negotiates down with anything that asks, including an attacker.
- Cipher suites. Weak suites accepted alongside strong ones are the usual finding. Ordering matters as much as membership.
- Certificate status. Revocation information — whether the server presents it, and whether stapling is in use.
- Renegotiation and session resumption. Insecure renegotiation support and absent session resumption both show up here.
- Elliptic curves. Whether weak curves are offered alongside strong ones.
Two of these are named after historical implementations — TLS-NEW-007 is Heartbleed and TLS-NEW-008 is ROBOT. Both are still checked, because a host that is misconfigured enough to be vulnerable to one of them is often misconfigured in other ways too. On a current deployment both are expected to come back clear.
Delivery, which is where most findings are
What a visitor experiences depends on more than the handshake:
- Is plain HTTP redirected to HTTPS? If not, the first request of every visit is unprotected, which is the only request an on-path attacker needs.
- Which host is canonical? If
httpandhttpsboth serve 200, the same content is at two URLs and any link can pick either. - Where does the redirect chain go? A chain that passes through an unencrypted hop is worse than a direct one, and it is invisible in the browser's address bar.
- Mixed content. An HTTPS page loading an
http://subresource hands the attacker a script position. Active mixed content — a script, not an image — is the serious case. - HSTS. Covered in depth on the security headers guide; the transport checks verify it is present, correctly scoped and long enough to matter.
What a TLS check cannot tell you
A handshake is a point-in-time observation
- It describes what your host negotiated for that connection. A CDN, load balancer or anycast edge in front of you may terminate TLS for some visitors and pass through for others, so one answer is not every answer.
- It says nothing about what happens after the handshake. A perfectly configured TLS endpoint serving an exploitable application is still that.
- It cannot see the private key, so it cannot tell you whether it is well protected, where it is stored, or who has access to it.
- It does not test whether your certificate will be renewed before it expires — only whether it is valid today.
Check the TLS on your own site
Certificates, protocols, ciphers and HTTPS delivery, checked from outside alongside the rest of your external surface.
Read-only. A handshake sends nothing to your application.