47-day SSL certificates: 2026–2029 schedule and how to prepare

Publicly trusted TLS certificates will be valid for at most 47 days from March 15, 2029. CA/Browser Forum Ballot SC-081v3, adopted in April 2025, set the steps: 200 days from March 15, 2026, 100 days from March 15, 2027, then 47 days. Domain validation reuse shrinks to 10 days, so in practice renewal has to be automated.

The schedule

The limits apply to the issuance date of each certificate, and they are written into sections 4.2.1 and 6.3.2 of the Baseline Requirements. Certificates already issued keep their original validity.

The Baseline Requirements add a "SHOULD NOT" one day below each limit (397, 199, 99 and 46 days), which gives CAs a margin for clock and rounding differences. The same 2026 change also tightened the definition of a short-lived subscriber certificate to seven days or less.

Ballot SC-081v3 passed with 25 certificate issuers voting yes, none voting no and five abstaining; all four certificate consumers that voted (Apple, Google, Microsoft and Mozilla) voted yes. Voting closed on April 11, 2025.

Max validity (days)
398 |████████████████████████████████████████|  until 2026-03-15
200 |████████████████████                    |  2026-03-15
100 |██████████                              |  2027-03-15
 47 |█████                                   |  2029-03-15

The certificate validity timeline shows the longer history, from five-year certificates to today, and the validity calculator tells you the maximum lifetime for a given issuance date.

Why lifetimes are shrinking

Shorter lifetimes are a substitute for revocation that never worked well, plus a forcing function for agility.

• Revocation is unreliable. Browsers do not block on OCSP, CRLs are large, and Let's Encrypt shut down its OCSP service in 2025. A compromised or mis-issued certificate effectively stays usable until it expires, so a shorter expiry caps the damage. See OCSP and CRL.
• Domain ownership changes. A domain can be sold or expire while its old certificate stays valid for months. With 10-day validation reuse and 47-day certificates, stale proof of control disappears quickly.
• Key exposure windows. A private key copied from a server is useful to an attacker only while a certificate for it is valid.
• Cryptographic agility. Moving the web to new algorithms, including post-quantum ones, or replacing a distrusted CA is far easier when every certificate in the world turns over in weeks rather than years.
• Automation as the norm. Root programs want certificate management to be hands-off. The Chrome Root Program policy says routine issuance and renewal should not involve human input except for identity verification of OV and EV certificates.

Who is affected and how

The change hurts in proportion to how manual your certificate handling is today.

The Baseline Requirements govern publicly trusted certificates only. A private CA used by your own machines is outside their scope, which is one more reason to move internal, device and client-certificate use cases off public certificates (see mTLS).

Subscription length versus certificate lifetime

What you buy from a commercial CA is a subscription, not a single certificate, and the two diverge more each year. Within a paid term you can reissue the certificate as often as needed at no extra cost; each issued certificate has a shorter maximum life.

Here is a one-year subscription started on three different dates, assuming you renew about two-thirds of the way through each certificate's lifetime:

Multi-year plans keep working the same way. Read the CA's terms for whether reissues are unlimited and whether they offer ACME, because at 11 or 12 issuances a year the installation step is the real cost.

Let's Encrypt is moving faster

Let's Encrypt is ahead of the Baseline Requirements schedule and uses ACME profiles to let users opt in early. Its December 2025 announcement sets these dates:

An opt-in shortlived profile issues certificates valid for about six days. Let's Encrypt recommends that clients use ACME Renewal Information (ARI, RFC 9773) to decide when to renew, or otherwise renew at about two-thirds of the certificate's lifetime; it warns explicitly that a hard-coded 60-day renewal interval will no longer be enough. It is also working on a new validation method, DNS-PERSIST-01, in which the DNS TXT record does not change on each renewal, so the ACME client does not need DNS write access. As of November 2026 check the Let's Encrypt documentation for its status before relying on it.

What 10-day validation reuse means in practice

The 10-day DCV reuse period is the part that breaks manual workflows, even more than the 47-day lifetime. Today many people validate a domain once by adding a DNS TXT record or uploading a file, then reissue for months without repeating it. From March 15, 2029 a CA can rely on that proof for only 10 days, so nearly every issuance needs a fresh challenge.

2026:  validate ──────────────── 200-day reuse window ───────────────▶
       issue      issue (reuses validation)      issue (reuses)

2029:  validate ─ 10 days ▶   validate ─ 10 days ▶   validate ─ 10 days ▶
       issue                  issue                  issue
       (each 47-day certificate effectively needs its own validation)

For HTTP-01 that is easy if the ACME client runs on the web server. For DNS-01, which wildcard certificates require, the client needs API access to your DNS provider. See the ACME protocol for how the challenges work.

Common misreadings

Existing certificates do not stop working on the cutoff dates, and the ballot covers only publicly trusted TLS server certificates.

• "My one-year certificate stops working on March 15, 2026." No. The limits apply to certificates issued on or after each date. A 398-day certificate issued on March 14, 2026 stays valid until its own expiry date in 2027.
• "Renew on day 47." A 47-day certificate should be renewed around day 30, leaving more than two weeks to notice and fix a failed renewal. The same two-thirds rule applies to 100-day and 200-day certificates.
• "This covers every certificate." Ballot SC-081v3 changes the TLS Baseline Requirements only. Code signing, S/MIME and private-CA certificates follow their own rules.
• "Shorter certificates are less secure because they change more often." Rotation itself is not a risk when it is automated; the risk is a manual process that people forget. Short lifetimes reduce how long a leaked key or mis-issued certificate stays usable.
• "Validation reuse means the same as certificate lifetime." They are separate limits. In 2029 a certificate can last 47 days, but the domain proof behind it can be at most 10 days old when the certificate is issued.
• "Wildcard certificates avoid the problem." A wildcard certificate is still limited to 47 days and requires DNS-01 validation, so it needs DNS automation more, not less.

A preparation checklist

Start now; 200-day certificates are already in force and 100-day ones arrive in March 2027.

1. Inventory every public certificate. Search Certificate Transparency logs for your domains with CT search; you will find certificates on hosts nobody remembers.
2. Automate issuance and installation. Use ACME wherever possible, including with commercial CAs that support it. For appliances, script the vendor API. Automating certificate renewal covers the patterns.
3. Automate domain validation. Give the ACME client DNS API credentials scoped to _acme-challenge records, or run HTTP-01 on the host itself.
4. Renew on signals, not fixed dates. Enable ARI where your client supports it; otherwise renew at two-thirds of the lifetime.
5. Monitor independently. Check what the server actually serves, not what the ACME client reports it renewed. Alert at about one-third of lifetime remaining.
6. Remove leaf pinning. Mobile apps and devices that pin a certificate will break at every renewal.
7. Move non-web uses to a private CA. Client certificates, device identities and internal services do not need public trust.

For background on the rule-making process, see the Baseline Requirements and the CA/Browser Forum.