SSL certificates now expire faster: how to automate renewal

Publicly trusted TLS server certificates issued on or after 15 March 2026 are capped at 200 days. The cap drops to 100 days for issuance from 15 March 2027 and 47 days from 15 March 2029. Existing certificates keep their own expiry dates. Reliable automation reduces manual work, but it still needs validation, deployment and alerts. This guide helps you identify the renewal owner and check the complete process.

The Saturday morning problem

Picture a Saturday morning. A customer taps the link in your Instagram bio and lands on a full-screen browser warning, something like "Your connection is not private." She does not read the small print. She closes the tab and buys from someone else.

Nothing was hacked. No server crashed. A small file reached its expiry date and nobody renewed it.

That file is an SSL certificate, and from now on it expires more often, by design. Whether that matters to you depends on one question: who renews it?

What changed, and when

The CA/Browser Forum’s TLS Baseline Requirements govern publicly trusted TLS server certificates, not every private, client, code-signing or CA certificate. Section 6.3.2 contains the subscriber-certificate schedule introduced by ballot SC-081:

• Issued before 15 March 2026: up to 398 days.
• From 15 March 2026: up to 200 days (where we are now).
• From 15 March 2027: up to 100 days.
• From 15 March 2029: up to 47 days.

The limit applies to certificates issued on or after each date. A certificate you already hold keeps its expiry date, so you feel the change at your next renewal.

Two more rules change alongside it. The time a certificate authority may reuse its proof that you control a domain shrinks on the same dates, ending at just 10 days in 2029, so proving ownership becomes a routine, repeated step. And for Organisation Validated (OV) and Extended Validation (EV) certificates, the company identity checks can only be reused for 398 days from March 2026, down from 825.

Let's Encrypt, the free certificate authority behind many hosting control panels, is shortening its own certificates on a published timeline: a 45-day opt-in profile from 13 May 2026, a 64-day default from 10 February 2027, and a 45-day default from 16 February 2028.

Why shorter is safer

Shorter validity limits how long a compromised or misissued certificate can remain valid, but it does not replace incident response. If a private key is compromised, arrange revocation and replacement using a new key; waiting for expiry or repeatedly reusing the compromised key is not a safe response.

Think of it as changing the locks every few weeks instead of once a year. Tedious if you do it by hand. Invisible if a machine does it.

Are you affected? It depends on who renews

The automatic group. Your host or control panel issues a free certificate and renews it in the background. You have probably never thought about it, which is the point. Hostlelo's shared hosting, for example, lists "Free SSL issued and renewed for you." For this group, shorter lifetimes change almost nothing, provided the automation keeps working.

The manual group. You bought a certificate, received a file, and installed it yourself, or a developer did. At 200 days that is a renewal almost twice a year. At 100 days, nearly four. At 47 days, about eight, and in practice more, because you renew before the old one runs out. Each renewal is a chance to forget, and a calendar reminder in one person's diary does not scale to eight a year.

The 60-second check

In a browser

1. Open your site and click the padlock or site information icon beside the address bar.
2. Open the certificate details and find the "valid to" or "expires on" date.
3. Record the issuer, but do not use its name or the price of the certificate as proof of automation. A free certificate can be installed manually, and a paid certificate can use automated issuance. Confirm the actual client, scheduler, deployment and recent successful renewal evidence.

From the command line

This diagnostic displays the presented leaf certificate’s expiry, issuer and subject. It does not establish hostname matching or chain trust, and the subject alone is not the full list of covered names. Check the Subject Alternative Name extension and use a normally verified TLS connection too:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate -issuer -subject

Repeat the HTTPS check for each web hostname. It tests TLS on port 443, usually the CDN edge if one is present. It does not test SMTP/IMAP just because the hostname starts with mail; inventory and test each real service, port and origin separately.

Make a list of every certificate you depend on

Most small businesses have more certificates than they think. Before automating anything, spend ten minutes writing a simple list with one line per name:

