CertKit
Abstract
You were tired of renewing all those certificates, and Certbot looked so easy. Now you have scripts thousands of lines long filled with command line incantations you have to Google every time you open it. The script is running on all the critical servers. And some of the printers.
If someone looks at it the wrong way, a certificate expires.
“It’s just Certbot - How Hard Could It Be?”
47 lines of bash. Beautiful. Clean. Renewed the web cert, sent a Slack message. It was perfect for three whole months.
Then marketing needed wildcards.
Then security demanded monitoring. Not just “is it valid” but “what’s the cipher strength” and “who touched it last” and fifteen other things nobody looks at.
The CEO wanted an email if anything is going to expire soon.
Now it’s thousands of lines long. Running as root. Via cron jobs that fire at different times because “we don’t want to hammer Let’s Encrypt.”
Your script needs OpenSSL 1.1.1 exactly. Bob’s AWS credentials from line 1,847. That Jenkins job nobody remembers. Touch any of it and production goes down.
What Proper Certificate Management Could Do
If only you could do it over again. You could build a proper certificate management system. It would do more than just renew the certificates. It would do useful and professional things like:
Certificate Discovery. Scan your domains and find the certificates you forgot existed–or never knew about. Your script manages a hardcoded list in a text file. Maybe a spreadsheet if you’re fancy.
Certificate Inventory. Proper systems would know every certificate in your infrastructure. Yours? It knows about the ones you told it about. That Jenkins server from 2019? The VPN appliance? That staging environment on Bob’s old laptop? Nobody’s tracking those.
Certificate Transformation. Need to convert PEM to PFX for that Windows server? Your script shells out to OpenSSL with parameters you copied from Stack Overflow. Works great until someone needs PKCS#12 with specific cipher suites.
Certificate Expiry Monitoring. The old script just checks the certificate in the filesystem–not what’s actually running. If something failed to update, you’ll know when users start complaining.
Secure Distribution. Your script has root SSH access to everything. Security loves that. Or it’s copying private keys through a shared folder. Or that one team that uses Git for cert distribution.
The Features You’ll Never Get Around to Building
You tell yourself you’ll add these features “next quarter.” You won’t.
Role-based access control. Right now everyone who needs to manage certs has root access to the script server. That’s fine, right?
Audit trails. Who renewed what when? Who knows. The script doesn’t log that. Check the bash history if it hasn’t rolled over.
Alerting that works. Email alerts go to a distribution list that nobody reads. Slack integration? That’s on the roadmap. Has been for two years.
Backup and recovery. The script is in Git. Probably. Someone might have committed the latest version. The certificates themselves? Hope you have backups.
Multi-region support. Each region has its own slightly different version of the script. They diverged years ago. Nobody knows what the differences are anymore.
It’s Time to Get Help
Look, your homegrown system meant well. You learned what breaks. What matters. What you actually need from certificate automation.
Now let someone else worry about all the ACME protocol changes on the weekend, distribution, monitoring, and other tasks. Get back to the work that you should have been doing. That’s what we’re building with CertKit.
Simple, Centralized, Transparent TLS Certificate Management.
Not a bash script held together with hope and regular expressions.
CertKit is certificate management for companies tired of maintaining their own broken systems. Currently in beta, accepting teams who’ve learned this lesson the hard way.