TLS certificates — validity, expiry, and SSL posture
Domain Watchdog runs two separate certificate checks. One reads the live certificate and grades its runway — how many days until it expires, and whether the chain is even valid. The other probes the server's TLS posture — the protocols, ciphers and chain it actually offers — to catch a technically-valid cert served over weak, outdated TLS.
Under “Certificates & TLS” there are two distinct signals. The first, “TLS certificate”, is the heavyweight — it carries the single largest weight of any check in the grade — because an expired or untrusted certificate breaks the site for every visitor. The second, “TLS/SSL posture”, is a lighter but still meaningful check on how the server negotiates TLS.
The TLS certificate check reads the live certificate the server presents and looks at two things at once: is the chain valid and trusted, and how much runway is left. It passes when the chain is valid and there are more than 30 days before expiry. It warns when the chain is valid but expiry is inside 7 to 30 days — time to renew. It fails when there are fewer than 7 days left, when the certificate has already expired, or when the chain is invalid or untrusted at all — a self-signed certificate, one issued for the wrong host, or a broken intermediate — no matter how many days of runway it claims.
The TLS/SSL posture check does a multi-handshake probe of the server. It fails when the server still offers TLS 1.0 or 1.1, when it accepts a weak cipher (RC4, 3DES, DES, NULL, EXPORT or anonymous), or when the chain it serves is incomplete or untrusted. It passes when the server sticks to modern protocols, offers TLS 1.3, uses strong ciphers, and serves a complete, trusted chain. In between — for example a server on TLS 1.2 that doesn't offer 1.3 — it warns: acceptable, but not ideal.
An untrusted chain is a hard fail even with plenty of runway. A certificate that's self-signed, issued for the wrong hostname, or served with a broken intermediate fails the TLS certificate check regardless of how many days remain — because visitors see a security warning today, not in 90 days.
These are two separate signals for a reason. Certificate runway matters far more than posture — its weight is more than double the posture check's — so a healthy, trusted, long-runway certificate keeps most of the grade even if the posture check flags an older protocol.
Frequently asked questions
What's the difference between the two certificate checks?
“TLS certificate” reads the live certificate and grades its runway and whether the chain is valid and trusted — it's the highest-weighted check in the grade. “TLS/SSL posture” probes how the server negotiates TLS: the protocols, ciphers and chain it actually offers.
When does the certificate check warn versus fail?
It passes with a valid chain and more than 30 days of runway. It warns with a valid chain and 7–30 days left. It fails with fewer than 7 days, an expired certificate, or an invalid/untrusted chain (self-signed, wrong host, or broken intermediate) — the last regardless of runway.
My certificate is valid but the posture check flagged it — why?
The posture check looks beyond validity at how the server negotiates TLS. It flags servers that still offer TLS 1.0/1.1, accept a weak cipher (RC4, 3DES, DES, NULL, EXPORT or anonymous), or serve an incomplete/untrusted chain. A server on TLS 1.2 that doesn't offer 1.3 gets a warning — acceptable but not ideal.
How much does the certificate affect my grade?
A lot. The TLS certificate check carries the single largest weight of any check, since an expired or untrusted cert breaks the site for everyone. The posture check is lighter — less than half the weight — so certificate runway drives the grade far more than posture does.