A customer opens your client's website and Chrome shows the warning everyone recognises: Your connection is not private.
They take a screenshot and send it to your client. Your client sends it to you. A certificate renewal that should have been routine is now public, embarrassing and urgent.
Once that screenshot reaches the client, a routine renewal failure becomes an urgent incident. Check the certificate customers actually receive from outside the network. You do not need access to the website or its renewal system, and you do not need to own the repair.
Since 15 March 2026 no public certificate authority will issue you a TLS certificate valid for more than 200 days. In March 2027 the cap drops to 100 days, and in March 2029 to 47. The last of the old 398-day certificates run out in April 2027, and after that everybody is on the short schedule whether they planned for it or not.
The CA/Browser Forum voted this through in April 2025 (ballot SC-081v3), with Apple, Google, Microsoft and Mozilla all in favour. The reasoning is sound. Revocation has never worked well in browsers, so the practical way to limit the damage from a stolen or mis-issued certificate is to make it expire sooner.
The part I care about is what it does to failure. 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.
Five ways automated renewal fails quietly
The job stopped running. The server was rebuilt and the cron entry or systemd timer wasn't carried over. The container image was rebuilt without the ACME client. Nothing logs an error, because nothing runs.
The certificate renewed and the server never reloaded. The ACME client wrote new files and exited. nginx, HAProxy or Postfix are still serving the old certificate from memory and will keep doing so until somebody restarts them. The renewal log says success. There is a longer write-up of this one, with the other places an old certificate hides, in renewed the certificate, old one still served.
It renewed on the wrong machine. You renewed on the origin. Visitors talk to a load balancer, a CDN, or the second box in the pool, and each of those has its own copy.
The challenge started failing. A firewall rule now blocks port 80. The DNS API token used for DNS-01 was rotated. Someone added a CAA record that doesn't include your CA. A CAA mistake used to bite once a year. At 47 days it bites eight times a year.
The validation expired. The same ballot shortens how long a CA may reuse a domain validation, down to 10 days by 2029. Setups that leaned on a long-lived validation will have to prove control again at nearly every renewal.
What these have in common is that the certificate on disk, the renewal log, or both look fine. The only place the problem is visible is from outside, in the certificate visitors are actually handed.
The one check that catches all five
Connect the way a browser does and read what comes back:
echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null \
| openssl x509 -noout -issuer -serial -enddate
Keep the -servername. Without SNI, a server that hosts several sites hands you its default certificate, which may not be the one you think you're checking.
Run that on a schedule, from a machine that is not the one doing the renewing, for every hostname that answers on 443. example.com and www.example.com can serve different certificates. So can api., mail. and whatever sits behind your CDN. If a disk fills up on the box that renews, you don't want the warning to live on the same disk.
If you want to spot-check a hostname without a terminal, this SSL certificate checker makes the same connection and shows the expiry, days left, issuer, serial and fingerprint.
How early to warn
The classic advice is a 30-day warning. On a 47-day certificate that renews at around day 30, a 30-day warning is true for most of the certificate's life. It fires constantly, so people filter it, and then it is worthless on the one day it matters.
Work backwards from the renewal point instead. If your client renews with a third of the lifetime left, a healthy 47-day certificate never drops below about 15 days remaining. A first warning at 14 days then means "renewal should have happened by now and didn't". After that you want reminders that get harder to ignore, and a final one that means a person has to act today. I settled on 14, 7, 3 and 1.
Two more rules kept the noise down for me, the same way they did for DNS records in the seven false alarms post. A new serial with a later expiry is a renewal, so it goes on a timeline and nobody gets an email. A new serial with an earlier expiry does get an email, because that usually means someone installed the wrong file.
Where this fits
Certificate expiry is one of four things I watch per domain in DNS Notify, next to DNS records, nameservers and the registration. Its SSL certificate expiry monitoring is deliberately narrow. It reads the leaf certificate served on port 443 and tracks the dates, issuer, key and fingerprint. It does not grade your TLS configuration or validate the chain, because other tools already do that well.
Certificates also fail for DNS reasons. A CAA record that blocks your CA and a broken _acme-challenge CNAME are both DNS changes, which is part of why the two live in one product. I covered the email equivalent of this, records that break without anyone noticing, in the four records that break mail while your site stays up.
If you do one thing this quarter, list every hostname you serve over HTTPS and check that each one is renewed by a machine, reloaded by a hook, and read from outside by something that will tell you when the first two stop working.
Top comments (0)