This document defines and describes certificate authority core concepts that are integral to the design
and practical usage of
Readers who are not yet familiar with public key infrastructure (PKI) and certificate management may want to check out...
Certificate Authorities (CAs) tend to be either "online" or "offline" mode.
When referring to Certificate Authorities (CAs), offline generally means
air-gapped or network isolated. However, the term offline has a different
meaning in the context of
step-ca is online (using the
step-ca server) it is responding to network requests. But
also operate "offline", without the
step-ca server, by accessing the signing
keys locally. We call this static, non-daemonized operation offline mode. Any
further use of the term offline in these docs will refer to offline mode in
the context of
step-ca (local access only).
Our tools support three modes of generating and operating a Certificate Authority (CA):
step casubcommand (docs here).
step casubcommand with
step certificatesubcommand (docs here).
It's not always practical or desirable to run an online CA.
Smallstep provides the means to create certificates without
step-cli offline mode leverages the CA's configuration, which must be available locally, to issue certificates.
$ step ca init --name "Local CA" --provisioner admin --dns localhost --address ":443" $ step ca certificate --offline foo.smallstep.com foo.crt foo.key
Sometimes you may wish to run a Registration Authority (RA). An RA acts as a front-end to a CA, authenticating certificate requests from its clients before passing them along to an upstream Certificate Authority that will issue the certificates. This operational mode centralizes and simplifies CA key management, because a single backing CA can serve several RAs.
In RA mode,
step-ca currently supports two backing CA types: Another
step-ca instance ("StepCAS"), or Google CloudCAS.
See the Registration Authority (RA) Mode section of our Configuration Guide for more on RA mode.
The certificate signing API exposed by
step-ca requires mutual
authentication. The CA authenticates to the client using a certificate (which
the client verifies using the root certificate created during CA initialization).
But the client must also authenticate to the CA. Again, this
presents a challenge: the client obviously can't use a certificate for
authentication because it doesn't have one yet.
To verify the legitimacy of certificate signing requests, we need some entity that the CA trusts to measure and attest to the identity of our workloads. In the step certificates architecture this entity is called a provisioner, because it helps to provision certificates.
In general, once a provisioner authenticates a workload's identity it issues the workload a bearer token to submit to the CA, along with a certificate signing request (CSR), to obtain a certificate. The bearer token authenticates the workload and authorizes the certificate request.
The details of how a provisioner interacts with a workload (or device or person) and the CA vary by provisioner type. Smallstep supports a number of provisioner types including:
On the public internet, sometimes HTTPS certificates need to be revoked before they expire. Over the years, there have been several methods for actively revoking HTTPS certificates. Any approach to solving this problem adds complexity to the PKI—usually in the form of additional network requests. For example, a web browser might need to fetch a Certificate Revocation List (CRL) from a URL embedded in an HTTPS certificate so it can make sure the certificate, which would otherwise be valid, has not been actively revoked by a trusted authority.
When designing a private PKI, you can make things a lot simpler and more decentralized. If you make certificate lifetimes short enough, you can passively revoke a certificate by letting it expire and making sure the Certificate Authority knows to reject any attempts to renew it.