Let's Encrypt certificates at 45 days: reconfigure renewal before expiry

Anyone managing Let's Encrypt certificates with a script written years ago and left untouched has a date to mark: 13 May 2026. From that day, the ACME tlsserver profile, previously experimental, will issue certificates valid for 45 days instead of 90. This is the first step in a trajectory that, according to the Let's Encrypt official blog, will bring the standard certificate lifetime from 90 to 45 days by 2028, in line with CA/Browser Forum requirements.

The tlsserver profile remains opt-in: it must be explicitly chosen in configuration, it is not the default. Those who make no changes will continue to receive 90-day certificates until the next step: on 10 February 2027, Let's Encrypt will move the classic default profile to 64-day certificates with a 10-day authorisation reuse period, which will affect all users who have not chosen the tlsserver or shortlived profiles (6 days). The final milestone is set for 16 February 2028, when the classic profile will move to 45-day certificates with a 7-hour authorisation reuse period.

Why a script "that has always worked" can break

The critical point is not the expiry date itself, but the renewal intervals written by hand. The official post states it plainly: renewing at a fixed 60-day interval will no longer be sufficient, whereas acceptable behaviour is to renew approximately at two-thirds of the current certificate's lifetime.

Translated into numbers: with 90-day certificates, a cron running every 60 days still leaves a 30-day buffer. With 45-day certificates, the same 60-day cron tries to renew a certificate that has already been expired for two weeks. The "two-thirds" rule applied to 45 days gives a renewal around day 30; applied to 64 days (the 2027 milestone) gives a renewal around day 42–43.

What certbot actually does, and what changes

Certbot does not renew "every so many days" on a calendar basis: the certbot renew command checks the expiry date of each certificate in /etc/letsencrypt/live/ and renews only those that are about to expire, according to its own internal logic. The standard package already installs a cron job or systemd timer that runs certbot renew twice a day: those who installed certbot from a system package (apt, dnf, snap) should not touch anything, because the expiry check is handled by the client itself, not by a fixed interval set by the user. The real risk is for those who years ago replaced the system timer with their own cron like 0 3 1 */2 * certbot renew (one attempt every two months): with 45-day certificates, such a broad check interval leaves little or no margin in case of temporary failure (DNS not propagated, rate limit, provider blocking).

ARI: the mechanism Let's Encrypt wants to become standard

To avoid relying on empirical formulas, Let's Encrypt is pushing adoption of ARI (ACME Renewal Information), a mechanism by which the server tells the client when it should renew, instead of letting the client guess with a fixed percentage of validity. The official post puts it first among recommended actions: to ensure your ACME client renews in time, Let's Encrypt recommends using ACME Renewal Information (ARI), whereas those with a client that does not yet support ARI must ensure it runs on software compatible with 45-day certificates.

For those using acme.sh or lego, the practical check is straightforward: check the changelog of your client to see if ARI support is present (recent versions of both projects have added it) and, if missing, manually shorten the interval of your existing cron rather than trusting the default value left from the initial installation.

Monitoring matters more than cron

An indication that the official source repeats explicitly concerns downstream checking: manually renewing certificates is not recommended, because with shorter lifetimes it needs to be done more often, and Let's Encrypt advises having a monitoring system sufficient to alert if a certificate is not renewed as expected. In practice: an external check that verifies the expiry date of the exposed certificate (not the one expected by the script) via openssl s_client -connect domain:443 -servername domain | openssl x509 -noout -enddate, scheduled independently of the renewal cron, remains the simplest safety net to add straight away, even before touching the automation scripts.

Minimal checklist for multi-domain management

• Verify which ACME profile your current configuration uses (classic is the default, no action required before February 2027).
• If you have deliberately switched to tlsserver for testing, verify that the cron or timer no longer assumes 90-day validity.
• Separate the "real" expiry check (by querying the exposed certificate) from the ACME client log: these are two different sources, and the second can lie if renewal fails silently.
• Plan, by early 2027, verification of all custom crons that replace the default timer of clients, because that is where most problems hide when the window narrows.

Source: Let's Encrypt official blog, "Decreasing Certificate Lifetimes to 45 Days", 2 December 2025, https://letsencrypt.org/2025/12/02/from-90-to-45