All articles

Shorter TLS certificates: what Let's Encrypt's 64 and 45 days mean for you

Published · 8 min read

Listen to the article · read by an AI voice

The padlock in the browser’s address bar depends on a TLS certificate. It encrypts the connection between your visitors and your website, and it shows that the site really belongs to the domain in the address. Certificates are valid only for a limited time. That time is now getting shorter, in fixed steps that the whole industry has agreed on.

For a small business this matters because a certificate that expires unnoticed turns a working website into a problem. Visitors are warned instead of reaching the site normally. With shorter lifetimes, renewal has to happen more often, so doing it by hand or on a home-made schedule becomes a real risk. This article explains the new rules, the Let’s Encrypt timetable, who is affected and what to do now. It is general information as of November 2026.

The new rules for the whole industry

The schedule comes from the CA/Browser Forum, the body in which certificate authorities (the organisations that issue certificates) and browser makers set common rules. Its Ballot SC-081 (version SC081v3) ended its vote on 11 April 2025.

The rules are part of the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates”. They apply to publicly trusted TLS server certificates whichever certificate authority issues them. A certificate you buy from a commercial provider is therefore affected just like a free one.

The maximum validity depends on the day a certificate is issued:

Issued Maximum validity
before 15 March 2026 398 days
from 15 March 2026 200 days
from 15 March 2027 100 days
from 15 March 2029 47 days

The requirements also say that certificates should not exceed 199, 99 and 46 days respectively. They add that certificates should not be issued for the maximum permissible time by default. For these calculations a day is 86,400 seconds, and any time beyond that, even a fraction of a second, counts as an additional day. Dates mean 00:00:00 UTC unless stated otherwise.

A second change is easy to overlook. Before issuing a certificate, an authority must check that the applicant controls the domain. A completed check may be reused for new certificates only for a limited time. That reuse period for domain validation is eventually reduced from 398 days to 10 days. For other identity data, it falls from 825 to 398 days. The overall reductions start in March 2026 and conclude in March 2029.

Let’s Encrypt’s own timetable

Let’s Encrypt, run by the Internet Security Research Group (ISRG), has issued certificates valid for 90 days. It halves this to 45 days by 2028, in step with the industry rules. It uses “profiles” for this. The timetable looks like this:

  • 13 May 2026: the tlsserver profile issues 45-day certificates. This profile is opt-in, meant for early adopters and testing.
  • 10 February 2027: the default profile classic switches to 64-day certificates with a 10-day authorization reuse period. This affects everyone who has not opted into the tlsserver profile or the shortlived profile (6 days).
  • 16 February 2028: the classic profile moves to 45-day certificates with an authorization reuse period of 7 hours.

The authorization reuse period is the time after validating domain control during which Let’s Encrypt allows certificates to be issued for that domain. When the change was announced it was 30 days. By 2028 it drops to 7 hours.

The dates apply to newly issued certificates. You will see the shorter validity at your next renewal after each date, not on the day itself. A certificate you already hold keeps its original lifetime until you renew it.

Why certificates get shorter

Let’s Encrypt gives two reasons: shorter validity improves the security of the internet by limiting the scope of a compromise, and it makes certificate revocation more efficient.

An everyday comparison: a key card for an office that is valid for a year is a bigger risk if it is lost than one that stops working after a few weeks. If a certificate’s private key falls into the wrong hands, the damage is limited to the time the certificate remains valid. Revoking a certificate means declaring it invalid before it expires.

Who is affected

In practice, the following situations need attention:

  • Manual renewal. Let’s Encrypt does not recommend it, because with shorter lifetimes it would have to be done more often.
  • Home-made scripts with a fixed interval. For clients without ARI, Let’s Encrypt says the schedule must be compatible with 45-day certificates. Here is a simple example: a script that renews every 60 days would let a 45-day certificate expire about two weeks before the next run.
  • Old client settings with a fixed renewal point. Since Certbot 4.0.0, a certificate counts as ready for renewal when less than one third of its lifetime remains. Before 4.0.0 the threshold was a fixed 30 days. Explicitly configured values still take precedence, so an old fixed setting stays in force until someone changes it.
  • Anyone who relied on reminder emails. Let’s Encrypt has ended its expiration notification emails. Its reasons: more and more subscribers have reliable automation for renewal, and the service meant keeping millions of email addresses connected to issuance records. If an email from Let’s Encrypt was your safety net, it is gone.
  • Every publicly trusted certificate. The industry rules apply to bought certificates as well, not only to Let’s Encrypt.

What to do now

There is time before 10 February 2027, but the changes are easier to make calmly than under pressure. A checklist:

  1. List all certificates and where they are used. Include every domain and subdomain, shop, mail or other services, and certificates that someone bought and installed years ago. You cannot automate what you do not know about.
  2. Switch to automatic renewal with an ACME client. ACME is the protocol that clients use to request and renew certificates automatically. The goal is a client that decides the timing itself, so nobody has to remember a date.
  3. Enable ACME Renewal Information (ARI). Let’s Encrypt recommends it so that a client renews on time. ARI helps clients know when they need to renew. How to enable it differs from client to client, so your client’s documentation applies.
  4. If your client has no ARI, renew at about two thirds of the lifetime. Let’s Encrypt calls this acceptable behaviour. For a 64-day certificate, two thirds means renewing around day 43.
  5. Check old fixed settings. Look for renewal intervals or thresholds written into scripts, scheduled tasks or client configuration, for example a fixed number of days. As described above, explicit values override the newer defaults, so they must be changed by hand.
  6. Monitor expiry yourself. With no reminder emails, you need your own check that raises an alarm when a certificate gets close to expiry, independent of the renewal process. Automation can fail quietly, for example after a server change. Monitoring is the second line of defence.

To keep each step small, begin with the inventory. Once you know which certificates exist, you can decide for each one whether automation is already in place or has to be set up.

For another setting that is easy to forget until something goes wrong, see our article on SPF, DKIM and DMARC.

How epicsoft handles it for its hosting customers

With the hosting of epicsoft networks, encrypted connections for every domain are part of the setup and of ongoing operations. Updates are installed automatically, and monitoring tells the team when something is wrong. Customers do not have to keep track of renewal dates themselves. Websites built by epicsoft networks also go live with SSL encryption and are kept up to date. You can find details on the pages for hosting and websites.

This article is general information and reflects the situation as of November 2026.

Sources

More articles

Ready for the next step?

There has never been a better time to start. Tell us about your project.

Get in touch