TLS certificate lifetimes are getting shorter, worth automating now

Happy October! This week I've been working with four different projects that all have the same need: automatic renewals for SSL/TLS certificates.

This is becoming increasingly important because publicly trusted TLS certificate lifetimes are getting shorter. For a long time, developers were used to certificates lasting about a year. That is now changing.

The CA/Browser Forum has defined the following maximum validity periods for publicly trusted TLS certificates:

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

At the time of writing this (October 2026), we are already in the 200 day period. These are maximum values, by the way. Certificate authorities can choose shorter lifetimes.

Let's Encrypt, for example, currently issues 90 day certificates, but has announced a move to 64 day certificates in 2027 and 45 day certificates in 2028.

It is easy to see where this is heading: manual certificate renewal is no longer a reasonable long-term strategy. If renewing a certificate means somebody needs to remember a calendar reminder, download a new certificate, copy it to a server, update a binding, and restart something, then the process will eventually fail.

In my opinion, certificate renewal should be automated, now is a good time to do that before it starts to bite your.

For public web certificates, the ACME process (Automatic Certificate Management Environment) is the obvious protocol to look at. Tools such as Let's Encrypt clients can request, validate, install, and renew certificates automatically.

A typical automated process should handle:

• requesting or renewing the certificate
• certificate and domain validation
• installing the new certificate
• updating the web server or application binding
• reloading/restarting the service if required
• monitoring that the renewal actually succeeded
• possibly, removing the old certificate.

That second-last point is important. Automation without monitoring only changes the problem from "somebody forgot to renew the certificate" to "the renewal job has been broken for three months".

For example, an alert at 30 days remaining can give plenty of time to investigate a broken renewal process before users see certificate errors.

Also remember that certificate renewal and certificate installation are two different problems. Getting a new certificate is useful only if the application actually starts using it.

Check things such as:

• IIS HTTPS bindings
• reverse proxy configuration
• Kestrel certificate configuration
• load balancers and application gateways
• containers and Kubernetes secrets
• Azure services that reference certificates.

Shorter certificate lifetimes are not necessarily a bad thing. They reduce the amount of time a compromised or incorrectly issued certificate remains useful.

But they also change certificate management from an occasional maintenance task into a normal automated operational process.

Hope this helps!