Let's Encrypt Certificates Are Getting Shorter. Is Your Renewal Script Ready?

Let's Encrypt certificates are getting shorter, and I think a lot of small VPS setups are not ready for it. If you set up automatic HTTPS a few years ago and have not looked at it since, this post is for you. The default assumption baked into a lot of renewal scripts, that you have 90 days before a certificate expires, is starting to change.

What is actually changing

Let's Encrypt confirmed the timeline directly on their own blog. On May 13, 2026, they switched their opt-in tlsserver profile to issue 45-day certificates. That already happened. Next, on February 10, 2027, their default classic ACME profile moves from 90-day certificates down to 64-day certificates. That is the profile most people are on right now without even choosing it, since it is the default. After that, the classic profile drops again to 45 days on February 16, 2028.

There is also a much shorter option already available. Since January 2026, Let's Encrypt offers a short-lived certificate profile valid for just 160 hours, which is about six days. This one is opt-in too, and Let's Encrypt has said they have no plan to make it the default. But some server admins are switching to it on purpose, since a stolen or leaked key becomes far less useful once the certificate expires in days instead of months. You can read the full staged timeline directly on Let's Encrypt's own announcement post.

Why this matters for your renewal script

Here is the part I want you to actually check today. A lot of Certbot tutorials, including some I have seen floating around from years ago, use a renewal check based on a 30-day buffer. That made sense with 90-day certificates, since it gave you a full 60 days of cushion if something went wrong with a renewal attempt.

That same 30-day check still works on a 64-day certificate, but your cushion just dropped to 34 days. On a 45-day certificate, you are down to 15 days of margin. If you ever moved to the 6-day short-lived option without updating your renewal logic, a 30-day check would try to renew a certificate that has not even been issued yet, and nothing would happen until it was already too late.

One writeup put this bluntly, and I think it is fair. As James Miller wrote, "if your automation isn't solid, your life is about to get harder."

How to check your own setup

First, find out which Certbot version you are running.

certbot --version

Certbot added support for ACME certificate profiles in version 4.0, and then added full support for Automatic Renewal Information, or ARI, in version 4.1.0, released in June 2025. ARI lets Let's Encrypt tell your client exactly when to renew, based on the real lifetime of your certificate, instead of your client guessing from a fixed day count. You can read the technical details in the EFF's own Certbot 4.0 announcement. If you are on an older Certbot than 4.1.0, I would plan an upgrade before you consider switching to any of the shorter-lived profiles.

Next, check that your renewal timer is actually active and running often enough.

systemctl list-timers | grep certbot

Certbot's own systemd timer usually runs twice a day by default, which is fine for 90-day, 64-day, or 45-day certificates. If you switch to the 6-day short-lived profile, though, twice a day is the bare minimum, and Let's Encrypt's own guidance in their official FAQ says to renew 6-day certificates every three days, and 90-day certificates every 60 days.

If you wrote your own renewal script instead of using Certbot's built-in timer, this is the moment to open it up and actually read your buffer logic. Look for any line comparing days-until-expiry against a fixed number like 30.

The catch: your monitoring needs the same update as your renewal

I would not stop at fixing the renewal logic alone. If you are watching certificate expiry with any kind of external monitor, that check also needs a shorter warning window once your certificates get shorter. A monitor that only alerts you 20 days before expiry is not useful if your certificate only lives for 6 days in the first place.

This connects directly to something we have covered before. If you already run self-hosted Healthchecks for your backup jobs, you can add a similar dead man's switch for certificate renewal. Have your renewal hook ping a check on success, and let Healthchecks alert you the moment a renewal is overdue, instead of waiting for a browser warning your visitors see first.

Should you switch to shorter certificates on purpose

I would not rush into the 6-day short-lived profile just because it exists. It is a real security upgrade if your renewal automation is already rock solid, since a stolen key becomes nearly useless within days. But if you are not fully confident your renewal runs reliably every time, adding a much shorter deadline just increases the odds of an outage from a missed renewal. Get comfortable with the upcoming 64-day default first, confirm your monitoring actually works, and only consider the 6-day option once you trust the whole pipeline.

FAQ

Do I need to do anything if I use Certbot's default settings?
If you are on Certbot 4.1.0 or later with the default renewal timer running, the built-in ARI support should adapt fine to the move from 90 days down to 64 days on its own. I would still confirm your version, since older releases may not fully support ACME profiles or ARI.

What happens if my certificate actually expires?
Visitors get a browser warning telling them the connection is not private, and most will leave immediately. Some browsers block the page outright. This is exactly the outcome a good renewal and monitoring setup is meant to prevent.

Is the 45-day certificate available to everyone right now?
As of this writing, the 45-day tlsserver profile is opt-in, meant for early adopters and testing. The 64-day change becomes the automatic default for everyone on February 10, 2027, unless you have already opted into a shorter profile.

Do I need to switch ACME clients to handle this?
Not necessarily. Certbot, acme.sh, and other actively maintained clients are adding support for these changes. I would just make sure whichever client you use is a recent version, not one installed years ago and never updated.

Does this affect certificates from other certificate authorities too?
Yes, in general. This shift toward shorter certificate lifetimes is part of a wider CA/Browser Forum requirement affecting all publicly trusted certificate authorities, not just Let's Encrypt, so the same renewal-buffer question applies no matter which authority you use.

Bottom line

Your 90-day certificate habit is on a countdown. I would check your Certbot version and your renewal buffer logic this week, not after the February 2027 default change actually lands. A renewal script that barely worked with 60 days of slack will not forgive you the same way with 15.

Sources: Let's Encrypt, Decreasing Certificate Lifetimes to 45 Days; Let's Encrypt, 6-day and IP Address Certificates are Generally Available; Let's Encrypt, We Issued Our First Six Day Cert; Let's Encrypt official FAQ; EFF, Certbot 4.0: Long Live Short-Lived Certs. Verified against Let's Encrypt's own blog on August 29, 2026.