Public TLS Certificates Now Max Out at 200 Days—Are Your Renewals Ready for 100?

Short answer: if a hosting platform or mature ACME client already renews certificates automatically, the new industry limits may require little day-to-day work. If certificates are still renewed manually, a custom system assumes roughly year-long lifetimes, or monitoring is built around fixed expiry dates, the next cut is close enough to test now.

The CA/Browser Forum's current Baseline Requirements limit newly issued publicly trusted TLS server certificates to 200 days from March 15, 2026. The maximum falls again to 100 days on March 15, 2027, then to 47 days on March 15, 2029.

This is not just a certificate-authority detail. Shorter lifetimes turn certificate management into an automation problem: more issuance events, more chances for DNS or HTTP validation to fail, more reloads and deployments, and less time to notice a broken renewal path before users see an expired certificate.

Rules checked: August 16, 2026. The dates and limits below come from the current CA/Browser Forum Baseline Requirements and current Let's Encrypt documentation.

What actually changed

The current public-TLS schedule is straightforward:

*Calculated as 365 ÷ maximum validity. Real systems should renew before expiry, so actual issuance frequency can be higher.

The important operational point is the multiplier. Compared with a 398-day certificate, a system running certificates all the way to the maximum lifetime would eventually perform roughly 8.5 times as many issuance cycles at a 47-day limit.

For a fleet of 10,000 certificates, the simplified capacity picture looks like this:

That does not mean every team suddenly has eight times the work. Good automation absorbs most of it. It does mean that manual steps, brittle validation, and fixed renewal assumptions become more expensive much faster.

Does this affect every TLS certificate?

No.

The CA/Browser Forum rules govern publicly trusted server certificates used in the Web PKI. An internal certificate issued by a private corporate CA is not automatically forced onto this exact 200/100/47-day schedule.

That distinction matters because the phrase "TLS certificate" covers several different setups:

The rule is therefore not "every certificate expires in 200 days." It is a maximum for newly issued publicly trusted certificates, and individual CAs can issue shorter certificates.

Let's Encrypt users are in a different position

Most Let's Encrypt users are already accustomed to shorter lifetimes.

Let's Encrypt's current documentation says its standard certificates still default to 90 days as of August 2026. That is already below both today's 200-day industry maximum and the 100-day maximum arriving in March 2027.

So a normal Let's Encrypt deployment does not suddenly need to move from a one-year certificate to a 200-day certificate. The more relevant question is whether its automation is ready for Let's Encrypt's own shorter-lifetime roadmap.

Let's Encrypt says:

• its opt-in tlsserver profile began issuing 45-day certificates on May 13, 2026;
• the default classic profile is scheduled to move from 90 days to 64 days on February 10, 2027;
• the default is scheduled to move to 45 days on February 16, 2028.

That is deliberately ahead of the industry-wide 47-day ceiling in 2029.

For a well-maintained ACME client, this should be boring. For a home-grown script that says "renew exactly 30 days before expiry," it is a good reason to stop assuming certificate lifetime is fixed.

The hidden second change: validation data expires faster too

Certificate lifetime is only half the schedule.

The CA/Browser Forum also shortened how long domain-control validation data can be reused. The current Baseline Requirements set the maximum reuse period for domain and IP validation at:

• 200 days for certificates issued from March 15, 2026;
• 100 days from March 15, 2027;
• 10 days from March 15, 2029.

That means a certificate platform cannot simply keep reissuing forever based on an old proof that somebody controlled a domain months or years ago.

For teams running their own certificate service, DNS automation therefore matters just as much as certificate installation. A perfect renewal scheduler still fails if the DNS challenge requires somebody to copy a TXT record by hand.

Why ACME Renewal Information matters now

The useful standard to know is ACME Renewal Information (ARI), RFC 9773.

ARI lets a certificate authority tell an ACME client a suggested window for renewing a specific certificate. That is better than every client independently guessing when renewal should happen from a fixed rule such as "30 days before expiry."

