Let's Encrypt Moves to 64-Day Certificates: Check Your Renewals Now

From 10 February 2027, every certificate Let's Encrypt issues or renews by default will be valid for 64 days instead of 90. If your renewals run on a modern client that asks Let's Encrypt when to renew, you probably have nothing to do. If anything on your server counts days by hand, it needs fixing before February.

Here is the surprising bit. Let's Encrypt's own announcement, dated 7 October 2026, tells admins to grep for the numbers 83, 80 or 60 in cron jobs, wrapper scripts and runbooks. A script that renews "when the certificate is 80 days old" waits for a day that never comes, because a 64-day certificate is already dead by then.

By the end, you will know where your renewal timers live, whether anything is hardcoded, and whether renewal works against a 64-day test certificate today.

What is changing, in plain words

A TLS certificate is the file behind your site's padlock. The time between its start and end dates is its lifetime, and renewal means getting a fresh one before the old one ends.

Think of a monthly bus pass that becomes a three-week pass. If you buy a new one when the old one runs low, nothing changes. If your diary says "buy new pass on the 28th", you end up at the bus stop with an expired card.

Here is what the Let's Encrypt post of 7 October 2026 says, at the time of writing (11 November 2026):

• Any certificate issued or renewed on or after 10 February 2027 gets a 64-day validity period by default.
• The last 90-day certificate is expected to expire on 11 May 2027.
• Valid certificates will not be revoked as part of this change.
• The staging environment (the test version of Let's Encrypt) has issued 64-day certificates since 14 October 2026.
• Authorization reuse (how long a passed domain check counts for later orders) drops from 30 days to 10 days, then to seven hours in 2028.
• Rate limits, ACME endpoints and issuance chains are not affected.
• The post calls this groundwork for default lifetimes of 45 days in 2028.

ACME is the protocol your client uses to talk to Let's Encrypt. ARI (ACME Renewal Information, RFC 9773) lets the server publish a suggested renewal window for each certificate; the client fetches it and picks a random moment inside. If your client supports ARI, Let's Encrypt is telling it when to renew, so the change looks after itself.

For everyone else, the advice is to renew at about two thirds of the lifetime. For 64 days that is about day 43, leaving roughly three weeks for retries.

Why this matters: nothing breaks on 10 February. Things break quietly weeks later, when the first 64-day certificates expire and a fixed-day script has not fired.

Before you start

Get these ready first:

• SSH access as root or a user with sudo on any server that runs Certbot or another ACME client.
• WHM root access if you manage a cPanel server, or at least cPanel access to your own account.
• A list of the domains you care about, including mail and panel hostnames.
• About 30 to 45 minutes for one server.
• A backup of your renewal configs and cron files (Step 1 below shows how).

Risk level: low. The checks only read files, and the dry run and staging test use the staging server without touching live certificates. Only editing cron or renewal files changes anything, and you will have a backup.

Find what you have and when it expires

Step 1: Back up the renewal configs and cron files

Before you read or change anything, take a copy. This command packs the Certbot folder and the system cron files into one dated archive in /root.

sudo tar czf /root/renewal-backup-$(date +%F).tar.gz /etc/letsencrypt /etc/crontab /etc/cron.d

You should see no output, and a file such as /root/renewal-backup-2026-11-11.tar.gz should now exist. If one of those paths does not exist on your server, tar complains about it; remove that path from the command and run it again.

Save the personal crontabs too, because they live elsewhere.

crontab -l > ~/my-crontab-backup.txt 2>/dev/null; sudo crontab -l > ~/root-crontab-backup.txt 2>/dev/null

Step 2: Check the expiry date the world actually sees

This fetches your live certificate and prints its issuer and dates. Replace example.com in both places.

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer -dates

You should see something like this (made-up values):

issuer=C = US, O = Let's Encrypt, CN = Example Intermediate
notBefore=Nov  1 08:14:02 2026 GMT
notAfter=Jan 30 08:14:01 2027 GMT

notBefore is the start and notAfter is the end. Today a Let's Encrypt production certificate should span about 90 days.

Quick tip: -servername sends your domain in the handshake. On shared servers, leaving it out may show the server's default certificate instead of yours.

To check a certificate file on disk, read it directly. Certbot keeps the current files under /etc/letsencrypt/live/.

sudo openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -noout -dates

Step 3: List what Certbot manages

This shows every certificate Certbot knows about, with its expiry and how many days are left.

sudo certbot certificates

Look for Certificate Name:, Domains: and Expiry Date:, which ends with something like (VALID: 30 days). Note each certificate name.

Now check your Certbot version, because it decides how renewal timing works.

certbot --version

The Certbot changelog says that from 4.0.0 (April 2025), a certificate is due when less than one third of its lifetime remains, instead of a fixed 30 days. From 4.1.0 (June 2025), certbot renew checks ARI, which for Let's Encrypt typically means renewal at around two thirds of the lifetime. At the time of writing the latest release is 5.10.0 (10 November 2026).

On 4.1.0 or newer, the default timing already fits. On 4.0.x the one-third rule still fits but ARI is not checked. Before 4.0.0 the default is a fixed 30 days before expiry, which still works for 64 days (renewal near day 34) but ignores ARI, so plan an upgrade.

Find the timers that run your renewals

Renewal only happens if something runs certbot renew on a schedule. The Certbot docs say to look in the system crontab (typically /etc/crontab or /etc/cron.*/*) or in systemd timers.

Step 4: Check systemd timers

This lists every timer the system knows, and the grep keeps only Certbot lines.

systemctl list-timers | grep -i certbot

The columns are NEXT (next run), LEFT (time until then), LAST (last run), PASSED (time since then), UNIT (the timer) and ACTIVATES (the service it starts). A healthy line shows a NEXT time within the next day and a LAST time that is recent.

No output just means the schedule lives in cron instead.

Step 5: Check cron

This searches the usual system cron locations for anything that mentions Certbot or ACME.

sudo grep -R -n -i -E "certbot|acme|letsencrypt" /etc/crontab /etc/cron.d /etc/cron.daily /etc/cron.weekly /etc/cron.monthly 2>/dev/null

Then check the personal crontabs, because many old setups put renewal there.

crontab -l 2>/dev/null | grep -i -E "certbot|acme|ssl|cert"; sudo crontab -l 2>/dev/null | grep -i -E "certbot|acme|ssl|cert"

Note every line, especially the schedule (the five fields at the start) and flags such as --force-renewal.

Heads up: a daily or twice-daily certbot renew is good, because Certbot only renews what is due. A line that fires on one fixed day every two or three months is the kind that breaks.

Hunt for hardcoded renewal days

Step 6: Grep for the numbers Let's Encrypt warned about

This searches cron files, common script folders and the Certbot renewal configs for 83, 80, 60 and 30 as whole numbers, then keeps only lines that also look certificate related. Add any folder where you keep your own scripts or runbooks.

sudo grep -R -n -w -E "83|80|60|30" /etc/crontab /etc/cron.d /usr/local/bin /usr/local/sbin /root /etc/letsencrypt/renewal 2>/dev/null | grep -i -E "cert|ssl|renew|expir|days|acme"

Expect noise, since 80 is also a port number. You are looking for things like AGE=80, -lt 30 next to a days variable, or a cron line that runs every two months.

Next, check whether any Certbot renewal config overrides the default timing.

sudo grep -H "renew_before_expiry" /etc/letsencrypt/renewal/*.conf

No output means no override. If you see something like renew_before_expiry = 30 days, read it like this with 64-day certificates:

• 30 days or less: safe. Renewal happens at day 34 or later, with time to spare.
• Close to or above 64 days, for example 70 days: every certificate is always within that window, so Certbot renews on every run.

Since 4.1.0 an early ARI suggestion beats a later renew_before_expiry, but without ARI the setting wins. The Certbot docs warn that hand-editing files under /etc/letsencrypt/renewal/ can damage them, so keep your Step 1 backup and dry run afterwards.

Step 7: Fix a hardcoded cron line or script

Here is a made-up example: an old server has this line in /etc/cron.d/renew-ssl, written years ago by someone who left.

0 4 1 */2 * root certbot renew --force-renewal --quiet

It forces a renewal on the first of every second month, so runs are 59 to 62 days apart. Fine for 90 days. With 64 days it leaves two to five days of margin, and one failure means an outage. With 45 days it fails outright.

The fix is to stop counting days. Comment the line out with # and let Certbot decide. If Step 4 showed a working systemd timer, that is all you need.

If you have no timer at all, the Certbot docs give this command, which adds a twice-daily renewal check to /etc/crontab with a random delay of up to one hour.

SLEEPTIME=$(awk 'BEGIN{srand(); print int(rand()*(3600+1))}'); echo "0 0,12 * * * root sleep $SLEEPTIME && certbot renew -q" | sudo tee -a /etc/crontab > /dev/null

Run it once only. Then confirm the line is there.

grep -n "certbot renew" /etc/crontab

If your own script must decide when renewal is due, base it on the fraction of lifetime left. This script exits 0 when less than one third remains, so it works for 90, 64 and 45 days alike. It needs GNU date, standard on Linux.

#!/bin/bash
# renew-check.sh: exit 0 when less than one third of the certificate lifetime is left
CERT="${1:-/etc/letsencrypt/live/example.com/cert.pem}"
start=$(date -d "$(openssl x509 -in "$CERT" -noout -startdate | cut -d= -f2)" +%s)
end=$(date -d "$(openssl x509 -in "$CERT" -noout -enddate | cut -d= -f2)" +%s)
third=$(( (end - start) / 3 ))
if openssl x509 -in "$CERT" -noout -checkend "$third" >/dev/null; then
  echo "Not due yet: more than one third of the lifetime is left"
  exit 1
fi
echo "Renewal due: less than one third of the lifetime is left"
exit 0

-checkend checks whether the certificate expires within the given number of seconds. Run the script with a certificate path and you should see one of the two messages.

Fix monitoring too. An alert at "fewer than 30 days left" fires for every healthy 64-day certificate from day 34. Use something like 14 days, and add alerting for renewal failures, as Let's Encrypt recommends.

Test against a 64-day certificate today

Staging already issues 64-day certificates, so you can rehearse February now. Its directory is https://acme-staging-v02.api.letsencrypt.org/directory, and browsers do not trust its certificates.

Step 8: Run a dry run

This simulates renewal of every Certbot certificate against staging, without saving anything to disk.

sudo certbot renew --dry-run

A good result ends with Congratulations, all simulated renewals succeeded: followed by the certificate paths. The Certbot docs note that --pre-hook and --post-hook run during a dry run, but --deploy-hook does not unless you add --run-deploy-hooks.

If a deploy hook reloads your web server or copies certificates, test it too.

sudo certbot renew --dry-run --run-deploy-hooks

Heads up: this really runs the hooks, so a hook that reloads Nginx will reload Nginx. Do it outside busy hours.

Step 9: Get a real staging certificate and look at its dates

A dry run keeps nothing, so you cannot see the 64 days yourself. First check which plugin you normally use.

sudo grep -H "authenticator" /etc/letsencrypt/renewal/*.conf

If it says webroot, this gets a staging certificate under a separate name without installing it. Replace the folder and domain with yours.

sudo certbot certonly --test-cert --webroot -w /var/www/html -d example.com --cert-name example.com-staging-test

The new --cert-name keeps your live certificate untouched. Certbot also refuses to replace a valid live certificate with a staging one unless you pass --break-my-certs, so never use that flag in production.

Now read the dates of the test certificate.

sudo openssl x509 -in /etc/letsencrypt/live/example.com-staging-test/cert.pem -noout -issuer -dates

The gap between notBefore and notAfter should be about 64 days, and the issuer will be a staging issuer rather than the one on your live certificate. Clean up when you are done.

sudo certbot delete --cert-name example.com-staging-test

Heads up: Let's Encrypt says never to add the staging root or intermediate to a trust store you use for normal browsing. They are not audited like the real ones.

cPanel and WHM: AutoSSL

On cPanel servers, AutoSSL usually handles renewals. cPanel's SSL guide says Let's Encrypt is the default AutoSSL provider for new installations, and AutoSSL attempts renewal when a Let's Encrypt certificate expires within 29 days.

Honest caveat: at the time of writing, that page still says an AutoSSL certificate expires after 90 days and says nothing about 64-day certificates. The docs alone cannot tell you how AutoSSL behaves after 10 February, so ask your host or cPanel, and watch the logs after the switch.

Step 10: Check AutoSSL in WHM

Go to WHM > Home > SSL/TLS > Manage AutoSSL and confirm the provider on the AutoSSL Providers tab.

On the Logs tab, pick the latest log and click View Log. Look for failures or deferrals. cPanel keeps these logs for 30 days in /var/cpanel/logs/autossl.

On the Options tab, make sure notifications cover at least failures, warnings and deferrals.

To run a check for every user from the command line, cPanel documents this command.

sudo /usr/local/cpanel/bin/autossl_check --all

A cPanel user without WHM can go to cPanel > Security > SSL/TLS Status and click Run AutoSSL.

If the server also has hand-made SSL cron jobs, run Steps 5 and 6 there too. A healthy AutoSSL does not mean an old script is healthy.

How to check it worked

After any change, check:

1. sudo certbot renew --dry-run ends with Congratulations, all simulated renewals succeeded:.
2. systemctl list-timers | grep -i certbot or grep -n "certbot renew" /etc/crontab shows exactly one renewal schedule that runs at least daily.
3. The grep from Step 6 no longer finds a fixed day count in anything that renews certificates.
4. The live check from Step 2 shows a notAfter date comfortably in the future.
5. On cPanel, the latest AutoSSL log shows no failures for your domains.

After 10 February 2027, repeat Step 2 on a renewed site: the lifetime should be about 64 days. Check again around day 45 to confirm a renewal really happened.

Quick tip: add a weekly check that warns when -checkend 1209600 (14 days in seconds) fails. It catches every kind of renewal failure, even on machines you forgot about.

Troubleshooting

"All simulated renewals failed"

Symptom: the dry run ends with All simulated renewals failed. The following certificates could not be renewed: and earlier lines show Failed to renew certificate example.com with error: followed by the reason.

Likely cause: the domain check fails, often because the site or webroot moved or a firewall blocks port 80. It is not the 64-day change, but the dry run exposes it early.

Fix: read the reason and the log in /var/log/letsencrypt. If the webroot moved, the Certbot docs (v2.3.0 and newer) suggest certbot reconfigure --cert-name example.com --webroot-path /path/to/new/location, which tests the new option against staging and saves it if the test passes.

"We will not do that unless you use the --break-my-certs flag!"

Symptom: Certbot says You've asked to renew/replace a seemingly valid certificate with a test certificate and stops.

Likely cause: you ran --test-cert against the name of a live certificate.

Fix: Certbot is protecting you. Use a separate --cert-name as in Step 9.

Browser warning after a test

Symptom: visitors see a "not secure" or certificate warning right after you tested staging.

Likely cause: a staging certificate got installed, for example by a plugin that also installs, or a script that copied the wrong files.

Fix: find the live certificate name with sudo certbot certificates, point the web server back at its files under /etc/letsencrypt/live/, reload, recheck with Step 2, then delete the test certificate.

"No simulated renewals were attempted"

Symptom: the dry run prints No simulated renewals were attempted.

Likely cause: Certbot has no renewal configs here, often because another client or a panel such as AutoSSL issued the certificates.

Fix: find the real tool. Look in cron for other ACME clients, and on cPanel use the AutoSSL steps.

Renewal happens on every run

Symptom: the logs show a renewal attempt twice a day, every day.

Likely cause: a renew_before_expiry value close to or above the certificate lifetime, or a cron line with --force-renewal.

Fix: lower or remove the value, drop --force-renewal from scheduled jobs, and dry run again.

A few extra notes

If a mail server or panel reads certificate files directly, make sure your deploy hook reloads it. More renewals means a service that only reloads on reboot shows a stale certificate sooner.

If a lapsed certificate would break your HTTPS redirects, see how to redirect HTTP to HTTPS using .htaccess. While you are in the TLS settings, check and enable TLS 1.3 on Apache, Nginx and WHM. Weighing another certificate authority? Read what SSL owners should know about the Cloudflare public CA.

Ask your host or a developer if certificates come from a load balancer, CDN or pipeline you did not build. The timer may live somewhere SSH cannot see.

The one message worth forwarding

Copy this and send it to whoever runs your servers:

"Let's Encrypt is moving default certificates from 90 to 64 days for anything issued or renewed on or after 10 February 2027. Could you check three things before then: that renewals run through Certbot 4.1.0 or newer (or another ARI-aware client), that no cron job, script or runbook uses a fixed day count like 83, 80 or 60, and that certbot renew --dry-run succeeds? Staging already issues 64-day certificates, so we can test it today. Please also make sure we get an alert if a renewal fails."

If something on your server counts days, change it to count fractions of a lifetime, and the 64-day change and the 45-day one after it will pass without anyone noticing.