SSL Checkers: Honest Pros and Cons

2026-03-27 · SPUNK13 · spunk.bet

An SSL checker tells you whether a TLS configuration is valid, modern and trusted. There are three broad kinds — hosted scanners, local scripts and raw openssl — and each fails at something the others catch.

Hosted scanners: thorough, public, slow

Qualys SSL Labs remains the reference. It grades A+ down to F, tests handshake simulation against dozens of client versions, checks chain completeness, and flags weak ciphers and protocol support. Two real drawbacks: a full scan takes one to three minutes, and results are published by default unless you tick the box to hide them. It also cannot reach anything on a private network, and it only tests port 443 on a public hostname. Hardenize and the Mozilla Observatory cover adjacent ground, the latter grading security headers alongside TLS.

testssl.sh: the one to run in CI

testssl.sh is a single bash script wrapping openssl. It runs against internal hosts, arbitrary ports and STARTTLS services:

testssl.sh --severity HIGH --jsonfile out.json example.com:443
testssl.sh --starttls smtp mail.internal:25

The --severity flag plus JSON output makes it a usable CI gate. Downsides: a full run takes several minutes because it opens a lot of handshakes, and some corporate IDS systems will flag it as an attack. Use --fast for routine checks.

openssl s_client: nothing to install, nothing hidden

When you need one specific answer, this is the fastest path:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

That prints subject, issuer and the notBefore/notAfter dates in about a second. Add -showcerts to inspect the chain the server actually sends, which is how you catch a missing intermediate — the single most common "works in Chrome, fails on Android" bug.

What every checker misses

Scanners test the endpoint you point them at. They do not know about the other 40 hostnames on the same load balancer, the certificate on your mail server, the internal API on port 8443, or the client certificate expiring in a partner integration. They also cannot see a certificate that is valid today and expires during your holiday. Point-in-time scanning is not monitoring.

Expiry monitoring is the part that actually prevents outages

Most certificate incidents are not weak ciphers; they are a renewal that silently failed. Three cheap fixes: run a daily cron that checks days-to-expiry across a list of hosts and alerts under 21 days; enable certbot renew --dry-run in a weekly job so a broken renewal surfaces before the real one; and watch Certificate Transparency logs for your domains so you learn about certificates you did not issue.

Pros and cons, condensed

• SSL Labs — best depth and client simulation; public results, public hosts only, slow.
• testssl.sh — works internally, scriptable, JSON output; slow full runs, noisy to network security tools.
• openssl s_client — instant, universal, no dependencies; you must know what to look for, no grading.
• Cron expiry check — catches the failure mode that causes most outages; tells you nothing about cipher quality.

Run a hosted scan when you change configuration, testssl.sh in CI, and an expiry check every day. That combination covers the realistic failure modes without turning TLS into a weekly chore.