The RFC explains two practical benefits:

1. a CA can spread renewals across time instead of getting a large synchronized burst;
2. a CA can ask clients to renew earlier when an exceptional event, such as a mass revocation, requires it.

Let's Encrypt's current integration guide recommends checking ARI regularly and, as a fallback, renewing automatically when a certificate has roughly one-third of its total lifetime remaining.

The architectural lesson is bigger than one protocol feature: renew based on certificate state and CA guidance, not a hard-coded calendar assumption.

A decision framework: how much work is actually needed?

Case 1: A managed platform owns the certificate lifecycle

Examples include setups where a CDN, application platform, ingress service, or cloud load balancer automatically requests, validates, installs, and renews the public certificate.

The likely action is verification, not rebuilding.

Check the provider's current documentation and answer three questions:

• Does it explicitly manage renewal, not just initial issuance?
• Does it also handle domain validation when renewal occurs?
• Will it alert you if renewal becomes blocked by DNS, CAA, account, or domain-ownership changes?

If all three are covered, the shorter lifetime should mostly be the provider's operational problem.

Case 2: Certbot or another maintained ACME client handles renewal

This is usually a healthy position, but do not assume "installed once" means "still automated."

Certbot's current documentation recommends checking whether the installation created a cron job or systemd timer. It also provides a dry-run path for testing renewal without waiting for the real expiry window.

Useful checks include:

systemctl list-timers | grep certbot
certbot renew --dry-run

The second command is especially valuable because it tests more than the date calculation. It can expose broken challenge configuration, missing credentials, plugin problems, or deployment hooks before the production certificate is close to expiring.

Case 3: A custom ACME service manages many certificates

This is where the schedule deserves engineering work.

Audit for:

• ARI support or another lifetime-relative renewal strategy;
• retry behavior with jitter rather than synchronized retries;
• rate-limit handling;
• DNS/HTTP validation automation;
• secure credential rotation for DNS APIs;
• deployment hooks that actually reload the new certificate;
• observability for renewal failures;
• an inventory that proves which certificate is active on which endpoint.

A renewal service that can successfully issue a certificate is not necessarily a reliable certificate-management system. The hard part is proving it can do the same thing thousands of times, automatically, while individual dependencies fail.

Case 4: Someone still renews public certificates manually

This is the highest-risk setup under shorter lifetimes.

A 100-day maximum means the manual process can repeat several times a year per certificate. A 47-day maximum pushes the theoretical issuance frequency toward eight times per year even before adding a safety margin.

The practical next step is not "add more calendar reminders." It is to remove the human from normal renewal.

Use ACME where the CA supports it, move to a managed certificate service, or replace manual validation with an automated challenge path. Keep human approval for exceptional cases if required, but do not make routine expiry avoidance depend on somebody remembering a date.

The 20-minute certificate-automation audit

This is the useful check to run before the 100-day limit arrives.

1. Find the real certificate owner

For each public hostname, identify whether the certificate is managed by:

• the application platform;
• a load balancer or CDN;
• Certbot or another ACME client;
• an internal certificate service;
• a person following a manual process.

Do not stop at "we use Let's Encrypt." The CA is not the renewal mechanism.

2. Inspect the actual lifetime

For a local PEM certificate:

openssl x509 -in certificate.pem -noout -dates -issuer -subject

For a remote HTTPS endpoint, inspect the certificate from the deployed service rather than relying only on a file sitting on disk.

The goal is to confirm what users are actually receiving and how long that certificate remains valid.

3. Trigger a safe renewal test

Use the supported staging or dry-run mechanism for the client or platform.

A good test should exercise:

• domain validation;
• certificate issuance;
• secret/key handling;
• installation;
• service reload or deployment;
• post-renewal health checks.

If the test stops after downloading a new certificate but never proves the application is serving it, the most important step is still untested.

