I just learned that Let’s Encrypt will shorten its certificates from 90 days to 64 days on February 10, 2027, then to 45 days in 2028.

For most organizations, that changes little. The change that will affect you took effect last March. It targets the certificates you buy.

A short history of encryption

Remember when the padlock showed up only on the payment page? The rest of the site was in the clear, sometimes even the login page.

The argument at the time was processor capacity. In the early 2000s, that was true. Opening an encrypted connection was expensive in computation. Large organizations bought accelerator cards or handed encryption off to their load balancer.

That argument died in 2010. Google turned HTTPS on by default for Gmail without adding a server. The result Google published: less than 1% of CPU load, less than 10 KB of memory per connection, and less than 2% of extra network traffic. The same year, Intel built AES encryption directly into its processors.

The real blocker was elsewhere. A certificate cost money every year. Someone had to request it, get it validated, install it by hand, and watch the expiration date. For a website, nobody saw the benefit.

Several events moved things along. In 2010, the Firefox extension Firesheep let anyone in a café steal a neighbor’s Facebook session on the same Wi-Fi. In 2013, Edward Snowden revealed the scale of surveillance on unencrypted traffic. In 2014, Google made HTTPS a ranking signal in its search results.

The real change comes at the end of 2015. Let’s Encrypt issues free certificates, renewed automatically by a protocol called ACME (Automatic Certificate Management Environment). The cost and the manual work disappear. In July 2018, Chrome labels every HTTP site “Not secure.”

Where we are

In 2015, 30 to 45% of page loads in Chrome were over HTTPS. Today we are close to 100%. A site without encryption is the exception.

This month, Chrome 154 goes further. It shows a warning before opening a public site without HTTPS. The visitor has to click to continue. Internal addresses, such as 192.168.0.1 or “intranet/”, are excluded.

A forgotten old page on an HTTP subdomain? Your customers now see a warning before they see you.

Another change: how long a certificate lives

A certificate is your site’s identity card. It proves to the browser that you own the domain. Once it expires, the browser shows a full-screen error. Most visitors stop there.

Ten years ago, a certificate could last about three years. Since 2020, the maximum is 398 days.

In April 2025, the CA/Browser Forum (the group of certification authorities and browser makers) adopted this schedule, for certificates issued from these dates:

  • March 15, 2026: 200 days maximum
  • March 15, 2027: 100 days maximum
  • March 15, 2029: 47 days maximum

A certificate installed by hand once a year now has to be installed twice. About four times starting in 2027. About eight times in 2029.

Why? Revocation, the mechanism that cancels a stolen or mistakenly issued certificate, works poorly. A stolen 47-day certificate becomes useless after 47 days at most.

What will break on your side

Your site on a modern host? Probably nothing. Renewal there is already automatic.

The risk is in equipment where the certificate is installed by hand: the firewall’s remote-access portal (VPN), Outlook Web Access on an internal Exchange server, the Remote Desktop gateway, your ERP client portal, or the NAS reachable from outside.

Often, a single person at your managed service provider (MSP) knows the procedure. They redo it from memory once a year.

Eight renewals a year is eight chances to forget.

Microsoft forgot. On February 3, 2020, Teams was down for about three hours for millions of users. The cause was an expired certificate.

Were you counting on Let’s Encrypt’s warning email? It has not existed since June 2025.

Do your scripts renew on a fixed interval, every 60 days for example? With a 64-day certificate, you have 4 days of margin left.

The problem no rule touches: self-signed certificates

During my penetration tests, I still see many Internet-facing services with a self-signed certificate. That is a certificate the device made for itself. No authority vouches for it.

I find them on administration interfaces of firewalls, switches, and servers, on VPN portals, and on NAS devices.

The CA/Browser Forum schedule does not touch them. Nobody issues them except the device itself.

A self-signed certificate encrypts the connection. It does not prove you are talking to the right device. An attacker placed in the middle can present their own certificate. The browser warning will look identical to the one people click through every day.

That is the real damage. An expired or self-signed certificate trains employees to click “Continue anyway.” That is exactly the reflex an attacker wants them to have.

And an administration interface reachable from the Internet is a more serious problem than its certificate.

What the standards say

ISO 27001 does not set a certificate lifetime. Annex A, control 8.24 (use of cryptography), does require rules for managing keys, including their life cycle. Control 5.9 requires an inventory of assets.

A certificate missing from the inventory has no owner. It ends up expiring on a Friday night.

Here are a few questions asked in an audit: show me the list of your certificates, their expiration dates, and who renews them.

Under Quebec’s Loi 25, section 10 of the private-sector privacy law requires reasonable security measures given the sensitivity of the personal information. A form that collects personal information on an unencrypted page, in 2026, is not defensible at all.

In practice

At a minimum, here is what I would do:

  1. Check your main site. That is what I do first, with loi25.certi360.com (quick and free).
  2. Build an inventory of certificates exposed to the Internet: domain, equipment, issuer, expiration date, owner. The free site crt.sh lists every public certificate issued for your domain. You will find forgotten subdomains there. Self-signed certificates are not on it. Look for those device by device.
  3. Sort each certificate: automatic renewal or manual.
  4. For each manual certificate, ask your MSP whether the equipment supports ACME. Several recent firewalls do. If not, put a load balancer or a cloud service that manages the certificate in front of the equipment. Or plan to replace it.
  5. Replace self-signed certificates exposed to the Internet. Better: take administration interfaces off the Internet and reach them through the VPN.
  6. Watch expiration from the outside, with a 30-day alert to a shared address, not to a single person.
  7. If you use Let’s Encrypt, test your renewals in their staging environment starting October 14, 2026. Look for hardcoded delays in your scripts, such as 60, 80, or 83 days. Renew at about two-thirds of the lifetime, not on a fixed date. Check that your ACME client supports ARI (ACME Renewal Information), the feature that lets Let’s Encrypt tell your tool when to renew.
  8. Check your subdomains: none of them should serve a public page over HTTP.

In short

Encryption was settled a long time ago. What remains is the discipline of renewal, nearly monthly by 2029. How many certificates in your organization are installed by hand by a single person?

Want to know where you stand? Let’s talk.

References