What 47-Day Certificates Mean for Your Stack (And Why Automation Can’t Wait) 

For years, TLS/SSL certificate validity was mostly a matter of convenience. Fewer renewals meant less operational overhead, so validity periods kept getting stretched, reaching 398 days at their longest. But every day a TLS/SSL certificate stays valid is another day a compromised key or an outdated validation record stays useful to whoever shouldn’t have it. 

 Revocation should have been that fix, but it never worked reliably at scale. Certificate Revocation Lists become too unwieldy to check efficiently, and Online Certificate Status Protocol (OCSP) introduces privacy trade-offs that browsers don’t consistently enforce. A compromised certificate can keep working long after someone should have caught the problem, which is exactly the gap a shorter lifespan closes without needing revocation to work perfectly. 

 A private key that leaks on a 47-day certificate has a much smaller window in which it matters than one that leaks on a certificate valid for over a year, and the same logic applies to stale organizational data or a validation check that’s technically still active but no longer reflects reality. That’s the reasoning behind Ballot SC-081v3 from the CA/Browser Forum, and it’s already underway: 

• March 15, 2026 — maximum validity dropped to 200 days 

• March 15, 2027 — maximum validity drops to 100 days 

• March 15, 2029 — maximum validity drops to 47 days, the final target under the current ballot 

If you have a smaller stack, the first phase might feel manageable. It’s the second and third stacks that turn a once-a-year manual task into one that should run on its own. 

Where Manual Certificate Renewal Breaks Down 

Manual renewal has always been technically possible. At 90 days, though, it already pushes most teams to automate parts of the process, even if they don’t think of it that way. At 47 days, the math no longer holds. 

Consider a team managing 50 public certificates on a 47-day cycle. That’s roughly 8 renewals per certificate annually, spread across a portfolio whose deadlines rarely align. Add the shrinking domain validation window on top of that, which narrows to just 10 days by 2029, and someone has to re-verify domain control almost as often as they renew. A missed renewal at that pace no longer means a scramble to catch up. It means an outage, one that usually shows up as a browser warning in front of customers before anyone on the team even notices internally. 

None of this means manual processes were a poor choice. They worked well when certificates lasted a year. They simply weren’t designed for a world where the clock resets every month and a half. 

Automatically Renew Certificates with ACME or REST API 

There are two well-established ways to automate certificate lifecycle management: ACME and REST API.  

ACME Automation 

ACME handles automation at the protocol level. Domain validation, certificate creation and renewal all happen programmatically, without a human clicking anything. Teams already running an ACME client, such as ZeroSSL’s acme.sh, generally find the transition to shorter lifespans close to invisible.  

What that automation actually delivers is a certificate that renews itself for as long as the integration stays in place, without anyone needing to track an expiration date. ZeroSSL supports this through its own dedicated ZeroSSL Bot as well as every major third-party ACME client, so a team can automate through whatever tool already fits its stack. Certificates issued through ACME are free and unrestricted by rate limits, which matters considerably once renewal shifts from an annual task to one that recurs every six weeks. 

REST API Automation 

REST API automation gives a team direct programmatic control instead of routing everything through a standardized protocol. Certificate creation, validation, renewal and cancellation all happen through simple HTTP calls with JSON responses and status changes come through automated webhooks rather than requiring a team to poll for updates. 

ZeroSSL’s API runs on infrastructure built to handle scale, currently processing millions of requests a month, with all data protected through 256-bit HTTPS encryption. That combination makes it a natural fit for teams that want automation built directly into their own scripts or internal tooling rather than handled by an external client. 

Set Your Own Clock 

The certificates themselves haven’t changed. What’s changed is the clock they run on. Teams already running ACME or the REST API have, in effect, been operating on a 47-day cycle for a while now, since their certificates get reissued the same way whether the interval is a year or six weeks. Their head start didn’t come from anything special about how they secured a connection. It came from setting that schedule themselves, rather than waiting for a deadline to set it for them.  

Which path is best for you depends less on the certificate type at this point and more on what your team actually needs. That said, teams already running 90-day certificates are effectively living in this future already, while teams still on longer annual cycles have a bit more runway, worth using now to get automation in place before the industry cap drops to 100 days in 2027.  

ACME is the simpler entry point, free of charge and unrestricted by rate limits, with setup running through its own bot or any major third-party client already in a team’s stack. REST API makes more sense once a team wants that automation built directly into its own systems, and it’s available on ZeroSSL’s paid plans for teams that need that level of control. 

The most useful step to take today is straightforward: choose ACME or the API, and issue one certificate through it from start to finish. Every renewal after that runs on its own, and shorter validity periods are no longer a manual concern. 

 Get started with ZeroSSL to automate your digital certificate lifecycle.