Validity Period (notBefore / notAfter)

Every X.509 certificate states its validity as two timestamps, notBefore and notAfter, and clients reject it outside that window. For publicly trusted TLS certificates, the CA/Browser Forum caps the maximum validity by issuance date. Ballot SC-081v3 sets 398 days for certificates issued before 2026-03-15, 200 days from 2026-03-15, 100 days from 2027-03-15 and 47 days from 2029-03-15, so as of November 2026 the limit is 200 days.

Why it matters

Shorter lifetimes limit how long a mis-issued certificate or a stolen key stays useful, especially because revocation checking is unreliable, and they force automation. The cap has fallen steadily: 60 months for certificates issued after 2012-07-01, 39 months after 2015-04-01, 825 days from 2018-03-01 and 398 days from 2020-09-01. Let's Encrypt goes further than the maximum: its tlsserver profile has issued 45-day certificates since 2026-05-13, its shortlived profile issues six-day certificates, and its default classic profile moves to 64 days on 2027-02-10. Plan renewal with ACME, not with calendar reminders.

Example

openssl x509 -in cert.pem -noout -dates
openssl x509 -in cert.pem -noout -checkend 2592000 && echo "valid for at least 30 more days"

-checkend takes seconds and exits non-zero if the certificate expires within that time.

Common misconceptions

• A multi-year purchase means installing once. Multi-year subscriptions still deliver certificates within the current maximum; each one must be reissued and reinstalled.
• Shorter certificates are less secure. Lifetime does not affect encryption; shorter lifetimes reduce the damage from a compromised key.
• The device clock does not matter. A client with a wrong date reports valid certificates as expired or not yet valid.