• The name: example.com, www.example.com, shop.example.com, mail.example.com, a booking or helpdesk subdomain, a staging site.
• Where it is served from: your hosting account, a VPS, a shop platform, a CDN.
• Who issues and renews it: AutoSSL, DirectAdmin, Certbot, the platform, or a named person.
• The current expiry date, from the checks above.

A made-up example of why this matters. A clinic's main website renews automatically through its host, but its online booking page runs on a separate subdomain that a freelancer set up years ago with a certificate he renews by hand. The main site is fine; the booking page breaks every time he is busy. The list is what finds that gap.

A simple timeline to work to

• Now: finish the list, switch every manual certificate you can to automatic renewal, and add monitoring.
• Before 10 February 2027: audit your Let’s Encrypt client’s renewal decision, scheduler, validation and deployment. Use ARI where supported or lifetime-aware timing; do not replace an old fixed interval with another fixed day count.
• Before 15 March 2027: the public limit falls to 100 days. Any certificate still renewed by hand now needs attention almost every quarter.
• Before 16 February 2028: Let's Encrypt's default moves to 45 days. Renewals should be fully automatic by now.
• Before 15 March 2029: the 47-day limit and 10-day domain validation reuse arrive. By this point, manual renewal is simply not practical.

How to automate renewal

On cPanel hosting: AutoSSL

Most cPanel hosts issue free domain-validated certificates through AutoSSL.

1. Open cPanel > Security > SSL/TLS Status.
2. Check each domain and subdomain. The status shows whether it has a valid certificate, when AutoSSL last ran for it, and whether anything is expiring.
3. Use the filter to see which domains are Included in AutoSSL and which are Excluded. Make sure every name you use is included.

Validation depends on the configured challenge and DNS/CDN route. A proxied hostname need not resolve publicly to the origin, and DNS validation differs from HTTP validation. Check the actual AutoSSL error and provider documentation before changing DNS or disabling a proxy; a separately hosted platform needs its own certificate owner.

On DirectAdmin

