Let's Encrypt Is Shortening Certificate Lifetimes

Let's Encrypt is cutting its certificate lifetimes in half, from 90 days down to 45 days by 2028. If your team still has a calendar reminder that says "renew the certs," this is the nudge to finally retire it.

The change isn't purely a Let's Encrypt decision. It's part of an industry-wide shift driven by the CA/Browser Forum, and every publicly trusted certificate authority is heading the same direction. Shorter lifetimes mean you'll be renewing (and re-proving you own the domain) a lot more often, so the "we'll get to it" approach to certs is pretty much done.

For teams building platforms, getting a cert issued usually isn't the problem anymore, but making sure they're renewed on time is still critical, more so with shorter expiration times. Below, we'll walk through what Let's Encrypt announced, why the industry landed here, and how the Cycle team handles certificate issuance, renewal, and rollout on the platform.

The Let's Encrypt certificate lifetime timeline

Let's Encrypt announced the change on December 2, 2025, and it's rolling out in three stages using ACME profiles. Profiles let ACME clients choose when they pick up the new behavior, at least until the defaults change underneath them.

A few details worth calling out:

• The first stage is opt-in. The May 2026 change only applies to people who chose the tlsserver profile, mostly early adopters and teams testing ahead of time.
• February 2027 is when most people will notice. That's when the default classic profile drops to 64-day certificates.
• Changes hit at renewal. The dates apply to newly issued certificates, so you'll see the shorter lifetime on your next renewal after each date.
• Staging goes first. Let's Encrypt plans to push each change to its staging environment roughly a month ahead of production.

The authorization reuse period is the part people tend to skip over, and it matters just as much. Today, once you prove control of a domain, Let's Encrypt lets you reuse that validation for 30 days. By 2028, that window shrinks to 7 hours, which effectively means proving domain control on almost every renewal.

Why are certificate lifetimes getting shorter?

It's a security call. Let's Encrypt says shorter lifetimes limit the scope of a compromise and make revocation work better. The CA/Browser Forum ballot adds a few more reasons: certs go stale as domains change hands, CRLs and OCSP don't scale well, mis-issued certs age out faster, and weak cryptography can be swapped out sooner.

For a recent reminder of why limiting the damage from a compromise matters, see eMudhra Intermediate CAs Compromised, our write-up on the eight intermediate CA keys that had to be blocked and revoked in October.

How Cycle handles TLS certificates

Turn on TLS for a LINKED record and Cycle provisions a Let's Encrypt certificate, installs it in the load balancer, and keeps it renewed.

Need Cloudflare origin certs, DigiCert, or another CA? Upload them as user-supplied certificates. Cycle detects the domains and uses them for any matching LINKED record. It can't renew certs it didn't issue, but it'll alert the hub owner 30 days before they expire.

And if a workload needs to handle TLS itself instead of relying on the load balancer, Cycle can inject generated certificates directly into a container through a container integration. For services that live outside Cycle entirely, the open source Cycle Certificate Manager can pull Cycle-generated certificates down and keep them fresh.

Renewal and rollout, handled end to end

Cycle doesn't stop at renewing certificates. It applies them too, without downtime. Once TLS is on, Cycle issues the cert, installs it in the load balancer, renews it well before expiration, and rolls the new one in without dropping traffic. Every attempt is recorded in the TLS certificate log, so failures are easy to trace. It works the same on bare metal, on-prem, or in the cloud, which is a big part of why we call Cycle the platform for building platforms.

DNS challenge or HTTP challenge: both are built in

To issue a certificate, Let's Encrypt needs proof that you control the domain. Cycle supports two ways of providing that proof, and since July, HTTP challenge has joined the DNS challenge as a first-class option.

DNS challenge works for zones hosted on Cycle and is the only option for wildcard certificates. HTTP challenge is built into the load balancer and works whether or not your zone is on Cycle. You'll need load balancer v2026.07.23.1 or newer, with the LINKED record pointing at a container or VM in an environment that has a live load balancer.

The practical win with HTTP challenge is flexibility around DNS. If your zone lives with another provider, and moving it isn't on the table, you can still get automatically managed Let's Encrypt certificates on Cycle. No DNS API keys sitting in a secrets manager, and no waiting on TXT record propagation.

In Kubernetes, this usually means running cert-manager, configuring an issuer, and adding ingress annotations for each domain. On Cycle, TLS is a setting on the LINKED record and the load balancer handles the challenge.