Documentation
Certificate authority.
A certificate authority here is a signing key with a certificate and a published revocation position. The key never leaves the hardware module, which means the thing most certificate authority compromises actually are, a private key copied off a machine, has no mechanism available to it.
What we ship, and what we do not
We ship a real CA: root and intermediate hierarchy, certificate signing request signing, issuance, revocation, and public CRL and OCSP distribution are all deployed and reachable.
We ship no enrollment ecosystem. There is no ACME, no SCEP, no EST, no auto-enrollment and no renewal agent. Integration is your pipeline calling the API, plus the console. Stated the way it should be: renewal automation is your pipeline's job. Signing, revocation, and revocation truth are ours.
Building the hierarchy
A CA is created against a key you already hold, and it is created as one of two kinds. A root signs its own certificate and sits at the top of your chain. An intermediate is signed by a CA above it and is what should actually issue your end certificates.
Use an intermediate for day to day issuance even when a root would work. The root then signs almost nothing, which is what lets it be the long-lived anchor you never have to replace. Replacing a root means touching every device and every verifier that trusts it.
The underlying key must be a signing key, and its algorithm is fixed at key creation, so the algorithm decision for a root is made before the CA exists rather than after. See Keys.
Issuing certificates
Issuance takes a certificate signing request and a CA to sign it with, and returns the certificate. Each issued certificate is retained against its CA, so you can list what a given authority has issued and fetch any certificate by serial. That inventory is what makes revocation meaningful later: you cannot revoke what you cannot enumerate.
A CSR can come from anywhere. If the subject key lives here, ask the key for a CSR directly, supplying the subject, and it produces one signed by that key. This is the common path for device identity and internal service certificates: key created here, request produced here, certificate signed here, private key never anywhere.
Certificates signed elsewhere
You can upload a certificate that was signed by some other authority. This matters in two situations that are otherwise awkward: when your root is offline or at another provider and only the intermediate lives here, and when you are migrating an existing hierarchy in stages rather than reissuing everything at once.
Revocation
Revoking takes the certificate serial and a reason. The reason is not decoration: it is published in the revocation list and it is what a relying party uses to distinguish a routine replacement from a compromise.
| Reason | Use it when |
|---|---|
| keyCompromise | The private key is believed to be in someone else's hands. |
| affiliationChanged | The subject's details changed enough that the certificate no longer describes it. |
| superseded | A replacement has been issued. |
| cessationOfOperation | The subject is retired. |
| unspecified | No reason given. Valid, and less useful to whoever reads the list later. |
Each CA publishes a certificate revocation list at a public endpoint, and OCSP responds for the same population. Both are reachable without authentication, because a relying party checking whether your certificate is still good is by definition not your customer and holds no credential of yours.
Private trust, not public trust
This is a private trust CA and we say so directly rather than leaving it ambiguous. Firmware signing, device identity, internal service certificates and mutual TLS are fully served: those verifiers trust the root you tell them to trust, which is yours.
Anything that requires a root already present in a browser or operating system trust store is deliberately not provided. If you need a certificate the public internet trusts without configuration, you need a public CA, and no amount of configuration here produces one.
The key under the CA
One consequence deserves its own heading, because it is the mistake with the longest tail. Scheduling deletion of a CA's key eventually destroys the only thing that can sign that authority's revocation list. Certificates already issued do not stop working when that happens; what stops is your ability to say that any of them is no longer valid.
Retire a hierarchy in the right order: issue replacements from the new authority, distribute them, revoke what the old authority signed, let the final revocation list publish, and only then consider the old key. The thirty day pending window on deletion gives you room to notice, and it is not a substitute for doing it in that order.