Let's Encrypt issues TLS certificates with a 90-day validity period by default. However, as the industry is gradually shortening TLS certificate lifetimes—with the maximum eventually expected to fall to 47 days—Let's Encrypt already offers certificates using the tlsserver profile with a validity period of 45 days.

Compared with the current default classic profile, the tlsserver profile removes deprecated attributes such as the Common Name. Because it follows the latest recommended configuration, it also produces slightly smaller certificates. The differences between the profiles are documented on the following page. If you have already automated certificate issuance and renewal, it is worth considering an early move to the tlsserver profile.

Certificate Profiles - Let's Encrypt

Certificates issued with the classic profile are currently valid for 90 days. However, the validity period is scheduled to be shortened to 64 days in February 2027 and then to 45 days in February 2028. Certificate renewal automation is easy to leave untouched once it is working, and many monitoring systems also use fixed day-based thresholds. Both renewal automation and monitoring therefore require careful review.

Decreasing Certificate Lifetimes to 45 Days - Let's Encrypt

With only about six months remaining before the validity period is reduced to 64 days, now is a good time to begin validating your systems.

Let's Encrypt also provides the shortlived profile for certificates that support IP addresses. These certificates are valid for only six days. With such a short lifetime, using them without automation is no longer practical.

6-Day and IP Address Certificates - Let's Encrypt

To issue certificates using any of these profiles, you need an ACME client that supports ACME profile selection. Widely used clients such as Certbot should be able to issue them without difficulty.

Issuing a certificate with the new tlsserver or shortlived profile is straightforward. The harder part is keeping it renewed reliably over time. With longer-lived certificates, checking once a day was generally sufficient. For certificates valid for 45 days—or only six days—clients need to check and renew more frequently. A long polling interval can also make it difficult to respond quickly enough if a large-scale certificate revocation occurs.

Rather than continuing to run renewal checks at fixed times and intervals with cron, it is recommended to migrate to or update an ACME client that supports ACME Renewal Information (ARI), and to schedule renewals using the window provided by ARI. ARI allows the certificate authority to influence certificate renewal timing. By following ARI, clients can determine an appropriate time to check and renew, while also benefiting from features such as exemptions from renewal rate limits.

ACME Renewal Information Is Now an RFC - Let's Encrypt

Let's Encrypt has published an official case study describing how Shopify significantly improved the efficiency of certificate renewals by moving to an ARI-based approach. Shopify operates its own certificate renewal platform. Introducing ARI simplified the process and allowed the CA to provide renewal timing with appropriate randomness.

Simplifying Certificate Renewals for Millions of Domains with ACME Renewal Information - Let's Encrypt

The renewal window provided by ARI varies according to the certificate lifetime, but actual windows are typically somewhere between roughly three hours and two days. When following ARI for short-lived certificates, a cron-based implementation may need to increase its execution frequency from once per day to approximately once every two hours.

Even with more frequent execution, clients are expected to select a random renewal time within the provided window. When managing many certificates, a cron-based approach may not distribute renewal timing effectively. Ideally, the system should manage timing independently for each certificate and run each renewal process separately. This may not be a serious problem today, but it will become increasingly important as certificate lifetimes continue to shrink.

I believe the practical limit of traditional cron-based certificate renewal is approaching. For this kind of workload, an eternal orchestration implemented with Azure Durable Functions is an excellent fit.

Eternal Orchestrations in Durable Task - Microsoft Learn

Eternal orchestrations in Durable Functions make it possible to maintain an independent durable timer for each certificate. Even at large scale, this architecture can renew every certificate at the optimal time indicated by ARI. Acmebot's ARI implementation uses eternal orchestrations to schedule each certificate independently and renew it at the appropriate time.

Acmebot | Automated TLS certificates for Microsoft Azure

It is rare to find a use case that fits Durable Functions this naturally, but the resulting implementation works extremely well. Certificate renewal systems will likely need to adopt a similar architecture as certificate lifetimes continue to become shorter.