Let's Encrypt 64-Day Certificates: Prepare Your Renewal Setup

Short answer: Let's Encrypt plans to issue 64-day certificates by default starting February 10, 2027. If renewal is automated and your ACME client supports ACME Renewal Information (ARI), the CA says you should be all set. If a cron job, script, or runbook assumes a fixed number of days before expiry, review it now and test your renewal path in staging.

A shorter certificate lifetime does not mean you must renew manually every 64 days. It does mean that a brittle schedule, a stopped timer, or a renewal that succeeds without reloading the web server can cause an outage sooner. The staging environment began issuing 64-day certificates on October 14, 2026, so there is time to exercise your setup before production changes.

Step 1: find who actually renews the certificate

Start with the system that owns the certificate. On a Linux server using Certbot, inspect scheduled timers and run a dry run:

systemctl list-timers | grep -i certbot
sudo certbot renew --dry-run

The timer output shows whether a scheduled renewal job exists. A successful dry run shows that the current validation and deployment path can complete against the test environment. It does not prove every domain, server, or manually installed certificate is covered, so compare the result with the certificate list in your host panel or monitoring service.

On managed hosting, the host may renew certificates without exposing Certbot. Ask the provider which service renews the certificate and whether the customer needs to change anything. Avoid adding a second renewal job before you know who controls the live files.

Step 2: check whether the ACME client uses ARI

ARI is the ACME Renewal Information extension. It lets a certificate authority provide a suggested renewal window to a compatible client. Let’s Encrypt says clients using ARI should be ready for the 64-day default, but support depends on the software and version you run.

Check the official documentation for your installed ACME client, then verify which binary or container your scheduled job invokes. A server may have a current client installed while an old container, hosting integration, or pinned package still handles production renewals. If documentation is unclear, ask the client maintainer or hosting provider rather than assuming ARI is active.

Step 3: search for fixed expiry assumptions

If your automation calculates renewal from the certificate expiration date, inspect cron jobs, wrapper scripts, deployment playbooks, and runbooks. Let’s Encrypt specifically suggests looking for hard-coded values such as 83, 80, or 60.

Search a repository you control with a command such as:

rg -n "(83|80|60)[[:space:]]*(day|days|d|\*)" ./scripts ./ops ./deploy

Treat matches as review prompts, not automatic edits. A number may be unrelated, and a schedule can use a different unit or be configured in a hosting panel. If your client does not use ARI and a schedule is tied to expiration, Let’s Encrypt recommends renewing at approximately two-thirds of the certificate lifetime. For a 64-day certificate, two-thirds is about 43 days. Check the client’s documented scheduling behavior before changing a production job.

Step 4: test in staging and verify deployment

Use the ACME client’s staging mode to exercise issuance and renewal without replacing the live certificate. Confirm the test completes for every hostname, including www or other subdomains, and that your deployment hook installs the renewed files.

A certificate can renew successfully on disk while the web server continues serving an older copy from memory. Check that the renewal process reloads the service only after a successful renewal. For nginx, validate the configuration before reloading:

sudo nginx -t
sudo systemctl reload nginx

Use the equivalent documented command for Apache, a container platform, or your host. Then inspect the certificate visitors receive, not only the file on disk. The guide to checking an expired SSL certificate includes commands for checking the live certificate.

Step 5: add failure alerts

A scheduled job is not useful if nobody sees that it stopped. Configure an alert for failed renewal, failed deployment, or an approaching certificate expiry. Keep an external monitor as a backstop, since an on-server timer cannot report a server outage if it is the only alert channel.

Record which account or provider owns renewal and who responds to an alert. This is especially useful when a domain moves between hosting platforms or a contractor originally installed the certificate. If you are setting up HTTPS for the first time, start with adding an SSL certificate; if HTTPS is already failing, use the HTTPS troubleshooting guide.

Common mistakes

• Assuming every tool called ACME automatically supports ARI. Confirm support in the documentation for the client and version actually running.
• Changing a renewal interval based only on a search result. First establish whether a value controls renewal, expiry checks, or something unrelated.
• Testing issuance but not the deploy hook or web server reload.
• Relying on email reminders that go to an unattended mailbox.
• Replacing a provider-managed renewal setup with a second job that competes for the same certificate files.