15. Security
Answers to the security questions customers ask most, with links to the details.
This page answers the questions security teams ask most often when they review CertKit. Where a feature has its own page, the answer here is short and links to the full details.
Accounts and access
How do you authenticate users?
Users sign in with an email and password plus optional TOTP multi-factor authentication, or through SAML 2.0 single sign-on on Business plans and above.
Learn more in Authentication →
How does role-based access work?
Account administrators control the whole account, and users only see the certificate collections they’re granted.
Learn more in Access Control & User Roles →
Keys and secrets
How do you secure certificate private keys?
When CertKit generates a private key, it stores the key in its database encrypted with AES-256-GCM. The encryption key is held in a separate secrets vault. Each value is also encrypted with additional authenticated data (AAD) that comes from the record it belongs to. Decryption fails unless that AAD matches exactly, so an encrypted key that has been altered or copied into a different record can’t be decrypted. The same protection covers private CA keys, ACME account keys, and the access keys for each collection’s certificate storage. Backups are encrypted with AES-256.
Each collection that doesn’t use a Keystore also has its own S3-compatible storage, hosted by CertKit, so scripts and tools like Terraform can retrieve certificates. When a certificate is issued, CertKit writes a separate copy of the certificate, private key, and PFX there. That copy is kept apart from the database and protected by the storage service’s own encryption at rest instead of the AAD scheme above. It can only be read with that collection’s read-only access keys, which are shown on the Certificate Explorer page.
If you’d rather CertKit never hold your private keys at all, use the Keystore, which is available on Enterprise plans.
How do you store deployment credentials?
Some deployments need a secret, like an appliance password or a cloud API key. You enter these as variables on the deployment configuration. CertKit encrypts them at rest with the same AES-256-GCM scheme it uses for private keys. The agent receives them with its configuration, keeps them only in memory, and never writes them to disk. It passes them to your script over standard input instead of on the command line, so they don’t show up in process listings. Keep them out of your script’s own command-line arguments and output, because the agent logs what your script prints.
Agents and your network
How is communication between the agent and CertKit secured?
The agent connects out to app.certkit.io over HTTPS. When you install it, the agent generates its own Ed25519 key pair, and the private half never leaves that machine. Every request the agent sends is signed over the method, path, host, timestamp, and a hash of the request body. CertKit uses that signature to confirm the request came from a registered agent, wasn’t changed in transit, and isn’t stale. The Keystore signs its requests the same way.
A new agent can’t deploy anything until someone with access to its collection approves it. The agent’s source code is available at github.com/certkit-io/certkit-agent, and the Windows installer is signed. See Agents.
Can CertKit run commands on my servers?
Deployment configurations can include a script that the agent runs after it installs a certificate, and anyone with access to the collection can edit those scripts. Once your deployments are working, you can lock the agent from the dashboard or by running certkit-agent lock on the host. A locked agent ignores new or changed configurations and scripts from CertKit, while certificate renewals and agent updates still come through. It can only be unlocked on the host itself.
Do I need to open inbound ports?
No. The only connections that leave your network are outbound HTTPS from the agent and Keystore to app.certkit.io, and the agent can go through an HTTP proxy. CertKit has no VPN, SSH, or other access into your network. If you use a Keystore, it listens on port 443 so your agents can fetch keys from it, and only your agents need to reach that port.
CertKit checks your public sites from three published IP addresses, the same way a browser connects to them. Internal sites are checked by your agents from inside your network.
Do you need my DNS API keys?
No. To prove you control a domain, you add one CNAME record for each domain name you validate that points _acme-challenge.<name> at CertKit’s validation DNS. You only do this once. The CNAME delegates that one validation record and nothing else, so CertKit can’t change any other record in your zone. See Certificates.
Audits and compliance
Can you help me complete my security audit?
On Enterprise plans, yes. We’ll fill out your security questionnaire and join a security review call with your team. On other plans, we’ll send you our security documentation, which describes how CertKit is built and how we protect your data, for your own review. Our Data Processing Agreement, including the list of subprocessors, is public. Contact us to request documentation.
Are you SOC 2 or ISO 27001 certified?
Not yet. Our security practices are modeled on the NIST Cybersecurity Framework, and we plan to pursue SOC 2 in Q2 2027. Right now, we’re focusing on completing the roadmap and integrating with the software and appliances you use.