# Certificate renewal planner > Work out a TLS certificate's validity, whether it fits the CA/Browser Forum 47-day schedule, and the renewal cadence it implies — all offline. - Tool: https://ronutz.com/en/tools/cert-renewal-planner - Family: Certificates & PKI --- ## What it does Give the tool a certificate's start and end dates, its `notBefore` and `notAfter`, and it works out the practical consequences: how long the certificate is valid, which phase of the CA/Browser Forum's shrinking-validity schedule it was issued under and whether its length fits that phase's cap, how many renewals per year that cadence implies, the reuse windows for domain and identity validation in that era, and a recommended lead time and "renew by" date. It is pure date math and runs entirely offline. ## Why certificate lifetimes are shrinking Publicly trusted TLS certificates have been getting shorter for years, and the CA/Browser Forum's ballot SC-081v3 sets out a schedule that steps the maximum validity down from 398 days, through 200 and 100 days, to 47 days by 2029. Shorter certificates limit how long a compromised or mis-issued certificate stays useful, but they also make manual renewal impractical, which is the point: the schedule effectively forces automation. Two related windows shrink alongside the validity: the period for which a domain-control validation (DCV) can be reused, and the period for which validated identity information (SII) can be reused, so more of the process must be repeated more often. ## What the plan tells you From just the two dates, the tool derives the whole picture: - the **validity length** and which SC-081v3 phase it corresponds to, with a clear yes or no on whether the length is within that phase's cap; - the **renewal cadence**, expressed as renewals per year, both for the current cap and for each future cap, so you can see how the workload grows; - the **DCV and SII reuse windows** that apply to the issuance era; and - a **recommended renewal lead time** and the resulting "renew by" date, so a renewal completes before expiry rather than at the wire. ## Automation is the real answer Because the endpoint of this schedule is a 47-day certificate, renewing by hand many times a year per certificate does not scale. The standard answer is the ACME protocol (RFC 8555), the automated issuance and renewal that tools like certbot use; the planner's cadence numbers are really an argument for adopting it. ## Using it Enter the certificate's `notBefore` and `notAfter` dates and read the validity, the schedule fit, the renewal cadence, the reuse windows, and the recommended renewal date. The calculation is a pure function of those two dates; whether a certificate is expired right now is shown separately, against your device clock. ## Standards and references - [CA/Browser Forum — Ballot SC-081v3 (schedule of reducing validity and data reuse periods)](https://cabforum.org/) - the 398 → 200 → 100 → 47-day TLS validity schedule and the DCV/SII reuse reductions (2026-2029) - [RFC 5280 — Internet X.509 PKI Certificate and CRL Profile](https://www.rfc-editor.org/rfc/rfc5280) - certificate validity period semantics (notBefore / notAfter) - [RFC 8555 — Automatic Certificate Management Environment (ACME)](https://www.rfc-editor.org/rfc/rfc8555) - the automated issuance/renewal that shortened lifetimes make necessary ## Related reading - [ACME on BIG-IP: from DevCentral scripts to a native client](https://ronutz.com/en/learn/bigip-acme-certificate-automation.md): How Let's Encrypt and other ACME certificate automation works on F5 BIG-IP: the native ACMEv2 client introduced in BIG-IP 21.1.0 (provisioning, renewal, and deployment for any ACMEv2 CA), the community dehydrated-based solutions that came before it, BIG-IQ's centralized Let's Encrypt CA management profile, and where the shared ACME concepts and rate limits fit. - [ACME on FortiGate: a built-in client for the box's own certificate](https://ronutz.com/en/learn/fortigate-acme-certificate-automation.md): How FortiOS's native ACME support obtains and renews a Let's Encrypt certificate for the FortiGate itself: the public-IP and FQDN requirements, the single-name SAN constraint, the TLS-ALPN-01 and HTTP-01 challenges (and which FortiOS versions support them), the GUI and CLI configuration, and how this differs from BIG-IP's native client. - [Certificate validity windows: notBefore, notAfter, and renewal lead time](https://ronutz.com/en/learn/certificate-validity-windows.md): How a certificate's lifetime is defined by two timestamps, how that length is measured against the cap, why validity is not the same as time remaining, and how to choose a renewal lead time. - [DCV and SII reuse: the validation cadence behind the renewal cadence](https://ronutz.com/en/learn/dcv-and-sii-reuse.md): Issuing a certificate means proving domain control and, for OV/EV, organization identity. SC-081v3 shrinks how long those proofs can be reused — DCV to 10 days by 2029 — which reshapes renewal as much as validity does. - [Let's Encrypt: the free CA and its rate limits](https://ronutz.com/en/learn/lets-encrypt.md): What Let's Encrypt is, why its certificates are short-lived, and how its rate limits actually work: the per-registered-domain and per-account limits, the exact-set and authorization-failure limits, and why ARI renewals are exempt from all of them. - [Public vs private PKI: which certificates SC-081v3 governs](https://ronutz.com/en/learn/public-vs-private-pki.md): The 47-day schedule binds publicly trusted TLS certificates only. What separates public from private PKI, why internal CAs are exempt, and how to read the planner's compliance verdict for an internal certificate. - [Renewing before expiry: lead time, ACME, and ARI](https://ronutz.com/en/learn/renewing-before-expiry.md): Why late renewal causes outages, how ACME automates issuance and renewal, how the ARI extension lets a CA steer the renewal window, and how to pick a lead time that leaves room to retry. - [The 47-day era: how TLS certificate lifetimes are shrinking](https://ronutz.com/en/learn/tls-certificate-lifetimes.md): The CA/Browser Forum's SC-081v3 schedule takes maximum public TLS validity from 398 days down to 47 by 2029, in three steps. What the phases are, why 47, and what it does to renewal volume.