SSL certificates now expire faster: how to automate renewal

Since 15 March 2026, publicly trusted SSL/TLS certificates can last at most 200 days. The limit drops to 100 days on 15 March 2027 and to 47 days on 15 March 2029. If your host or control panel issues and renews certificates automatically, you will barely notice. If anyone renews a certificate by hand, they will be doing it roughly eight times a year by 2029, so the fix is the same for everyone: make renewal automatic, then monitor it. This guide shows how to check where you stand in a minute, how to automate renewal in cPanel, DirectAdmin and on a VPS with Certbot, and how to catch a failed renewal before your visitors do.

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

Every publicly trusted certificate has a maximum lifetime, set by the CA/Browser Forum, the group where certificate authorities and browser makers agree the rules. Ballot SC-081, approved on 11 April 2025, cuts that lifetime in steps. As DigiCert summarises the schedule:

• Until 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

If a certificate's private key leaks, whoever holds it can pose as your site until the certificate expires. Under the old 398-day limit, a stolen key could stay useful for more than a year. At 47 days, that window drops to under seven weeks.

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. Note who issued it. "Let's Encrypt", "ZeroSSL" or "Sectigo" via your host's AutoSSL usually means automatic renewal. A certificate you paid for separately usually means a person renews it.

From the command line

This shows the expiry date, issuer and covered name for any site:

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

Run it for www.example.com too, and for any other names you use, such as a shop subdomain or mail.example.com. Each name can have its own certificate and its own expiry.

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: if you use Let's Encrypt, check that your ACME client is current and does not rely on a fixed 60-day renewal, since the default lifetime drops to 64 days that day.
• 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.

AutoSSL can only validate domains that actually point to the server. If a subdomain points elsewhere (a shop platform, for example), that platform has to provide its certificate.

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

If you run your own server with Certbot (Let's Encrypt's popular client from the EFF), check three things:

certbot certificates
certbot renew --dry-run
systemctl list-timers | grep -i certbot

The first lists each certificate with its domains and expiry date. The second tests renewal against Let's Encrypt's staging server without changing anything. The third confirms that the automatic renewal timer exists; Certbot's documentation notes that most installations set up a systemd timer or cron job, and snap installs include automatic renewal. If neither exists, renewal is not automatic yet.

If a service needs reloading after renewal, use a deploy hook, which runs only after a successful renewal:

certbot renew --deploy-hook "systemctl reload nginx"

Replace nginx with your web server. Other clients, such as acme.sh, work similarly; what matters is that renewal runs on a schedule without anyone touching it.

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 expiry so failures never surprise you

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

• A simple daily check on a server you control. This command exits with an error if the certificate expires within 21 days (1,814,400 seconds), which you can hook into a cron job that emails you:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -checkend 1814400 || echo "Certificate for example.com expires within 21 days"

• An external uptime or certificate monitor that alerts a shared inbox or team chat.
• 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

Let's Encrypt's HTTP-01 challenge can only be done on port 80, at http://yourdomain/.well-known/acme-challenge/. A firewall that blocks port 80, or a rule that sends that path somewhere else, breaks validation. Keep port 80 open, and make sure your redirects let the challenge path through.

The domain points somewhere else

If DNS for a name points to another server, the certificate authority checks the wrong machine. Fix the DNS record, or let the platform that hosts that name issue its own certificate. Our guide on connecting a domain to hosting covers the records.

A CAA record blocks the certificate authority

A CAA record lists which certificate authorities may issue for your domain. If one exists and does not include your CA (for Let's Encrypt, letsencrypt.org), issuance fails. Check with dig +short CAA example.com. If there are no CAA records at all, any public CA may issue after validating your domain.

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 renews our SSL certificates, for every domain and subdomain we use, and what happens if that person is on leave? Please confirm renewal is automatic, that port 80 and any CAA records allow it, and that someone gets an alert if it fails."

If the answer is "the host, automatically, with alerts", you can stop thinking about it. If the answer is "a person, by hand", you have found a small risk that is cheap to fix today and awkward to fix on a Saturday morning.