Abstract
Most security vendors hide their documentation behind a login. Some don’t write it at all. You get a sales page, a demo, and a request to install an agent on your servers, and you’re expected to trust that the thing does what the marketing says.
That’s backwards.
So we wrote the docs, and we put all of them at certkit.io/docs. No login, no account gate, no “contact us for details.” You can read every page before you create an account.
You should be able to read it before you run it
The CertKit Agent runs commands on your infrastructure. That’s not a side effect, it’s the design. You configure a restart command, the agent runs it after a renewal, and your service picks up the new certificate without anyone logging in at 2am. Convenient. Also exactly the kind of thing you should be suspicious of when a vendor asks you to install it.
The agent source is readable for that reason. The docs exist for the same one. Before any of this touches a production box, you can read how agents install and update themselves, how the keystore keeps private keys on your own hardware instead of ours, and how agent locking freezes the configuration so a compromise of CertKit can’t turn into command execution on your servers. No black box. If you’re putting a tool in the path of your certificates, you get to know what it does first.
What’s actually in there
The docs follow the certificate lifecycle, start to finish.
Discovery comes first, because you can’t manage what you can’t see. There are pages on scanning Certificate Transparency logs for certificates issued against your domains, and on agent auto-discovery that finds the certificates already installed on your servers. Then issuance: how ACME issuers work, how ARI drives automated renewals, and, the part most vendor docs skip entirely, what happens when issuance fails and how to read the error. The happy path is easy to document. The failure modes are the ones you actually need at 9pm.
Deployment is the hard middle that scripts never solved, so it gets real coverage: deployment configs, built-in templates for common software, custom templates for everything else, and a Windows-specific guide. The operational layer is documented too, the parts an IT team has to answer for in an audit: access control and collection scoping, SAML SSO and MFA, managed accounts for MSPs running multiple tenants, and the activity log that records who did what.
It goes deep where it counts. There’s a page on signature and key algorithms and one on post-quantum cryptography, because the cert estate is going to churn again and you should know what we support before it does.
Docs are a commitment, not a launch
I’m not going to pretend this is finished. Documentation is a maintenance job, not a one-time ship. It grows with the product, it goes stale if you ignore it, and the only way it stays useful is if we keep editing it as things change. We will. When a feature ships, the docs ship with it.
If you want to see what’s coming, the roadmap is public too.
CertKit handles the full certificate lifecycle, and tells you exactly how it does it.
Comments