As TLS certificate lifetimes shrink toward 47 days, experts urge checking expiry from outside the renewing host

The author of a dnsnotify post on dev.to ^[18] wrote: "At eight renewals a year nobody renews by hand, so nobody forgets. What happens instead is that the automation stops working and nothing tells you." ^[8] Eight is roughly how many 47-day lifetimes fit in a year. The same post recommends renewing with a third of the lifetime left ^[17]. On a 47-day certificate that is about 15.7 days, so renewal lands near day 31 ^[1]. Renewed on that schedule, a hostname renews about 11.7 times a year ^[2].

The cap comes down in steps. Under today's 200-day cap a site needs at least about 1.8 certificates a year, and about 3.7 under the 100-day cap from March 2027 ^[3]. A person with a calendar can still manage that. At 47 days, from March 2029 ^[3], I would not trust one to. The post's case for the ballot rests on revocation: it has never worked well in browsers, so making certificates expire sooner is the practical way to limit damage from a stolen or mis-issued one ^[6].

In every failure the post lists, the certificate on disk, the renewal log, or both look fine ^[13]. A rebuilt server loses its cron entry or systemd timer, or a container image is rebuilt without the ACME client. Nothing logs an error because nothing runs ^[9]. An ACME client writes new files and exits while nginx, HAProxy or Postfix keep serving the old certificate from memory until someone restarts them. The renewal log says success ^[10], and about the files it is correct. A renewal on the origin misses the load balancer, the CDN or the second box in the pool, each holding its own copy ^[11]. Challenges break when a firewall blocks port 80, a DNS-01 API token is rotated, or a CAA record leaves out the CA ^[12]. The same ballot cuts domain validation reuse to 10 days by 2029, so domain control has to be proved again at nearly every renewal ^[7].

The post's check connects the way a browser does ^[14]:

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

Keep `-servername`. Without SNI, a server hosting several sites returns its default certificate, which may be a different one from the certificate you meant to check ^[14]. The post says to run the check on a schedule, from a machine other than the one doing the renewing, against every hostname answering on 443. Its reason is that example.com and www.example.com can serve different certificates, and so can api., mail. and whatever sits behind the CDN ^[15].

Alerting is the better part of the post. A healthy 47-day certificate renewed at a third of its life drops to about 15.7 days before renewal. A 30-day threshold is therefore crossed on every healthy cycle ^[4]. The post says that warning fires constantly and people filter it out ^[16]. Its replacement works back from the renewal point. A first warning at 14 days means renewal should already have happened, and the author settled on further alerts at 7, 3 and 1 days ^[17]. Each threshold says something specific about the renewal job. That is good alert design.

The 14-day figure transfers only if renewal happens with a third of a 47-day lifetime left. Under the 200-day cap, a third left is about 67 days. A renewal that fails at that point stays unseen for about 53 days before a 14-day alert fires ^[5]. I would set the thresholds as fractions of the lifetime the CA actually issued.