47-Tage-Zertifikatsrechner: Umstellung auf kurze Laufzeiten planen

The schedule behind the numbers

CA/Browser Forum ballot SC-081v3, adopted on 11 April 2025, rewrote two tables of the TLS Baseline Requirements. Section 6.3.2 caps how long a publicly trusted certificate may be valid, by the day it is issued: 398 days until 14 March 2026, 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029. Section 4.2.1 caps how long a CA may reuse a domain validation on the same dates: 398, 200, 100 and finally 10 days. The calculator carries those values exactly as the Baseline Requirements v2.3.1 state them and reads the step in force from the date of each issuance, so a certificate issued on 14 March 2026 is still judged against 398 days.

How validity is counted

The Baseline Requirements define the Validity Period from notBefore through notAfter inclusive, with a day of exactly 86,400 seconds and any remainder counting as one more day. A certificate that starts at midnight and is meant to last 200 days therefore ends at 23:59:59 on day 200, and a single extra second makes it 201 days — over the limit. For that reason §6.3.2 also says certificates SHOULD NOT exceed 199, 99 and 46 days; the calculator uses those recommended values as the default lifetime of new certificates, and flags a lifetime above them. In "my certificates" mode each line is checked against the limit of its own issuance date, so a certificate a CA should never have issued shows up as an error.

Renewals and validations per year

A renewal policy decides when a certificate is replaced. Most ACME clients renew once two thirds of the lifetime have passed, which keeps a third of the lifetime as a safety margin for failed attempts. The calculator turns the policy into a renewal interval for every period of the schedule, and from it the number of renewals per certificate per year. A policy that renews a fixed number of days before expiry does not shrink with the certificates: 30 days before expiry is generous for a 398-day certificate and means renewing every 17 days for a 47-day one. The calculator warns when a policy would renew on every run, or only at the moment of expiry.

The reuse period is the change most teams underestimate. Today a CA may reuse a validation for as long as the certificate lives, so validation happens once a year. From 2029 a validation older than 10 days cannot be reused, so nearly every renewal needs a fresh http-01 or dns-01 challenge (RFC 8555). The calculator counts validations separately for that reason and points to two remedies: following the CA's renewal window with ACME Renewal Information (ARI, RFC 9773), and the persistent DNS TXT validation method of ballot SC-088 (dns-persist-01), which proves control with a record that stays in place.

Counts and lists

With a number of certificates the yearly figures are steady-state averages: renewals are assumed to be spread evenly over the year, which is what a large fleet looks like. With a list, each certificate is simulated day by day from its own renewal date to the end of the plan, so the counts are exact for that list, and every certificate gets its days remaining, its renewal date under the policy and the lifetime its replacement may have. The plan starts today in UTC — the date the Baseline Requirements use — unless you choose another start.

What stays on your machine

Everything is computed in your browser. The page makes no request of its own: the schedule ships with the page, and the certificate names and dates you type never leave it. A share link carries the settings and the list in the part of the address after #, which browsers do not send to any server.

For the background — what CAs issue today, ACME profiles, ARI and monitoring that alerts in time — read 47-day TLS certificates: the schedule and what to automate. To check the certificates your servers actually present, use the bulk domain checker; to limit which CAs may issue for your domain at all, publish a CAA record with the CAA record generator.