A green padlock in the browser bar doesn't mean your TLS configuration is actually secure — it only means the certificate is valid and trusted. Here's what a real check should cover.
1. Certificate expiry
The most common (and most avoidable) outage cause: a certificate that silently expires. Most checkers cover this, set a calendar reminder regardless of auto-renewal.
2. Legacy protocol support
If your server still accepts SSLv3, TLS 1.0, or TLS 1.1, you're exposed to known downgrade attacks (like POODLE) even if modern clients negotiate TLS 1.3 by default. Many servers leave these enabled for "compatibility" years after it stopped being necessary.
3. Weak cipher suites
RC4, 3DES, and NULL ciphers are still enabled on a surprising number of servers. These were broken years ago — if a scan shows them as available, an attacker capable of forcing a downgrade can read traffic that looks encrypted.
4. Heartbleed and similar implementation bugs
Heartbleed (CVE-2014-0160) is over a decade old, but unpatched OpenSSL instances still turn up, especially on infrastructure that hasn't been touched since it was set up. This isn't something you can see by looking at the padlock — it requires an active probe.
5. Certificate chain completeness
A missing intermediate certificate can make your site fail in some browsers/devices while working fine in others, which makes it a frustrating one to diagnose without a proper chain check.
A surface-level checker will tell you the certificate is "valid." A full TLS scan tells you whether the configuration around it is actually safe.