Direct answer: the maximum validity of publicly trusted TLS certificates is falling from 398 days to 200 days (from 15 March 2026), 100 days (from 15 March 2027) and 47 days (from 15 March 2029); domain/IP validation-data reuse periods fall in parallel to 200/100/10 days. The 200-day stage is already in force; the next hard deadline is 100 days on 15 March 2027. This is not mainly a certificate-price problem but an operations-frequency problem: one certificate needs at least 1.8 renewals/year (200 days), 3.65 (100 days), 7.8 (47 days); 1,000 certificates at 47 days mean about 7,766 renewals/year, or about 21 per day. Manual uploads cannot keep up. Start now, not in 2029: build the inventory, ACME issuance, automated deployment, expiry/CT monitoring and rollback first.
This guide is for website/e-commerce operations, SRE, platform engineering, CDN/load-balancer management and procurement teams. It explains the CA/Browser Forum Baseline Requirements 200/100/47-day schedule, renewal workload, ACME automation, common failure modes and a 90-day implementation checklist. Rules come from the current CA/Browser Forum Baseline Requirements (including the 15 March 2026, 2027 and 2029 effective clauses), Ballot SC-081v3, IETF RFC 8555 (ACME) and RFC 8657 (ACME CAA accounturi/validationmethods), all accessed 8 November 2026. Official rule facts, editorial calculations and implementation advice are kept separate. This is not compliance or procurement advice.
(1) 200 days is already in force (15 March 2026), 100 days arrives on 15 March 2027 and 47 days on 15 March 2029; domain/IP validation reuse falls to 200/100/10 days. (2) At 47 days, 1,000 certificates mean about 7,766 renewals/year; manual processes will miss some. ACME plus automated deployment and monitoring is the default architecture. (3) A multi-year subscription is not a multi-year certificate; every certificate is still capped at 200/100/47 days. Procure on issuance volume/automation, not "buy once, install for years".
Timeline: 398 -> 200 -> 100 -> 47 days
The current CA/Browser Forum Baseline Requirements set three hard dates: from 15 March 2026, Subscriber Certificates are capped at 200 days; from 15 March 2027, 100 days; from 15 March 2029, 47 days. Domain and IP address validation-data reuse periods fall in parallel to 200/100/10 days. Subject Identity Information reuse remains 398 days at 15 March 2026, so do not put every validation type on the same cadence. The rules also define a day as 86,400 seconds; fractional seconds/leap seconds add a day, so the official text recommends not issuing at the maximum by default.
| Certificate issued on/after | Maximum validity | Domain/IP validation reuse | Other changes |
|---|---|---|---|
| Before 15 Mar 2026 | 398 days | 398 days | Previous rules |
| 15 Mar 2026 - 14 Mar 2027 | 200 days | 200 days | DNSSEC validation, IP reverse-zone ban, Precertificate Signing CA sunset |
| 15 Mar 2027 - 14 Mar 2029 | 100 days | 100 days | ACME accounturi/validationmethods (RFC 8657) |
| 15 Mar 2029 onward | 47 days | 10 days | Shorter cycles become normal |
Sources: CA/Browser Forum Baseline Requirements current text (Sections 6.3.2, 4.2.1 and the effective-date table); Ballot SC-081v3 (passed 11 April 2025, effective 16 May 2025). Editorial summary; "maximum validity" means publicly trusted TLS Subscriber Certificates; internal/private CAs are not bound by the same BR.
Renewal workload: from once a year to eight times
Assuming renewal exactly at expiry with no overlap, renewals per certificate per year are about 365/validity: 0.92 at 398 days, 1.83 at 200, 3.65 at 100 and 7.77 at 47. For 100/1,000 certificates that is 183/1,825 (200 days), 365/3,650 (100 days) and 777/7,766 (47 days). If 20% remain manual, 1,000 certificates at 47 days mean about 1,553 manual renewals/year, or about 4.3 per working day, before retries, approvals and deployment windows.
| Maximum validity | Renewals/cert/year | 100 certs/year | 1,000 certs/year | 20% manual at 1,000/year |
|---|---|---|---|---|
| 398 days | about 0.92 | about 92 | about 917 | about 183 |
| 200 days | about 1.83 | about 183 | about 1,825 | about 365 |
| 100 days | about 3.65 | about 365 | about 3,650 | about 730 |
| 47 days | about 7.77 | about 777 | about 7,766 | about 1,553 |
Editorial calculation: 365/validity, assuming renewal at expiry with no overlap; real renewal windows usually start earlier, so counts may be higher. Excludes multi-domain/SAN, wildcards, multi-region deployment, CDN/LB upload and approval time; "20% manual" is an example.
Which certificates are affected, which are not
The rules target publicly trusted TLS Subscriber Certificates: certificates issued by a CA trusted by browsers/operating systems and used for public HTTPS/API/email and similar services. Certificates from internal/private CAs are not subject to the same CA/B Forum BR validity limit, but may be constrained by enterprise policy, sector regulation or client requirements. If a private root is imported into public trust stores, or the certificate is used on the public internet, assess it under public-trust rules. Also note: a subscription/contract can be multi-year, but each issued certificate is still capped at 200/100/47 days; CAs usually fulfil multi-year contracts through multiple issuances.
| Object | Subject to 200/100/47 days? | Check first |
|---|---|---|
| Public HTTPS website/API | Yes | Publicly trusted CA, certificate type |
| Certificates on CDN/load balancer | Yes | Upload/automated deployment, rollback |
| Internal/private CA certificates | Generally not the same BR | Enterprise policy, client trust, compliance |
| Self-signed/test certificates | Not public BR | Do not use in production/public internet |
| Multi-year subscription/contract | Each certificate still capped | Contract fulfilled by multiple issuances? |
| IoT/embedded/email/database TLS | Depends on public trust/client | Device updateability, trust store |
Sources: CA/Browser Forum Baseline Requirements (scope and Section 6.3.2); editorial summary. Internal CA, client trust and sector rules follow enterprise standards/applicable regulation.
Automation architecture: ACME + deployment + monitoring
At 47 days, the core question is not "which CA" but "can issuance, validation, deployment, verification and rollback run unattended?" The standard approach is ACME (RFC 8555): the client requests a certificate, the CA validates domain control via HTTP-01, DNS-01 or TLS-ALPN-01, a deployer pushes the certificate to load balancers/CDNs/applications, and monitoring checks expiry, chain, CT and the actual handshake. From 15 March 2027, CAs must also process ACME accounturi/validationmethods parameters (RFC 8657), letting CAA records bind an account and validation method and reducing mis-issuance risk.
| Component | Purpose | Implementation notes |
|---|---|---|
| Certificate inventory | Know what exists, where and who owns it | Domain/SAN, CA, expiry, deployment location, owner, automated/manual |
| ACME client | Automated request/renewal | DNS-01/HTTP-01 support; retries, rate limits, logs |
| Validation method | Prove domain control | DNS-01 for wildcards/many domains; HTTP-01 needs public reachability |
| Deployer | Push new certificate to CDN/LB/app | Atomic update, canary, rollback, full chain |
| Monitoring | Catch expiry/chain/deployment failures | 30/14/7-day alerts; CT logs; external handshake probe |
| CAA/account binding | Restrict who can issue | RFC 8657 accounturi/validationmethods (CAs must process from 15 Mar 2027) |
| Emergency path | CA/validation/deployment failure | Backup CA, backup validation path, manual fallback, rollback drill |
Sources: IETF RFC 8555 (ACME), RFC 8657 (ACME CAA accounturi/validationmethods), CA/Browser Forum BR 15 March 2027 clauses; editorial implementation advice.
Common failure modes: why automated renewal still expires
Automated renewal usually fails in the validation/deployment/monitoring chain, not in ACME itself: expired DNS API credentials, CAA records that block the new CA, HTTP-01 blocked by a WAF, wildcard certificates requiring DNS-01, a CDN receiving only the leaf certificate without the intermediate chain, only one of several load-balancer nodes updated, monitoring that checks the file but not the live handshake, clock drift, CA rate limits or a locked account. A 47-day cycle turns these from a once-a-year incident into a monthly-or-more event; drills and alerts are mandatory.
| Failure mode | Symptom | Control |
|---|---|---|
| Expired DNS API credentials | DNS-01 validation fails | Least privilege, rotation, dual credentials |
| CAA blocks the new CA | Issuance rejected | Check CAA before changes; bind accounturi |
| WAF/firewall blocks HTTP-01 | Validation 403/timeout | Allow the validation path or use DNS-01 |
| Only leaf certificate deployed | Chain errors for some clients | Deploy full chain; external handshake test |
| Only one node/region updated | Intermittent expiry | Atomic release, per-node verification, canary |
| Monitoring checks files only | File new, live cert old | Probe the actual certificate/expiry externally |
| CA rate limit/account lock | Renewal queue fails | Renew early, backup CA, alerts |
| Clock/timezone error | Early/late activation | NTP, UTC, safety margin |
Editorial failure list and controls, not an official checklist; validation, CAA, CA rate limits and deployment constraints follow CA/client/platform documentation.
Procurement and CA selection: a multi-year subscription is not a multi-year certificate
Separate the contract/subscription term from the certificate validity: a multi-year contract may allow multiple issuances, but each certificate is still capped at 200/100/47 days. Ask the CA about ACME support, DNS-01/wildcards, API rate limits, CAA accounturi/validationmethods, retry/alerting, chain/root update policy, backup CA, SLA and whether pricing is per certificate/domain/issuance. Do not compare only the "annual certificate price"; model annual issuance count at 47 days.
| Procurement question | Why it matters |
|---|---|
| ACME support? Which validation methods? | Determines automated renewal/wildcards |
| API rate limits/concurrency/retries? | 1,000 certificates renewing together can hit limits |
| CAA accounturi/validationmethods support? | CAs must process RFC 8657 parameters from 15 March 2027 |
| How are chain/root updates communicated? | Chain changes can break some clients |
| Backup CA/multi-CA support? | Enables switching when one CA fails |
| Pricing per certificate/domain/issuance? | Issuance volume rises sharply at 47 days |
| SLA/support/incident response? | Expiry is a production incident, not just a purchase |
Editorial procurement checklist, not a vendor recommendation; contracts, prices and SLAs follow the CA's quote and terms.
90-day implementation checklist
Use the first 90 days to make inventory, automated issuance, automated deployment, monitoring and drills work; do not wait for 15 March 2027. The order is inventory, ACME/validation choice, deployment automation, monitoring/alerting, failure drills, procurement/contract. The 47-day stage simply runs the same process more often; if 200 days is still manual, 100 days will break.
| Phase | Action | Output |
|---|---|---|
| Weeks 1-2 | Inventory all public TLS certificates: domain/SAN, CA, expiry, deployment location, owner | Certificate list, risk ranking |
| Weeks 2-3 | Choose ACME client/CA/validation; confirm DNS API, CAA and WAF allowlisting | Automation design, permission model |
| Weeks 3-5 | Run issuance -> deployment -> handshake verification -> rollback in test/staging | Playbook, rollback steps |
| Weeks 5-7 | Connect monitoring: 30/14/7-day expiry, CT, external handshake, chain checks | Alerts, dashboard |
| Weeks 6-8 | Drill CA failure/validation failure/deployment failure | Drill report, backup path |
| Weeks 8-10 | Capacity/rate-limit/concurrency test at 47-day volume | Rate parameters, batching policy |
| Weeks 10-12 | Update procurement/contract/SLA; clarify issuance volume for multi-year subscriptions | Procurement conclusion, budget |
Editorial implementation advice, not an official template; ACME/CA/deployment/monitoring implementation follows enterprise architecture and vendor documentation.
FAQ
Is the 200-day limit already in force?
Yes. Publicly trusted TLS Subscriber Certificates issued on or after 15 March 2026 are capped at 200 days; domain/IP validation-data reuse is also 200 days. Certificates issued earlier under 398-day rules remain valid until expiry.
When do 100 and 47 days start?
100 days from 15 March 2027, and 47 days from 15 March 2029; domain/IP validation reuse becomes 100 days and 10 days respectively.
Do internal certificates have the same limit?
The CA/Browser Forum BR applies to publicly trusted certificates. Internal/private CAs are generally not subject to the same validity limit, but enterprise policy, client trust or sector regulation may apply. If a private root is in public trust stores or used publicly, assess it under public-trust rules.
Can a multi-year certificate purchase bypass the limit?
No. A multi-year contract can cover multiple issuances, but each issued certificate is still capped at 200/100/47 days. Procure on annual issuance volume/domain count/automation, not "buy once for years".
Is ACME mandatory?
Not mandatory, but manual renewal is impractical at 100/47 days. ACME (RFC 8555) is the standard automated issuance/renewal protocol; commercial CA APIs/agents can also work, but you still need deployment, monitoring and rollback.
What about wildcard certificates?
Wildcards usually use DNS-01 validation; the certificate is still capped at 200/100/47 days. Limit DNS API permissions, bind CAA accounturi, and prepare manual fallback for validation/deployment failures.
What about chain/root changes?
Deploying only the leaf certificate, missing the intermediate chain, or failing to sync root/chain updates can break some clients. Test the actual handshake externally after deployment, monitor the chain/expiry and keep a rollback path.
How do we avoid certificate expiry?
Inventory + automated renewal + automated deployment + external handshake monitoring + 30/14/7-day alerts + CT monitoring + regular drills; keep a backup CA/validation path for critical domains.
Research method and limitations
This article separates "official rule facts" from "editorial calculations." The 200/100/47-day schedule, domain/IP validation reuse of 200/100/10 days, the 15 March 2026 DNSSEC/IP reverse-zone/Precertificate Signing CA changes, the 15 March 2027 ACME accounturi/validationmethods requirement and the 15 March 2029 47-day/10-day limits come from the current CA/Browser Forum Baseline Requirements (Sections 6.3.2, 4.2.1 and the effective-date table) and Ballot SC-081v3. The ACME protocol comes from IETF RFC 8555, and the CAA parameters from RFC 8657. Renewal counts, manual percentages, the 90-day checklist and procurement questions are editorial.
Eight limitations: (1) this is not legal/compliance/procurement advice; (2) only publicly trusted TLS Subscriber Certificates are covered, not private CA/client trust/sector regulation; (3) renewal counts assume renewal at expiry and vary with windows, SAN/wildcards and deployment nodes; (4) CA prices, rate limits, SLAs and contracts are excluded; (5) ACME client/CA implementation differences are not covered; (6) CT/OCSP/CRL, chain/root updates and IoT device constraints are not covered in depth; (7) multi-CA/multi-region/multi-tenant architectures are not assessed; (8) rules may change, so recheck the CA/Browser Forum BR and CA/platform documentation before implementation.
Sources and basis
- CA/Browser Forum, Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (current): cabforum.org/working-groups/server/baseline-requirements/requirements. Section 6.3.2 maximum validity, 4.2.1 validation-data reuse, effective-date table. Accessed 8 November 2026.
- CA/Browser Forum, Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods (11 April 2025): cabforum.org/.../ballot-sc081v3. 200/100/47-day validity and 200/100/10-day reuse schedule, voting/effective information. Accessed 8 November 2026.
- IETF RFC 8555, Automatic Certificate Management Environment (ACME): rfc-editor.org/rfc/rfc8555. ACME issuance/validation/renewal protocol. Accessed 8 November 2026.
- IETF RFC 8657, ACME Profile for CAA accounturi and validationmethods: rfc-editor.org/rfc/rfc8657. CAA account/validation-method binding; BR requires CAs to process it from 15 March 2027. Accessed 8 November 2026.
Data cut-off 8 November 2026; validity/reuse periods follow the latest CA/Browser Forum BR and CA/platform documentation; this is not compliance, procurement or legal advice.