Abstract
You’ve deployed certificate automation with Certbot and your artisanally-crafted scripts, but you still got paged at 2am for an expired cert. You’ve discovered the difference between issuance automation and certificate automation.
Certificate automation is more than a cron job
Operational certificate lifecycle is a loop. It repeats every renewal, hostname change, or emergency replacement:
issue → deploy → verify
Issue is proving control of the domain and getting the CA to sign the keypair/CSR. This is the “ACME did its thing” moment. If you want the mechanics, I wrote up how ACME automates issuance.
Deploy is the hard part. It is getting the new certificate, in the correct format, to every place that serves traffic. Web servers, mail servers, load balancers, ingress controllers, app servers, sidecars, and that one legacy box you hate touching.
Verify is proving that the endpoint is using the certificate you think it is, for the names you intended. Not “the file exists,” but “real clients see the new cert.” Verification means running a real TLS handshake against the public hostname and checking expiry, SANs, and chain. Almost nobody does this part.
Then the loop starts again because certificates expire, soon every 47 days.
Issuance is easy to automate
Lots of teams are really good at automating issuance. These tools solve getting a valid cert, not getting it live everywhere, or verifying that it works.
You can install Certbot. You can wire up DNS plugins. You can schedule renewals.
But that’s it. The CA says “ok.” The client exits 0. A file got written. It’s up to you to get it where it needs to go. And none of that proves it worked end-to-end.
From issuance automation to certificate automation
You don’t need “more Certbot.” Your servers shouldn’t need to know how ACME works. You need to make deployment reliable, and monitor that it worked.
1. Deployment should be boring A renewed cert that isn’t deployed everywhere is just a file. Build a repeatable rollout path to the places that terminate TLS (CDN, load balancer, ingress, app servers), and standardize the bundle format so you don’t lose hours to chain weirdness.
2. Verification is the success signal Stop celebrating “renewal succeeded.” The loop only completes when an external check proves the public endpoint is serving the expected cert and chain. If you can’t automatically verify it, you didn’t really automate it.
3. Don’t pass out DNS keys If DNS is in the loop, reduce the blast radius. Prefer patterns like DNS delegation, keep credentials scoped and centralized, and keep the TXT record lifecycle boring (create, validate, clean up).
Do those three things and shrinking certificate lifetimes are no big deal. The loop just runs more often, and nobody gets paged for it.
That’s the whole idea behind CertKit, it’s the missing layer that turns “we can renew a cert” into “we can reliably deploy and verify certificates everywhere they’re used.”
Comments