Let’s Encrypt Moves to 64-Day Certificates: Prepare Renewals

Let’s Encrypt has announced that its free TLS certificates will get shorter. From February 10, 2027, every certificate it issues or renews will be valid for 64 days, down from the 90 days that admins have relied on for years. This is the middle step of a longer plan: the default is expected to drop again, to 45 days, in 2028. If your websites, mail servers or APIs use Let’s Encrypt, and most small-business servers do, now is a good time to check that your renewals are fully automated and do not depend on old assumptions about the 90-day lifetime.

What is changing and when

The rollout comes in stages, and you have time to test before it reaches production:

Certificates that are already valid will not be revoked. A 90-day certificate issued before February 10 keeps working until its normal expiry date. Subscribers who want even shorter lifetimes can already choose 45-day or six-day certificates through Let’s Encrypt’s certificate profiles.

Let’s Encrypt says the change follows the CA/Browser Forum Baseline Requirements, which set the industry-wide timeline for shorter certificate lifetimes. Other certificate authorities are working towards the same limits, so this is not a change you can avoid by switching provider.

Shorter domain authorization reuse

There is a second, less visible change. When an ACME client proves it controls a domain, Let’s Encrypt can reuse that successful validation for later orders for a limited time. That reuse window is being cut from 30 days to 10 days, and it is planned to shrink to just seven hours in 2028.

For most setups this changes nothing, because the client simply validates again when it renews. It matters if you have tooling that validates a domain once and then issues several certificates over the following weeks, or if a DNS challenge involves a manual step. In those cases, expect to complete validation far more often, which is another strong reason to automate DNS-01 challenges through your DNS provider’s API.

What stays the same

• Rate limits are not affected by the move to 64 days.
• ACME endpoints do not change, so client configuration URLs stay as they are.
• Certificate issuance chains are unchanged.

How to check your servers

The risk here is not the shorter lifetime itself. It is renewal logic that silently assumes 90 days. Work through this checklist on each server.

1. Find out how renewals actually run

Look for both cron jobs and systemd timers, since different packages use different methods:

sudo crontab -l
ls /etc/cron.d/
systemctl list-timers --all | grep -i -E 'certbot|acme|lego'

If you find nothing, that is a warning sign rather than good news. Confirm how certificates on that host are being renewed before assuming it is handled.

2. Look for hard-coded day counts

Let’s Encrypt specifically warns about scripts that renew at fixed values such as 83, 80 or 60 days. A script that waits 80 days before renewing will let a 64-day certificate expire. Search your scripts and runbooks:

sudo grep -rnE '\b(83|80|60)\b' /etc/cron* /usr/local/bin /opt/scripts 2>/dev/null

Adjust the paths to wherever your own tooling lives, and review each match by hand. The recommended rule is to renew after roughly two-thirds of the certificate’s lifetime has passed, rather than at a fixed number of days.

3. Prefer a client with ARI support

ACME Renewal Info (ARI) lets the certificate authority tell your client when it should renew. Clients that support ARI should handle the new lifetimes without any changes. Check your client’s documentation to confirm whether it supports ARI, and update it from your distribution’s repositories if you are on an old release:

# Debian / Ubuntu
sudo apt update && sudo apt install --only-upgrade certbot

# RHEL / Rocky / AlmaLinux (EPEL)
sudo dnf upgrade certbot

4. Test against staging

Once 64-day certificates are live in staging on October 14, run a test renewal so you see the new behaviour before production does. With Certbot, a dry run uses the staging environment:

sudo certbot renew --dry-run

5. Automate the reload and add alerts

A renewed certificate on disk does nothing until nginx, Apache, Postfix or Dovecot loads it. Make sure every renewal triggers a service reload, and set up monitoring that warns you when a live certificate gets close to expiry. Checking what the server actually presents is more reliable than checking the file:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate

Do the same for mail ports such as 465 and 993 if your mail server uses Let’s Encrypt certificates.

What this means for hosting panels

If you use cPanel, Plesk or a managed host, certificate renewal is usually handled by the panel. That reduces the work, but it does not remove the need to check. Make sure the panel software is current, and keep an eye on any certificates that were installed manually or copied to other services such as load balancers, mail gateways or containers. Those copies are the ones most likely to be forgotten when lifetimes shrink.

How TechProvidence can help

TechProvidence manages Linux, cPanel/WHM and WordPress servers for businesses that cannot afford an expired certificate taking their site or mail offline. We can audit your renewal setup, move scripts to ARI-capable clients, automate DNS challenges and reloads, and add expiry monitoring across all your services. If you would like us to check your servers before the February deadline, contact us.

Source: Linuxiac