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.