At User level, open SSL Certificates and choose the automatic ACME certificate (Let's Encrypt or ZeroSSL) for the domain, www and mail. DirectAdmin's documentation says certificates are then issued and renewed automatically. Our DirectAdmin setup guide covers it step by step.

On a VPS with Certbot

For Certbot, first inspect the inventory and scheduler; then review validation settings and configured hooks before a controlled dry run. These illustrative commands require suitable access and have not been run on your server. Replace example.com with the certificate name from the inventory:

certbot certificates
systemctl list-timers --all
# After reviewing validation settings and hooks:
certbot renew --cert-name example.com --dry-run

The dry run normally uses Let’s Encrypt staging without deploying its test certificate, but it can trigger temporary configuration changes and pre/post hooks. A custom server setting can change the endpoint. Timer names vary; inspect the corresponding service, cron or external scheduler and recent results. A listed timer alone is not proof of successful renewal.

Deployment is a separate check. A deploy hook can reload a service after renewal; ordinary dry runs do not execute it unless explicitly requested. Review existing installer behavior and hooks before adding one. For a plain Nginx service, an administrator could use a reviewed hook body such as:

#!/bin/sh
set -eu
/usr/sbin/nginx -t
/bin/systemctl reload nginx

This example is not a complete Certbot installation. Verify executable paths, service name and permissions, and configure it through the documented deploy-hook mechanism only if an installer does not already deploy correctly. Alert on failures and compare the certificate served by the live endpoint with the renewed certificate on disk.

Renew on Let's Encrypt's schedule, not a fixed number

With lifetimes shrinking, renewal timing written as "every 60 days" will break. Let's Encrypt says renewing at a hardcoded interval of 60 days will no longer be sufficient, and recommends clients that use ACME Renewal Information (ARI), which tells your client when to renew. As a fallback, its integration guide suggests renewing when a third of the certificate's lifetime is left, checking at least twice a day at a random time. In practice: keep your ACME client up to date, and avoid custom scripts with fixed day counts.

Behind Cloudflare

If your site is proxied through Cloudflare, visitors see Cloudflare's edge certificate, which Cloudflare manages. You still need a valid certificate on your own server for the Full (strict) setting, which our HTTPS redirect guide explains, so automate that one too.

Paid OV or EV certificates

If you need a paid certificate, ask your certificate authority or reseller whether they support automated issuance (many offer ACME). Plan for the yearly organisation re-check that the new identity reuse limit brings, and make sure renewal reminders go to a shared mailbox, not one person.

Monitor TLS and expiry, and test the alert path

Automation fails quietly: a DNS change, a firewall rule or a full disk can stop renewals. Add a safety net.

• The earlier expiry-only OpenSSL pipeline does not verify hostname and trust, and appending a successful echo can hide a nonzero exit. Use a monitor with explicit connection, TLS and expiry failure states. The Python 3 example below checks port 443 using the system trust store and exits nonzero on failure; replace the hostname and choose a warning window suited to the actual certificate lifetime:

import socket
import ssl
import sys
import time

host = "example.com"
warning_days = 14
try:
    context = ssl.create_default_context()
    with socket.create_connection((host, 443), timeout=8) as tcp:
        with context.wrap_socket(tcp, server_hostname=host) as tls:
            certificate = tls.getpeercert()
    remaining = ssl.cert_time_to_seconds(certificate["notAfter"]) - time.time()
    if remaining <= warning_days * 86400:
        print(f"EXPIRING {host}: {remaining / 86400:.1f} days remain")
        sys.exit(1)
    print(f"TLS_OK {host}: {remaining / 86400:.1f} days remain")
except (OSError, ValueError, KeyError) as error:
    print(f"TLS_CHECK_FAILED {host}: {error}")
    sys.exit(1)

• Connect nonzero exits to a notification path and test that someone receives them. This example does not establish application health, revocation status, every CDN/backend certificate, mail TLS or a strict end-to-end timeout for DNS resolution. A short-lived profile may need a different warning window. The detailed Let’s Encrypt audit covers renewal, deployment and live-endpoint checks.
• Ask your host who gets alerted when automatic renewal fails, and how fast they act.

When automatic renewal fails: common causes

Port 80 is blocked or redirected badly

HTTP-01 needs inbound validation on port 80 and the correct challenge response. Let’s Encrypt follows supported HTTP/HTTPS redirects, so a redirect is not automatically a failure. Review the actual challenge route and all relevant frontends; DNS-01 has different requirements and does not require opening port 80.

The domain points somewhere else

Check A and AAAA records, proxies and challenge routing against the intended architecture. Do not overwrite DNS merely because it points to a CDN rather than the origin. If a separate platform serves the name, confirm which platform owns validation and certificate deployment.

A CAA record blocks the certificate authority

Check the effective CAA policy for the requested name, including parent records and any CNAME target. An empty answer at one hostname is not proof that no policy applies. The issue and issuewild properties differ; diagnose DNS/CAA errors before changing policy. If no applicable restricting policy exists, CAA itself does not restrict which public CA may issue after validation.

You need a wildcard certificate

Wildcards such as *.example.com cannot use the HTTP-01 challenge. They need DNS-01, which means a TXT record at _acme-challenge.example.com, normally created automatically through your DNS provider's API.

Only one name is covered

The certificate covers example.com but not www.example.com, or the other way round. Make sure both names are included in AutoSSL, DirectAdmin or your Certbot command.

Two questions for your host

• Who issues and renews my certificate, and how often?
• If a renewal fails, who gets the alert, and how fast can you fix it?

A good answer is specific. "It renews automatically, and we email you if it ever fails" beats "don't worry about it." If you are comparing providers, our checklist for choosing a UAE hosting company turns questions like these into a buying process.

The one message worth forwarding

Send this to whoever looks after your website:

“Who owns renewal and deployment for every web, origin and mail certificate we use? Please confirm the actual challenge method, successful recent runs, certificate coverage and the alert/escalation path. If anything is manual, propose a tested automation plan and explain any cost before we approve changes.”

A specific answer should be backed by recent evidence and a tested alert path. Keep reviewing it after DNS, CDN, hosting or certificate-profile changes. Automatic issuance is useful, but successful deployment and monitoring are what keep the right certificate in service.