A certificate expired at 2am and silently took down an internal service for hours before anyone noticed — how do you diagnose it fast, and how is this different from a chain-of-trust problem?
Quick Answer
An expired certificate fails a completely different check than a chain-of-trust problem: the chain can be perfectly valid and complete, but the client rejects the connection purely because the current date falls outside the certificate's notBefore/notAfter validity window. So openssl s_client showing a full, correct chain but a Verify return code 10, certificate has expired, immediately isolates it. The fast diagnosis is checking the expiry date directly rather than assuming a more complex chain or network issue; the real fix, though, is retroactive — automated expiry alerting and renewal well before this incident, because by the time you're debugging it live, the outage has already happened.
Detailed Answer
Think about a company badge that grants employees building access, set to automatically expire on a date printed on the card. Chain-of-trust is like the badge itself being fake or issued by an organization security doesn't recognize at all — the badge's authenticity is in question. Expiry is a completely different problem: the badge is 100 percent genuine, issued by a fully trusted authority, but the date printed on it has simply passed, and the door scanner is doing exactly its job refusing entry to an out-of-date badge, no matter how authentic it is otherwise.
TLS certificates carry an explicit validity window, notBefore and notAfter timestamps, specifically so compromised or outdated key material has a natural expiration, limiting how long a leaked or weakly-secured private key remains dangerous if it's ever exposed. This is a deliberate security design choice, not an arbitrary inconvenience, which is also why the industry, led by browser vendors, has steadily shortened maximum certificate lifetimes over the years, from years down to 398 days, with further reductions proposed, to force more frequent rotation across the entire ecosystem.
When a certificate expires, every TLS client's validation step explicitly checks the current time against the certificate's validity window as one of several independent checks, alongside chain validity, hostname match, and revocation status. Critically, this check can fail even when the certificate chain is otherwise completely valid and correctly served, which is why openssl s_client -connect internal-user-auth-service:443 -servername internal-user-auth-service showing a correct, complete chain but a nonzero verify return code specifically pointing to expiry, code 10, tells you immediately this is a pure date problem, not a chain, hostname, or trust problem — a much narrower, faster diagnosis path than starting from 'something's wrong with TLS' and checking everything from scratch.
In production, the operational lesson from a 2am silent expiry is almost never about handshake diagnostics — the real gap is that nothing was watching the expiry date proactively. Mature setups run a scheduled job, or use a dedicated certificate-monitoring tool, that checks every production certificate's days-until-expiry on a recurring basis and pages well before expiry, commonly at 30 days, 14 days, and 3 days out, specifically so a renewal failure, an ACME client bug, a manual process someone forgot, a certificate issued for the wrong hostname, gets caught and fixed during business hours, long before the actual expiry moment silently breaks things at 2am with nobody watching.
The non-obvious gotcha: an expired certificate incident often isn't actually about the certificate lifecycle at all — it's frequently a symptom of an automated renewal process that itself silently failed weeks earlier, a cron job for an ACME or Let's Encrypt renewal that started erroring out after a permissions change, or a rate limit hit against the CA, and nobody noticed because the only alert anyone had configured was 'did the certificate actually expire,' not 'is the automated renewal process itself healthy.' The fix isn't just renewing the certificate; it's diagnosing and repairing whatever quietly broke the automation days or weeks before the visible outage occurred.