Certificate renewal is one of those jobs that can run quietly for years, until a small assumption in a script stops being true. Let's Encrypt's latest lifetime change is a reason to check those assumptions now.

In its 7 October announcement, Let's Encrypt says default certificates issued or renewed from 10 February 2027 will be valid for 64 days. Valid existing certificates will keep their expiry dates. Shorter opt-in profiles remain available.

This week's staging change is useful

The staging service is scheduled to start issuing 64-day certificates on 14 October 2026. That gives administrators a place to check their renewal automation before the production change.

Let's Encrypt recommends clients that support ACME Renewal Information, or ARI, which lets the authority advise when a certificate should renew. Where timing is hard-coded, it recommends renewal at approximately two-thirds of the certificate's lifetime.

A script built around a 90-day certificate may wait too long under a shorter lifetime. Check the calculation rather than assuming a successful renewal last month proves it will keep working.

Find every place a certificate is used

Start with the public website, then include mail services, control panels, API endpoints and any separate subdomains. A single business can have several renewal systems operated by different people.

For each endpoint, record the client, the person responsible and how a renewed certificate reaches the service. A hosting provider may manage some certificates while your deployment pipeline manages others.

Ask your provider which clients and control-panel versions support the transition. A precise answer is more useful than a general assurance that SSL is included.

Issuing the file is only part of the job

A renewal can succeed while the public service continues presenting the old certificate. Test the whole path: request, validation, file placement, permissions and the reload or deployment step.

After the test, inspect the certificate presented by the endpoint from outside the server. Confirm its expiry and hostname. That catches a service pointing at the wrong file or a load balancer that never received the replacement.

Use staging certificates only in a test environment. They are intended for testing and will not be trusted by ordinary browsers.

Make a failed renewal visible

Give renewal errors a destination someone reads. An error in a cron log is easy to miss if nobody reviews that log. Also monitor the expiry of the certificate visitors actually receive.

  • Identify the renewal client and its timing rules.
  • Test the complete process against staging.
  • Confirm the service presents the replacement certificate.
  • Send failure and expiry alerts to an accountable person.

The announcement leaves several months to prepare. Use the staging change to prove your automation works, then keep the result in your normal maintenance records. That is cheaper than finding the broken assumption when customers see a certificate warning.

Reporting checked on 13 October 2026. The staging change is scheduled for 14 October.