# TLS Certificates Heading to 47 Days: Automation Becomes Mandatory
Table of Contents
Every site you reach over https uses a certificate: a small digital document that proves the site really is who it claims to be, and that lets the browser encrypt the connection after a brief initial exchange, the TLS handshake. Nothing new so far. What’s new is that these certificates will last far less than they do today. The body that sets the rules for the whole industry has approved a schedule that will cut the maximum lifetime from just over a year down to only 47 days by 2029. For people visiting sites, nothing changes. For the people running them, quite a lot does, because renewing a certificate by hand every month and a half isn’t sustainable: automation stops being a nice-to-have and becomes a requirement.
The news in brief
The body that sets these rules is called the CA/Browser Forum. It’s where two groups meet: the Certificate Authorities (CAs), the companies that issue certificates, and the browser makers such as Apple, Google, Microsoft, and Mozilla, who decide which certificates to trust. When these parties agree on a rule, that rule effectively applies to the entire public web.
On 11 April 2025 the Forum approved a proposal identified as SC-081v3. It was put forward by a representative from Apple and endorsed by Sectigo, Google, and Mozilla. So this isn’t a draft or an idea still under discussion: it’s a settled decision, with a precise and binding schedule. The vote passed with no objections: not one Certificate Authority and not one browser maker voted against it.
The schedule of cuts
The reduction doesn’t happen all at once. It’s spread across three steps, with fixed dates. Today a TLS certificate can last at most 398 days, a little over a year. From there it comes down like this:
- From 15 March 2026: maximum lifetime 200 days
- From 15 March 2027: maximum lifetime 100 days
- From 15 March 2029: maximum lifetime 47 days
The dates mark when each limit takes effect for certificates issued from that day on. A certificate obtained before a cut-off stays valid for the term it was issued with; the new limit applies to later issuances. In practice the tightening is felt gradually, but the direction is one-way and won’t reverse.
Why shorten the lifetime
The natural question is: why make life harder? The main reason is security, and it turns on a simple idea, the window of compromise.
A certificate is tied to a private key, a secret file that must stay on the server and never leave it. If that key is stolen - through an attack, a misconfiguration, a backup ending up in the wrong place - whoever holds it can impersonate the site for as long as the certificate remains valid. The longer the certificate, the longer the window in which a theft goes unnoticed and does damage.
In theory there’s a remedy: revocation, the ability to declare a certificate invalid before it expires. In practice revocation works poorly. Browsers don’t always check whether a certificate has been revoked, and the mechanisms meant to warn them are slow or unreliable. Shortening the lifetime is a more solid way to get the same effect: a certificate that lasts a short time limits the damage on its own, because it expires before the problem can drag on. It’s less elegant than revocation, but it actually works.
There’s a broader reason too. Certificates that last a year tend to be treated as things you configure once and forget. Shortening their life forces everyone to automate their management, and an automated, frequent process is safer than a manual, rare one: it makes fewer mistakes, doesn’t rely on a person’s memory, and doesn’t leave certificates expired through oversight.
It’s not just the expiry date
The same decision touches a second, less visible but equally important point: domain re-validation. Before issuing a certificate for a site, the Certificate Authority has to confirm that whoever’s asking actually controls the domain. This check is called Domain Control Validation (DCV). Once it’s done, today the result can be reused for a long time: you prove control of the domain once and it’s taken as good for months.
This reuse period is being shortened on the same schedule, down to just 10 days from 15 March 2029. That means it won’t be enough to renew the certificate often: you’ll also have to re-prove control of the domain often. Slow, manual methods - such as email-based verification or hand-placing a file on a server - become impractical at that frequency. You need a system that proves domain control on its own, automatically, every time it’s needed.
Manual renewal no longer holds up
Put the pieces together. With a maximum lifetime of 47 days, every certificate has to be replaced before it expires, so in practice roughly every month. For someone running a single site it’s a nuisance; for someone running dozens or hundreds it becomes impossible to keep up by hand. One forgotten renewal is all it takes for a site to show visitors the expired-certificate warning - that red screen that sends people running - with immediate damage to reputation and sales.
The conclusion this decision points to explicitly is that certificate management needs to be automated. Not as an optional improvement, but as the only way to keep pace with the required frequency.
The automation is called ACME
The tool to do this already exists and is widely used. It’s called ACME (Automatic Certificate Management Environment), a standard protocol - a shared language - with which a server can request, obtain, and renew certificates on its own, talking to the Certificate Authority without human intervention. It’s the same mechanism made popular by Let’s Encrypt, the free authority that for years has issued certificates valid for 90 days precisely because they’re designed to be renewed automatically.
How it works, in plain terms: a program installed on the server proves to the Authority that it controls the domain, receives the certificate, installs it, and schedules its own renewal before expiry. All without anyone having to remember anything. The best-known client is called certbot, but almost every modern control panel, load balancer, and cloud service already has ACME support built in. Anyone already using it has almost nothing to do: the shorter lifetime is, for them, a detail the system handles by itself.
An example of the idea, using certbot, to obtain and configure a certificate on a web server:
certbot --nginx -d example.com -d www.example.comFrom that point on, renewal happens automatically, usually through a scheduled task that runs several times a day and renews certificates as they approach expiry.
What’s worth doing now
There’s no rush for today, but the direction is clear, and it’s worth getting ahead of it calmly rather than chasing deadlines later.
- Take an inventory. Know how many certificates you manage, where they are, and when they expire. There are often more than you remember.
- Check what’s already automatic and what isn’t. The certificates still renewed by hand are the ones that will cause trouble first.
- Adopt ACME where it’s missing. Moving manual renewals to an automated client is the investment that pays off most, because it removes the fragile part of the process.
- Don’t wait for 2029. Whoever automates now will pass through all three steps without noticing. Whoever puts it off will end up managing by hand a frequency that can’t be managed by hand.
In short
TLS certificate lifetimes are stepping down to 47 days by 2029, along with the reuse period for domain checks, which drops to 10 days. It’s a settled decision, not a proposal. The reason is to shrink the time in which a compromised certificate can do harm, in a world where revocation works poorly. For people browsing, nothing changes. For those running sites the message is blunt: manual renewal has an expiry date, and automation through ACME is the ready-made path to stop thinking about it.
