M's Works

Parliamo su

WhatsApp

47-day SSL certificates: manual renewal is running out of time

The maximum lifetime of SSL certificates drops to 47 days by 2029, and Let's Encrypt moves to 64 days on February 10, 2027. What breaks first if you renew by hand, and how to automate renewal.

Antonio Murabito5 min read
A row of duration bars getting shorter from left to right: the last and shortest one is red

Since March 15, 2026 a public SSL certificate can't be valid for more than 200 days, and the limit keeps dropping until it reaches 47 days in 2029. If you still renew certificates by hand, with a yearly reminder in your calendar, it's time to stop. The next date to note is February 10, 2027: from then on Let's Encrypt issues 64-day certificates.

When a certificate expires, the browser puts a full-screen warning in front of the site and apps that call your APIs stop connecting. Sometimes email stops too. Usually a customer notices first, because renewal was someone else's job.

The timeline: from 398 to 47 days

Maximum lifetimes are set by the CA/Browser Forum, where the certificate authorities sit alongside the browser makers. Ballot SC-081, voted in April 2025, passed with no votes against: 25 authorities in favour, 5 abstaining, and a yes from Apple, Google, Microsoft and Mozilla. The aim is to limit the damage from a stolen or misissued certificate, which stays usable for less time if it expires sooner. The dates, as summarised by DigiCert:

398 days

the maximum lifetime until March 15, 2026

200 days

the maximum lifetime from March 15, 2026

100 days

the maximum lifetime from March 15, 2027

47 days

the maximum lifetime from March 15, 2029

The first step is already in force, and anyone who bought an "annual" certificate after March 15 has found out: the subscription runs for twelve months, the certificate doesn't, and halfway through the year it has to be reissued and reinstalled. From 2027 that becomes four certificates a year. If your provider supports ACME, even a paid certificate can renew itself.

Let's Encrypt is moving faster than everyone else. It currently issues 90-day certificates, which become 64 days on February 10, 2027 and 45 days on February 16, 2028; if you want to try 45 days early, you can already request them through the opt-in tlsserver profile, live since May 13, 2026. The same schedule shortens how long a domain validation can be reused: 30 days today, then 10, then 7 hours. In practice, every renewal will have to validate the domain again from scratch.

What breaks first

At 47 days you're looking at roughly eight renewals a year per domain, repeated on every machine that holds a copy of the certificate. The first to go are certificates installed by hand on admin panels, internal servers and network appliances, where nobody ever set up automatic renewal. Next come renewal scripts written years ago: they still run, but maybe on a server that has changed since, or on a fixed interval designed for 90 days. If the certificate was copied from the web server to the load balancer or the mail server, the renewal lands on the first one and never reaches the second. Applications that trust one specific certificate rather than the authority that issued it stop connecting at the first renewal.

Let's Encrypt, for its part, stopped emailing expiry warnings on June 4, 2025. If you relied on that email to find out an automatic renewal had failed, today you find out from the error on your site.

How to automate renewal

Automatic renewal goes through ACME, the protocol used by Let's Encrypt and many commercial authorities. A client on the server, Certbot for example, requests the certificate, proves you control the domain, installs it and renews it before it expires. Installing the client is the easy part. The rest goes in this order:

  1. The inventory: every domain and subdomain with a certificate and, for each one, the machine it's installed on. Almost nobody has one, and without it you don't know what to check.
  2. Renewal tied to the certificate's lifetime, not to a fixed interval. Let's Encrypt says that renewing every 60 days, as many scripts do, won't be enough anymore. It recommends ARI, where the authority itself tells the client when to renew; failing that, renew at about two thirds of the certificate's lifetime.
  3. Distribution: if the same certificate serves several systems, the renewal has to reach all of them, and the services using it need a restart.
  4. An external check that reads the expiry of the certificates actually in use every day and warns you a few days ahead. It has to run somewhere else: if it lives on the same server that does the renewing, when that server has a problem both go quiet.

On modern hosting the public site is often already covered, and you only need to confirm that renewal is set up and working. The real work is on management software, internal APIs, appliances and mail servers, the part of systems management that usually has no owner.

If you don't know how many certificates you have, where they live and who renews them, get in touch: we start from the inventory and leave a check running that warns you before an expiry reaches your customers.

Topics47-day SSL certificatesLet's EncryptHTTPSACMEautomatic renewal

Comments

Loading comments…

“If opportunity doesn't knock, build a door.”

Milton Berle
47-day SSL certificates: timeline and automatic renewal | M's Works