SSL Certificate Checker

What an SSL check tells you

An SSL (really TLS) check connects to a host, completes the handshake, and reports back the certificate it was served: the subject and any Subject Alternative Names, the issuer, the validity window, the signature algorithm, and which TLS protocol versions the server will speak. It answers the practical question of whether browsers will trust the site and for how long.

When you reach for it

You run it right after installing or renewing a certificate, when users report a browser warning, or when monitoring flags an upcoming expiry. It is also the fastest way to confirm a load balancer or CDN is presenting the certificate you think it is rather than a stale one.

Example

$ openssl s_client -connect example.com:443 -servername example.com
subject=CN=example.com
issuer=CN=R3, O=Let's Encrypt
notBefore=Jan  1 00:00:00 2024 GMT
notAfter =Apr  1 23:59:59 2024 GMT

The -servername flag sends SNI, which matters because one IP can host many certificates; without it you may get the wrong one.

Common pitfalls

The classic failure is a broken chain. Your leaf certificate can be perfectly valid while the server forgets to send the intermediate certificate that links it to a trusted root. Many desktop browsers paper over this using cached intermediates, so it works on your laptop and fails on a fresh mobile device. Always test the full chain, not just the leaf. A second trap is confusing leaf expiry with the whole path: an intermediate can expire and break trust even while your leaf still has months left.

FAQ

It works in Chrome but fails on my phone, why? Almost always a missing intermediate. Chrome had it cached; the phone did not. Fix the chain the server sends.

Does the certificate cover www and the root? Only if both appear in the SAN list. A cert for example.com does not automatically cover www.example.com.

The cert is valid but the site is unreachable. That is a name resolution issue, not TLS. Check the record first with the DNS lookup tool.