Renew your certificates by automation or not at all

The claim

A TLS certificate that a human has to remember to renew will, eventually, expire on a weekend and take your site down — and the industry is actively removing the margin for that mistake. Certificate lifetimes are shrinking toward 47 days by 2029, which makes manual renewal not merely risky but impractical: nobody is going to run a manual process eight times a year without missing once. Automate the renewal, monitor the automation, and the entire category of certificate-expiry outages disappears.

Why this is getting more urgent, not less

The maximum validity period for public TLS certificates has been falling for years, and the schedule now points sharply downward: from the current 398 days, toward 200, then 100, and 47 days by 2029. The reasoning is sound — shorter lifetimes limit the damage of a compromised key and force the automation that makes the whole system more robust. But the consequence for you is direct: a certificate you renew by hand today, four times a decade, becomes one you would renew eight times a year, and a manual process at that frequency is a certainty of eventual failure, not a possibility.

The automated setup

The ACME protocol issues and renews certificates without human involvement. A client proves control of the domain, receives the certificate, and repeats before expiry. With certbot:

certbot certonly --nginx -d example.ca -d www.example.ca

# certbot installs a systemd timer that renews automatically;
# confirm it exists and check when it next runs:
systemctl list-timers | grep certbot

The renewal runs twice daily and does nothing until a certificate is within 30 days of expiry, at which point it renews and reloads the web server. Once this is working, the certificate renews itself indefinitely and you never think about it — which is the goal, and also the trap, because a silent automated system that breaks is exactly as invisible as no system at all.

Prefer DNS validation for anything non-trivial

There are two ways to prove domain control, and the choice matters more than it first appears. HTTP validation places a file on your web server; it is simple but breaks for wildcard certificates and for any host not reachable on port 80 from the public internet. DNS validation places a temporary record in your zone; it is slightly more setup but handles wildcards, works for internal hosts, and does not depend on your web server being reachable at renewal time.

certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/dns.ini \
  -d '*.example.ca' -d example.ca

For a single public website, HTTP validation is fine. For anything with a wildcard, multiple hosts, or internal services, DNS validation is the more robust default, and adopting it early avoids a migration later.

The rule that makes automation trustworthy: monitor it separately

Here is the failure that catches teams who have automated correctly: the renewal automation itself breaks — an API credential expires, a DNS provider changes an interface, a permission is revoked — and because the system was silent when working, its silence when broken raises no alarm. The certificate then expires exactly as it would have with no automation at all, and the team is surprised because they believed the problem was solved.

The defence is an independent check that does not know or care how the certificate is renewed. It connects from outside and reads the actual expiry date off the live certificate:

echo | openssl s_client -servername example.ca -connect example.ca:443 2>/dev/null \
  | openssl x509 -noout -enddate

Run that daily from a host that is not the web server, parse the date, and alert if expiry is under 14 days away. This check passes regardless of which client or method issued the certificate, and it fails whether the cause is broken automation, a manual certificate someone forgot, or a renewal that ran but failed to reload the server. It is the backstop that turns "we automated it" into "we know it is working".

The reload nobody tests

A subtle and common failure: the certificate renews correctly on disk, but the web server keeps serving the old one in memory because nothing reloaded it. The new certificate is right there in the filesystem, valid, and the site still presents the expired one to visitors. Ensure the renewal hook reloads the server, and test it — the external monitor above catches this case too, because it reads what is actually being served, not what is sitting in a file.

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

What to do this week

Confirm three things, in order. First, that every public certificate you run renews automatically — find any that do not and migrate them to an ACME client now, before the short-lifetime schedule makes it urgent. Second, that an independent external check reads your live expiry dates and alerts with real headroom. Third, that renewal reloads the serving process. A site whose certificates renew automatically, whose renewal is monitored by something that does not trust the renewal, and whose server actually picks up the new certificate has removed one of the most common and most avoidable outages there is — and has done it in a way that keeps working as certificate lifetimes continue to shrink.