CertKit
Abstract
SSL Certificates have always been a pain in the butt.
From the magical OpenSSL incantations to generate a CSR to the various formats that each webserver requires. Remembering what hardware needs which certificates. Managing scheduled renewals and runbooks for which file goes where.
Screw anything up and your site is “Not Secure”.
And now Apple wants us to do it every 47 days.
Remember when we had HTTP-only websites? Or when certificates lasted three years? Then one? At this rate, by 2030 we’ll be renewing certs for every request.
Our Breaking Point
Last year, I watched a perfectly competent DevOps team spend six hours debugging why their automated certificate renewal stopped working. The culprit? CertBot updated, their ancient Ubuntu install didn’t, and the ACME protocol had “opinions” about TLS versions.
Six. Hours.
That’s when we decided we needed to build something better. Not another command-line tool that works–until it doesn’t. Not an enterprise PKI suite that requires a PhD to operate. Just something that handles certificates and gets out of the way.
We Tried Everything Else First
Trust me, we didn’t want to build another tool. We tried them all.
CertBot? Works great. For one cert on one server.
Need wildcards across a web farm? Now you’re writing special routing rules. Opening port 80. Praying the validation server stays up.
Got the cert? Cool. Now distribute it to 50 other servers. Hope you like rsync. The official CertBot solution for multiple servers is literally “figure it out yourself.”
I’ve seen it all. Dropbox folders full of private keys. Git repos anyone can clone. That one team using Ansible until they accidentally pushed to production instead of staging.
Whoops.
Cert Manager? Fantastic if your entire infrastructure lives in Kubernetes and you enjoy writing YAML manifestos. For the rest of us living in the real world with legacy systems, Windows servers, and that one critical app running under Bob’s desk? Not so much.
Commercial solutions? DigiCert wants to sell you an “enterprise certificate lifecycle management platform” starting at just $call-for-pricing. What a deal!
So we built CertKit. Here’s what makes it different.
Transparency That Actually Helps
Every certificate management tool claims to offer “monitoring.” What they mean is an email when something expires. Maybe a dashboard if you’re lucky.
CertKit shows you everything. Which certificates are where. When they were last checked. What’s about to expire. What already expired but nobody noticed because it’s on that staging server everyone forgot about. Real monitoring means knowing about problems before they become problems.
And alerts? They go where you actually look. Email, Slack, Teams (if we have to).
A GUI That Doesn’t Suck
I know, I know. Real sysadmins prefer their certificate management artisanal. Hand-crafted bash scripts. Locally-sourced cron jobs. Small-batch OpenSSL commands passed down through generations.
But you know what? Sometimes I just want to click a button and add a certificate without writing a config file. Sometimes the new junior admin needs to provision a cert without learning the entire ACME RFC.
CertKit has a dashboard that actually makes sense. Add certificates, remove them, see what’s happening. No need to SSH into three different boxes to figure out why something’s broken.
The SSL Certificates You Forgot About
That Jenkins server from 2018. The VPN appliance. The marketing WordPress site. CertKit discovers certificates across your infrastructure automatically. No more surprise expirations from forgotten systems.
It Just Works™
This is the part where I’m supposed to say “robust enterprise-grade reliability” or some nonsense you’d find in a whitepaper.
Here’s what I mean: CertKit doesn’t break when your Linux distro updates. Or when Let’s Encrypt changes their API. It handles the edge cases because someone’s actually paying attention.
Unlike the bash script Terry wrote in 2019 before he left for a “better opportunity”, someone’s maintaining it. We’re fixing it before you even know it’s broken.
Centralized Without the Single Point of Failure
“But what if your service goes down?”
Fair question. But CertKit isn’t in the critical path. We push certificates to your infrastructure. If we go down, your sites keep running with their current certs. You’ve got time to fix things.
Compare that to distributed setups where every server runs its own renewal process. One fails, you might not notice until customers complain.
DNS Without the Security Nightmare
Want wildcard certificates? Every tool makes you hand over your DNS API keys. Full access to your entire domain. What could go wrong?
CertKit proxies DNS validation. We only touch TXT records for ACME challenges. Can’t accidentally delete your MX records. Can’t redirect your domain to a crypto scam–even if it’s going to the moon. Just the minimum access needed for certificate validation.
The Future’s Getting Worse
How long can digital certificates be valid? If you ask Google, not very long. Right now you can get a 1 year certificate. Next March, you’ll only get 200 days.
March 2027? 100 days.
We’re on the way to 47 days.
Some people are seriously discussing daily certificate rotation.
Daily.
Your full-time job is renewing certificates now.
Manual processes won’t cut it. Half-baked automation will break constantly. You need something built for this insane future we’re heading toward.
That’s why we built CertKit. Not because we love certificates. Because we’re tired of them.
Let Us Worry About SSL Certificates
Look, I’m not going to pretend CertKit’s perfect. Nothing is. But it’s better than what you’re doing now.
Stop maintaining certificate infrastructure. Stop debugging renewal failures. Stop explaining to management why the certificate expired.
Just let CertKit handle it. Your future self will thank you.
CertKit is TLS certificate management software for people who have better things to do. Currently in beta, accepting users who are tired of SSL certificate hell.