Contact us

Managed servers · 7 min read

Certificates now last 200 days, and soon 47

Since 15 March 2026 a public TLS certificate can't be valid for more than 200 days, and by 2029 the limit is 47. Renewing by hand stops working. What to list, what to automate and how to notice when the automation quietly fails.

The dates

The CA/Browser Forum voted (ballot SC-081) to cut the maximum life of a publicly trusted TLS certificate in three steps:

From Longest a certificate can be valid Domain validation can be reused for
15 March 2026 200 days 200 days
15 March 2027 100 days 100 days
15 March 2029 47 days 10 days

At 47 days, renewing at about two thirds of the lifetime means every certificate gets replaced roughly once a month. A calendar reminder and someone pasting a certificate into a control panel will break sooner or later. So it has to be automated, and something other than the automation has to check that it worked.

First, find every certificate

Web servers are the obvious ones. The certificates that expire without anyone noticing are elsewhere:

  • Mail: SMTP with STARTTLS on 25 and 587, SMTPS on 465, IMAPS on 993.
  • FTPS on hosting accounts.
  • Control panels and webmail.
  • Load balancers, CDNs and reverse proxies that keep their own copy.
  • Appliances: NAS boxes, firewalls, printers with a web page.
  • Internal services that happen to use public certificates.

For each one, note the hostname, port, issuer, how it gets renewed and who's responsible. Certificate Transparency logs help fill gaps, because every public certificate issued for your domain is listed there.

Then automate the renewals

cPanel hosting. AutoSSL renews certificates for the domains on the account, including mail and service subdomains, as long as domain validation succeeds. When it doesn't, the cause is usually a domain whose DNS points somewhere else, or a redirect rule that also catches /.well-known/acme-challenge/. Leave that path out of any forced redirect:

RewriteCond %{REQUEST_URI} ^/\.well-known/ [NC]
RewriteRule ^ - [L]

Your own Linux servers. An ACME client (certbot, acme.sh, or whatever the web server has built in) on a timer, with a deploy hook that reloads every service using the certificate. A renewed file that nothing reloads is a classic way to have an outage anyway:

certbot renew --deploy-hook "systemctl reload httpd postfix dovecot"

Wildcards and internal names need DNS-01 validation, which means API access to the DNS zone. If your DNS provider allows it, limit that API token to the _acme-challenge records.

Check from the outside

The monitoring should connect to each endpoint and look at the certificate it actually gets. Don't rely on the renewal tool saying it succeeded:

# warning below 21 days, critical below 7
check_http -H shop.example.com -S --sni -C 21,7
check_smtp -H mail.example.com -p 587 -S -D 21,7

With 47-day certificates, a warning at 21 days left means renewal has already failed several times. That's exactly when a person needs to look.

Make sure a failure gets noticed

Once a quarter, check that a failed renewal actually produces an alert. Point a test hostname at a broken validation path, or use a staging CA, and see whether the warning arrives. Automation that fails without telling anyone is worse than a manual process, because nobody thinks they need to look.

Got something that needs looking after?

Tell us what you have and what's bothering you. You'll hear back within one working day, usually with a few questions before any price.