SSL Certificate Expiry Calculator

Every X.509 certificate carries a validity structure with a notBefore and a notAfter timestamp, and a relying client rejects the certificate outright once its own clock passes notAfter. The remaining lifetime is therefore just the difference between that timestamp and now, while the renewal date is the expiry less whatever buffer the operator chooses. Maximum lifetimes are not left to the issuer: the CA/Browser Forum Baseline Requirements have ratcheted them down repeatedly, from 39 months to 825 days in March 2018, and then to 398 days for certificates issued on or after 1 September 2020 after Apple announced it would enforce that limit in Safari. A further stepped reduction toward much shorter maximum lifetimes was adopted by the Forum in 2025, which makes automated issuance a requirement rather than a convenience. Buffer sizing follows from the validity period. Let us Encrypt issues 90-day certificates and advises renewing at the 30-day mark, roughly one third of the lifetime remaining, which leaves 30 days of retries before any user-visible failure; for a 398-day certificate a 30 to 60 day buffer serves the same purpose. Two limitations are worth stating plainly. Expiry of the end-entity certificate is only one failure mode among several: an expired or missing intermediate in the chain, a revoked certificate, a subject name that does not match the requested host, or significant clock skew on the client all produce the same browser error for the visitor. And month-based arithmetic is an approximation, since certificate authorities count validity in days, so an expiry computed by adding calendar months can differ from the issued notAfter value by a day or two.

The protocol these certificates serve began at Netscape, where SSL 2.0 shipped in 1995 and was quickly replaced by the substantially redesigned SSL 3.0 in 1996, credited to Paul Kocher working with Phil Karlton and Alan Freier. The IETF took over the specification and published TLS 1.0 as RFC 2246 in January 1999, followed by TLS 1.2 as RFC 5246 in 2008 and TLS 1.3 as RFC 8446 in August 2018. The certificate format itself is older and comes from a different lineage: X.509 originated in the ITU-T X.500 directory standards, with its first version issued in 1988. Governance of issuance practice arrived much later. The CA/Browser Forum was formed in 2005 by browser vendors and certificate authorities, and its Baseline Requirements took effect in July 2012, imposing the first common rules on validation and lifetime. Trust incidents drove the next phase. The compromise of the Dutch authority DigiNotar in 2011, which produced fraudulent certificates for Google domains, led to that authority being removed from browser trust stores entirely and motivated Certificate Transparency, designed by Ben Laurie and Adam Langley at Google and published as RFC 6962 in June 2013; Chrome required transparency logging for certificates issued after 30 April 2018. In parallel, the Internet Security Research Group launched Let us Encrypt into public beta in December 2015, and its issuance protocol was standardized as ACME in RFC 8555 in March 2019, making free automated certificates ordinary infrastructure.