My certificate "expired" — what does that actually break?

My certificate "expired" — what does that actually break?

When a certificate passes its notAfter date, what fails and why? The encryption itself is unaffected; what collapses is the browser's willingness to trust the identity binding.

Every X.509 certificate carries a validity window (notBefore / notAfter, RFC 5280). The moment the client's clock passes notAfter, path validation rejects the certificate as expired and the browser shows a full interstitial — even though the AES session keys would still work perfectly. Trust is time-boxed deliberately: short lifetimes limit the blast radius of a key compromise that no one noticed.

The industry has been shortening these windows aggressively. Maximum certificate lifetime fell from ~39 months to 825 days (2018), then to 398 days (Sept 2020, enforced by Apple/Google/Mozilla, not the CA/Browser Forum, which deadlocked). The CA/Browser Forum has since voted to step lifetimes down toward 47 days by 2029.

The practical lesson: a certificate is a perishable credential, not a one-time install. The shorter the maximum lifetime trends, the more manual renewal becomes untenable — which is the entire argument for automation (ACME, the protocol behind Let's Encrypt).

Further reading: RFC 5280 section 4.1.2.5; CA/Browser Forum ballot SC-081 (lifetime reduction).

Bottom line: expiry breaks trust, not crypto. As maximum lifetimes shrink toward weeks, automated renewal stops being optional.