We’ve been quietly solving a problem that most teams haven’t hit yet, but they’re about to.
SSL certificate lifetimes are dropping to 47 days. If you’re managing certificates manually today, you have a very short window before that becomes a real operational problem.
We know, because it happened to us first.
Our Annual Cert Renewal Checklist
For years, managing SSL certificates at TrackJS was a once-a-year chore. Buy a new *.trackjs.com wildcard certificate, pull up the checklist, and spend an afternoon pushing it to every server and service that needed it. Annoying, but manageable. Put it on the calendar, knock it out to some tunes, and move on.
Then a bunch of folks in a committee that we had never heard of decided that annual certificates were too risky and started driving lifetimes down. At that cadence, “put it on the calendar” stops being a chore and starts being someone’s entire job.
So we went looking for automation. The obvious answer was certbot, the go-to open source ACME client, but it didn’t work for us.
Certbot makes some very reasonable assumptions about how you run things. Specifically: one certificate, one server, publicly accessible, running Linux. That’s a perfectly sensible setup for a lot of people. It’s just not how we do anything.
We use wildcards and pass them around to a lot of different services. Most of our servers aren’t publicly accessible. We run Windows hosts. Certbot wasn’t going to get us where we needed to go without a lot of painful workarounds, and workarounds in certificate management are exactly the kind of thing that fails silently at 2am.
So We Built CertKit
We built an internal tool, codenamed CertKit, to solve this for ourselves. The design was simple: a centralized ACME client that renews certificates in one place and distributes them to everything that needs them: Windows servers, Linux hosts, whatever you’ve got.
And because we’re a monitoring company, we couldn’t help ourselves. From day one, CertKit didn’t just renew certificates. It monitored them. Not just watching expiration dates, but verifying that the certificate actually running on each host matches the thumbprint we expect. If our automation fails silently and an old cert stays in place, CertKit tells us immediately. That’s the kind of thing that saves you from a very bad day.
It worked better than expected, so we started adding the things real infrastructure actually needs:
- Better Windows support
- Java Keystore integration
- Local key storage
- Certificate transparency log monitoring
- More integrations, more platforms
Turns out, other people had the same problems we did. We started hearing from folks who wanted access, so we opened a beta.
CertKit is Now Open
We’ve been running that beta for the past year, and today I’m pleased to say that CertKit is officially out of beta and open for business.
If you need simple, affordable, fully automated SSL certificate management, the kind that works on your actual infrastructure, not just the theoretical perfect-Linux-server infrastructure, CertKit is ready for you.
And as a thank-you to everyone who helped us get here: subscribe before May 31 and get 40% off forever as a founding customer.
Ok, that’s enough, we’ll get back to JavaScript now.
