Understand what your scan results mean / SSL/TLS
SSL/TLS certificate chains and why expiry catches people off guard
A certificate doesn't just need to be valid — it needs a complete, trusted chain back to a root your visitor's browser already trusts. Here's how that chain works, and why an expiry date sneaks up on almost everyone.
When a browser connects to your site over HTTPS, your server doesn't just present one certificate — it presents a chain: your certificate (the "leaf"), signed by an intermediate certificate authority, which is itself signed by a root certificate that's pre-installed as trusted in the browser or OS. If any link in that chain is missing or expired, the whole connection is untrusted, even if your own certificate looks fine in isolation.
This is why a certificate can look valid when you check it directly but still show a browser warning for real visitors: a missing intermediate certificate is one of the most common real-world TLS misconfigurations, and it's invisible unless something actually validates the full chain the way a browser does.
Expiry catches people off guard for a structural reason, not a carelessness one: most certificates last 90 days to a year, renewal is often automated (Let's Encrypt, most CDNs) but automation itself can silently fail — a DNS change, a renewal script that stops running, a service migration that leaves an old cert path referenced somewhere. Nothing alerts you until the certificate actually expires and the site goes down for every visitor.
What to do: don't just check "is the certificate valid today" — check days-remaining on a recurring basis, and treat anything under 14 days as urgent regardless of whether renewal is "supposed to be automatic." Korantix's SSL/TLS check reads the live chain the same way a browser does, including hostname match and issuer, not just the expiry date in isolation.