4. Break one dependency on purpose

In a staging environment, simulate one realistic failure: unavailable DNS credentials, blocked HTTP challenge, a denied API token, or a deployment hook that returns an error.

Then confirm two things happen:

1. the system retries safely;
2. somebody receives an alert early enough to fix the problem before expiry.

Shorter certificates make detection time part of the design.

5. Remove fixed-lifetime assumptions

Search code and operations documentation for rules such as:

• renew every 11 months;
• renew 30 days before expiry;
• alert only at 30 days;
• validation can be reused for one year;
• certificate inventory is reviewed quarterly.

Some of those rules may still work today. The problem is that they encode a certificate lifetime that the industry is actively shortening.

Prefer percentage/lifetime-relative logic or ARI-aware clients where available.

What is likely to break first

The certificate itself is usually not the weak part. The surrounding process is.

Manual DNS challenges

A TXT record that requires a human becomes increasingly painful as validation reuse periods shrink.

Forgotten deployment hooks

A renewal job can succeed while the web server continues serving the old certificate. Monitor the certificate visible from the network, not just the issuance log.

Stale DNS API credentials

Automated DNS validation is only automated while the credential still works. Scope the credential narrowly, rotate it safely, and make failures visible.

Expiry alerts designed for long-lived certificates

An alert that first fires 30 days before expiry once felt conservative for a 398-day certificate. Under much shorter lifetimes, monitoring should focus on renewal health continuously, not only on a distant expiry date.

Large synchronized fleets

If thousands of certificates were created together and the system uses the same fixed renewal threshold for all of them, they can all attempt renewal in the same window. ARI and jitter exist partly to avoid this kind of clustering.

What not to do

Do not react to the 47-day headline by forcing every certificate to 47 days today. The schedule is phased, and individual CAs have their own product timelines.

Do not assume a 90-day Let's Encrypt certificate means no future work. The certificate lifetime may already be short, but the renewal client, validation path, or deployment hook can still be brittle.

Do not treat a successful certificate order as proof that renewal is solved. The meaningful test is repeated unattended renewal plus correct deployment plus alerting when it fails.

And do not apply the public-Web-PKI schedule blindly to an internal private CA. Internal PKI may choose similar lifetimes for security reasons, but its policy is a separate decision.

What to watch next

The next industry deadline is March 15, 2027, when the public certificate maximum falls from 200 to 100 days and the domain-validation reuse ceiling also falls to 100 days.

Let's Encrypt's own default change arrives earlier: its current roadmap moves the default classic profile to 64-day certificates on February 10, 2027.

That makes the next six months a useful testing window. Teams do not need to wait until a certificate is 24 hours from expiry to discover that the renewal path depended on an old DNS token or a script written for one-year certificates.

Conclusion

Shorter public TLS certificates are not mainly a paperwork change. They are an industry push toward certificate lifecycles that are automated, observable, repeatable, and able to react to changing renewal windows.

If certificates are already fully managed, verify the provider's renewal guarantees and monitoring. If ACME is already automated, run a real dry-run and inspect the deployed result. If a human still performs routine renewal, the 100-day deadline is a clear reason to replace that workflow rather than add another reminder.

The 200-day limit is already here. The useful question is whether the system can keep renewing when the number becomes 100, then 47, without anybody having to think about the calendar.

Sources

Checked August 16, 2026:

• CA/Browser Forum — current Server Certificate Baseline Requirements
• CA/Browser Forum — Ballot SC081v3: schedule for reducing validity and data-reuse periods
• Chromium Root Program — reduced certificate lifetimes and validation reuse
• Let's Encrypt — Certificate Lifetime Rationale and Plans
• Let's Encrypt — Decreasing Certificate Lifetimes to 45 Days
• Let's Encrypt — Integration Guide for renewal and ARI
• RFC 9773 — ACME Renewal Information
• Certbot documentation — renewal and dry-run guidance