The certificate lifecycle — and the quiet ways renewal automation breaks
A TLS certificate is not a one-time purchase — it is a recurring obligation with a hard deadline, and the way it gets renewed matters as much as the certificate itself.
Issuance: proving you control the domain
A public certificate authority (CA) won't sign a certificate for a domain just because you ask — it has to verify you actually control it, usually via one of a few standard challenges: adding a specific DNS TXT record, serving a specific file at a well-known HTTP path, or (less commonly now) receiving an email at an administrative address. Automated issuance protocols like ACME (the protocol Let's Encrypt popularized) handle this challenge-response automatically, which is what makes frequent renewal practical at all — doing it by hand every 90 days for more than a handful of domains simply doesn't scale.
Why renewal automation fails without anyone noticing
The failure modes are almost never "the CA rejected the renewal" — they're operational: a cron job on a server that got rebuilt without the renewal script; a DNS-challenge automation that broke when DNS provider credentials rotated; a certificate that renews successfully on disk but never gets picked up because the web server or load balancer wasn't reloaded; a multi-server setup where the renewal ran on one node and the certificate never made it to the other three behind the load balancer.
Every one of these produces the exact same symptom from the outside: a certificate that looks perfectly fine right after renewal, and then quietly ages toward expiry with nobody automated actually watching it, because the assumption was "renewal is automated, so it's handled."
What actually catches this
The fix isn't more trust in the automation — it's an independent, external check that doesn't depend on whatever might be broken internally. Something that connects to your domain the same way a real visitor would, on a schedule, from outside your own infrastructure, and tells you the moment the *actual served certificate* — not the one sitting in a renewal log somewhere — starts running out of runway. That's a fundamentally different failure surface than "did the renewal script exit 0," and it's the one that actually correlates with whether your visitors are about to see a browser warning.