47-Day SSL Certificates: The Lifetime Schedule and What It Means

Publicly trusted TLS certificates are getting much shorter lifetimes. Under CA/Browser Forum ballot SC-081, which passed in April 2025, the maximum validity of a certificate issued on or after March 15, 2026 is 200 days, from March 15, 2027 it is 100 days, and from March 15, 2029 it is 47 days. Before these changes the limit was 398 days. The time a CA may rely on an earlier domain validation shrinks on the same schedule, ending at 10 days. As of today, the 200-day stage is already in force.

For any team still renewing certificates by hand, this is the change that makes automation mandatory.

The schedule, from the Baseline Requirements

The rules live in the CA/Browser Forum's Baseline Requirements for TLS server certificates, section 6.3.2 (validity) and section 4.2.1 (data reuse), introduced by ballot SC-081v3. The ballot passed with 25 certificate issuers voting yes, none against and five abstaining, and all four voting certificate consumers (browser and operating system vendors) in favor.

Maximum certificate validity

The requirements also say CAs should not go right up to the limit: the recommended maximums are 199, 99 and 46 days. A day is defined as 86,400 seconds, and any extra fraction counts as another day, which is why certificates are often issued a little short of the limit.

Domain validation reuse

When a CA validates that you control a domain, it may reuse that result for later certificates for a limited time. That window shrinks as well:

Organization identity reuse

For OV and EV certificates, the CA also verifies information about the organization (subject identity information). The reuse period for that data dropped from 825 days to 398 days on March 15, 2026, and stays there.

Why the lifetimes are shrinking

A certificate is a promise that, at the time of issuance, the holder controlled the domain. The longer a certificate lasts, the longer that promise can be wrong: the domain may have changed hands, the private key may have leaked, or the certificate may have been issued by mistake. Revocation is supposed to handle those cases, but clients check revocation inconsistently. Short lifetimes limit the damage by making every certificate expire soon anyway, and they force the automation that lets the whole ecosystem change CAs or algorithms quickly when it needs to.

What it means in practice

Renewal becomes frequent

Renewing at about two thirds of a certificate's lifetime is a common rule of thumb and the one Let's Encrypt suggests for clients without renewal hints. For a 47-day certificate that means renewing roughly every 31 days, about 12 times a year per certificate. For a team with 40 certificates, that is around 480 renewals a year, each of which must also be deployed to every server, load balancer and CDN that uses it.

Validation becomes part of every renewal

With a 10-day reuse window, the CA will re-check domain control for almost every certificate. ACME clients do this automatically with HTTP-01 or DNS-01 challenges. What breaks is anything that depends on a human, such as clicking a link in a validation email or adding a DNS record by hand.

Hard-coded schedules will fail

A cron job that renews every 60 days was safe with 90-day certificates. With 47-day certificates it renews after the certificate has already expired. Scripts, runbooks and calendar reminders built around a yearly or 60-day cycle all need revisiting.

Your CA may move faster than the rules

CAs can issue shorter certificates than the maximum, and some already plan to. Let's Encrypt has announced that its default profile will move from 90-day to 64-day certificates on February 10, 2027, and to 45-day certificates on February 16, 2028, with its authorization reuse period shrinking to 10 days and then 7 hours. An opt-in profile already issues 45-day certificates.

How to prepare

1. Inventory every certificate

You cannot automate what you do not know about. Start with:

• Your DNS zones: every host name that serves HTTPS, mail or another TLS service.
• Certificate Transparency logs, searchable on sites such as crt.sh, which list every public certificate issued for your domains.
• Devices and platforms where certificates are uploaded by hand: load balancers, firewalls, VPN gateways, NAS boxes, printers, SaaS custom domains.

2. Automate issuance and deployment

For servers you control, an ACME client (Certbot, acme.sh, lego, or a web server with built-in ACME such as Caddy) handles issuance and validation. Make sure deployment is automated too:

certbot renew --deploy-hook "systemctl reload nginx"

For managed platforms, prefer the provider's own managed certificates over uploading your own. For appliances that only accept manual uploads, check whether the vendor supports ACME or an API, and plan for replacing those that do not.

3. Let the CA tell you when to renew

ACME Renewal Information (ARI), standardized as RFC 9773, lets the CA suggest a renewal window to the client. Clients that support it renew at the right time even if lifetimes change again, and the CA can ask for early renewal if certificates need to be replaced, for example after a mis-issuance. Check whether your ACME client supports ARI and turn it on.

4. Prefer validation that survives repetition

HTTP-01 works well when the server is directly reachable on port 80. DNS-01 works for wildcards and servers that are not publicly reachable, but it needs API access to your DNS provider; a common pattern is delegating _acme-challenge with a CNAME to a zone your automation controls, so the main zone's credentials never sit on the web server. Let's Encrypt has also said it expects to support a new method, DNS-PERSIST-01, that uses a DNS record you set once rather than one per renewal.

5. Watch what is actually served

More renewals mean more chances for one to fail quietly: a validation blocked by a new firewall rule, a server that was not reloaded, a node behind the load balancer that missed the update. Check every public endpoint from outside, daily, and alert well before expiry. Our guide to SSL certificate monitoring covers what to check, and the free SSL certificate checker shows what a site is serving right now.

With short lifetimes, the alert threshold should be relative to the renewal point rather than a fixed month ahead. If your automation renews with about a third of the lifetime left, an alert at 14 days for a 100-day certificate, or 7 days for a 47-day certificate, means automation has missed its window and still leaves time to fix it.

What does not change

• Existing certificates keep their expiry dates. Nothing has to be reissued on March 15 of any year.
• The certificate itself works the same way. Browsers, TLS versions and server configuration are unaffected.
• Domain registration is separate. A short-lived certificate does not help if the domain behind it expires; check it with the domain expiry checker.

PingRobot includes SSL certificate expiry reminders on every plan: each HTTPS monitor reads the certificate daily and emails you 7, 14 or 30 days before it expires, whichever you choose, then every day in the last three days.

Start monitoring free — 10 monitors, no credit card.