TLS certificate lifetimes: 200 days now, 100 days in March 2027, 47 days in March 2029 — and domain validation falls to 10
The maximum lifetime of a publicly-trusted TLS certificate is 200 days, and has been since 15 March 2026. It drops to 100 days on 15 March 2027 and to 47 days on 15 March 2029. Those three steps are ballot SC-081, written into section 6.3.2 of the CA/Browser Forum's TLS Baseline Requirements, and they are the part everybody has written about.
The number that decides whether a human can stay in the loop is a different one. On the same three dates, the maximum domain-validation reuse period falls too — and it falls further. It was 398 days; it is 200 days now; it becomes 100 days in 2027; and on 15 March 2029 it becomes 10 days. The certificate cap shrinks by a factor of 8.5 over the schedule. The validation cap shrinks by a factor of 39.8.
From March 2029, a certificate may live 47 days but the domain validation behind it may be no more than 10 days old at the moment of issuance. You cannot validate a batch of domains and issue against it for the rest of the quarter. That is the clause that makes automation mandatory in practice, and it is section 4.2.1, not 6.3.2.
The step-down, both numbers together
Read from the two reference tables the Baseline Requirements print in sections 6.3.2 and 4.2.1. Each row is a record here, carrying the verbatim line from the effective-date table as its evidence.
| Certificates issued from | Max certificate validity | Max domain-validation reuse | Max subject-identity reuse |
|---|---|---|---|
| before 2026-03-15 | 398 days | 398 days | 825 days |
| 2026-03-15 (in force) | 200 days | 200 days | 398 days |
| 2027-03-15 | 100 days | 100 days | 398 days |
| 2029-03-15 | 47 days | 10 days | 398 days |
The third column stops moving and the second does not. Subject Identity Information reuse was cut once, from 825 days to 398, and the Baseline Requirements schedule no further step for it — its table has two rows where the other two have four. So the two validation clocks separate: the organisation details in an OV or EV certificate stay good for over a year, while proof that you still control the domain expires in a week and a half. If you plan renewals off a single "revalidation" figure, that is the divergence that will catch you.
The SHOULD NOT is one day below the MUST NOT, every time
Section 6.3.2 states each cap twice, and the two numbers are never the same:
Subscriber Certificates issued on or after 2026-03-15 and before 2027-03-15 SHOULD NOT have a Validity Period greater than 199 days and MUST NOT have a Validity Period greater than 200 days.
The same one-day gap appears at every step — 397/398, 199/200, 99/100, 46/47. The Baseline Requirements then explain why:
For the purpose of calculations, a day is measured as 86,400 seconds. Any amount of time greater than this, including fractional seconds and/or leap seconds, shall represent an additional day. For this reason, Subscriber Certificates SHOULD NOT be issued for the maximum permissible time by default, in order to account for such adjustments.
So a CA that issues at exactly 200 days can be pushed to 201 by a rounding artefact and be in breach. When a certificate authority tells you it issues 199-day certificates rather than 200, that is not vendor caution — it is the rule's own recommended number, and "the 47-day certificate" everyone plans for is really a 46-day certificate.
The 200-day cutover carried ten other obligations
15 March 2026 is remembered as the lifetime date. Eleven Baseline Requirements obligations took effect that day. Only one was the validity cap:
- DNSSEC validation became mandatory — back to the IANA root trust anchor, on all DNS queries used for domain validation (3.2.2.4) and on CAA record lookups (3.2.2.8.1), with local policy forbidden as a way to switch it off, and SERVFAIL no longer treatable as a pass
- Validation method 3.2.2.4.8 was withdrawn — CAs may no longer rely on it to issue
- Domain names ending in an IP reverse-zone suffix may no longer appear in certificates (4.2.2)
- Precertificate Signing CAs may no longer be used to issue precertificates (7.1.2.4)
Three of the eleven are the reuse and validity numbers in the table above. The other eight are operational changes that a renewal-date spreadsheet will not surface.
What is actually next
Of the 45 dated requirements in this dataset, 24 have already taken effect and 21 are still ahead, spread over 10 future dates:
| Date | Lands | What |
|---|---|---|
| 2026-09-15 | 1 | Sunset all remaining use of SHA-1 in certificates and CRLs (BR 7.1.3.2.1) |
| 2026-11-29 | 2 | Mozilla: WebTrust Network Security v2.0.5 and TLS Baseline v2.10 required for audit periods ending on or after this date |
| 2027-03-15 | 10 | The 100-day cap, 100-day validation reuse, five more validation methods withdrawn, two ACME accounturi/validationmethods rules — plus four Chrome deadlines including serverAuth-only EKU and automation for every subordinate CA |
| 2027-04-15 | 1 | Chrome removes root CAs whose key material was created in 2008–2009 |
| 2027-07-01 | 1 | Mozilla: Detailed Controls Report required for audit periods beginning on or after this date |
| 2027-09-15 | 1 | Chrome caps each CA owner at two self-signed roots in the store |
| 2028-03-15 | 1 | Three more validation methods withdrawn |
| 2028-04-15 | 1 | Chrome removes root CAs from 2010–2011 |
| 2029-03-15 | 2 | The 47-day cap and the 10-day validation reuse |
| 2029-04-15 | 1 | Chrome removes root CAs from 2012 to 14 April 2014 |
The next deadline is 16 days away and it is not about lifetimes at all. And 2027-03-15 is the busiest date in the whole schedule — ten separate obligations from two programmes at once, which is a materially different planning problem from "the cap halves".
Three programmes, three clocks
The maximum-lifetime story is one authority's. This dataset holds all three that bind a publicly-trusted CA, because their dates do not line up:
| Authority | Dated requirements held |
|---|---|
| CA/Browser Forum TLS Baseline Requirements | 29 |
| Google Chrome Root Program | 13 |
| Mozilla Root Store Policy | 3 |
Chrome's are the ones least likely to be on anyone's calendar, because they are not certificate deadlines — they are root-store deadlines keyed to how old a root's key material is. Roots created in 2006–2007 were due out on 15 April 2026; 2008–2009 goes in April 2027, 2010–2011 in April 2028, and 2012 to 14 April 2014 in April 2029. (Chrome's policy states the schedule; it does not publish a per-root confirmation, so we record the date it set, not the removal.) A chain that validates today stops validating in Chrome on a date determined by a key generated nearly twenty years ago.
Why the authority is not the page you find
On 5 August 2026 we asked two AI assistants when the 200-day, 100-day and 47-day maximums take effect. Between them they cited ten domains. cabforum.org was not one of them. Every cited source was a certificate vendor's marketing page or a consultancy blog — restatements of a table the CA/Browser Forum publishes in full, openly, with the dates in a column.
That is the gap this dataset exists to close: the body that sets the rule publishes the schedule as data, and is not the thing being quoted back to you.
What we can and cannot stand behind
The three sources were last read on 5 August 2026 and are due for re-reading by 3 November 2026. Each ballot the CA/Browser Forum passes adds rows to the effective-date table, so this schedule is expected to grow rather than settle. The changes feed will carry any revision as data — as of today it holds one entry, the initial snapshot of 5 August, because nothing has moved since.
On 27 of the 29 CA/Browser Forum records the effective date sits inside the quoted line itself, because the table prints date, section and requirement together — the cleanest evidence shape in this portfolio. The Chrome and Mozilla records are weaker in one specific way. Those two documents state a requirement in one place and its date somewhere else, usually a version table at the top, so on 14 of their 16 records the date is not inside the quoted sentence and is shown as unconfirmed on the record's own page. The requirement wording is quoted verbatim either way. Where the date matters to you, follow the source link and read the surrounding section rather than taking our word for it.
- The renewal-window calculator — give it an issue date, get the cap that applies, the next reduction, and how many renewals fall before a date you name
- All 45 dated requirements — one page each, with source and verbatim quote
- data.json — the whole schedule, machine-readable
- changes.xml — poll this instead of re-reading the Baseline Requirements
- How the records are made and checked
Every figure on this page is computed from those records. If one looks wrong, the record it came from links the document that states it — check us.