Online Life Guide

Let’s Encrypt certificates are getting shorter: how to make sure your site never expires

Free Let’s Encrypt certificates will drop from 90 days to 64 days in February 2027, then to 45 days in 2028. If your renewals are fully automated you are probably fine, but now is the time to check, because a missed renewal means a browser warning on your site.

By OwnYourStack Admin · Published

Let's Encrypt logo
Let's Encrypt © Let's Encrypt / ISRG

Let’s Encrypt, the non-profit certificate authority that secures a huge share of the web for free, is halving the lifetime of its certificates. The plan, announced in December 2025, follows a CA/Browser Forum decision to cap the validity of all public TLS certificates at 47 days by 2029.

The timeline

DateWhat changes
13 May 2026The optional tlsserver profile started issuing 45-day certificates for early adopters
14 October 2026The staging (test) environment issues 64-day certificates, so you can test now
10 February 2027The default classic profile switches to 64-day certificates; a domain validation can be reused for 10 days instead of 30
16 February 2028The default profile moves to 45-day certificates, with validations reusable for only 7 hours

The changes apply at your next renewal after each date, so nothing breaks overnight. What changes is how often renewals have to succeed.

Why shorter is considered safer

A stolen or mis-issued certificate is only dangerous for as long as it remains valid, and certificate revocation has never worked reliably in browsers. Shorter lifetimes limit the damage and push everyone towards full automation, which is the real goal.

Who needs to act

  • Fully automated setups (Certbot, acme.sh, Caddy, Traefik, a hosting control panel with built-in Let’s Encrypt): usually nothing to do, but worth the five-minute check below.
  • Anyone who copies certificates by hand into a router, NAS, mail server, load balancer or appliance: you are the people at risk. Renewing manually every 60 or so days was a chore; every few weeks is a recipe for an outage.
  • Scripts with hard-coded schedules, such as “renew on the first of every second month”: these will fail once certificates last 45 days.

Five checks to do this week

1. Confirm renewal actually runs

For Certbot on a systemd-based Linux server, systemctl list-timers | grep certbot should show a timer firing at least daily. With acme.sh, crontab -l should show its daily job.

2. Do a dry run against staging

certbot renew --dry-run performs a full renewal against the Let’s Encrypt staging environment without replacing your real certificates. Since staging now issues 64-day certificates, this is the closest you can get to testing the 2027 behaviour today.

3. Renew based on remaining lifetime, not the calendar

Let’s Encrypt recommends renewing about two-thirds of the way through a certificate’s life. Clients that decide based on the certificate’s expiry date, or that support ACME Renewal Information (ARI), where the authority suggests a renewal window, will adapt on their own. Fixed dates will not.

4. Make sure services reload the new certificate

A renewed file on disk is useless if Nginx, Apache, Postfix, Dovecot or your reverse proxy keeps serving the old one from memory. Check that your client runs a deploy or reload hook after each renewal.

5. Add expiry monitoring

Let’s Encrypt’s own advice is to be alerted as soon as a renewal fails. An uptime monitor that checks certificate expiry (Uptime Kuma, which you can self-host, does this) will warn you with days to spare rather than leaving you to find out from a visitor.

And for devices that cannot be automated?

Put them behind something that can. A reverse proxy such as Caddy or Traefik can hold the public certificate and renew it automatically, while the old appliance behind it keeps a long-lived internal certificate. Otherwise, check whether the device’s firmware has gained ACME support: many NAS and router makers have added it in recent years.

Sources