Certificate Authority Core Concepts
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...
- Everything you should know about certificates and PKI but are too afraid to ask
- The case for using TLS everywhere
- Online X.509 Certificate Authority
- Certificate Issuance Policies
- Certificate Templates
- Active vs. Passive Revocation
- Other Operational Modes
Online X.509 Certificate Authority
step-ca is an online certificate authority, meaning it runs as a server
on the network and accepts certificate requests.
Provisioners are methods of proving an entity's identity to the CA prior to getting a new certificate. The CA needs proof that an entity that is requesting a new certificate is who they say they are. Once a provisioner authenticates an entity's identity, it then issues the entity a bearer token to submit to the CA, along with a certificate signing request (CSR), to obtain the new certificate.
The details of how a provisioner interacts with an entity (machines or people) and the CA vary by provisioner type. Smallstep supports a number of provisioner types including:
- ACME protocol
- OAuth/OIDC Single Sign-on
- AWS Instance Identity Documents
- Google Cloud Instance Identity Tokens
- Azure Instance Metadata Service
- Kubernetes Service Account Tokens
- SCEP protocol
- JWT for building custom integrations
Active vs. passive revocation
There are two certificate revocation methods: active vs. passive.
Private PKIs like
step-ca uses passive revocation by default.
Passive revocation doesn't use Certificate Revocation List (CRL) and Online Certificate Signing Protocol (OCSP) like the Web PKI you may be familiar with.
To passively revoke a certificate means to block its renewal at the CA. This eliminates the additional network request that occurs when using a web PKI because the certificate just expires by itself. Unlike active revocation, certificates cannot be immedietely revoked. Therefore, certificates should have a shorter lifetime to reduce the value of a key that has been exfiltrated.
With certificate issuance policies administrators can configure what Subjects, SANs and Principals the CA is allowed to sign.
An example of a policy is to only allow (strict) subdomains of
internal.example.com, which would be encoded as
step-ca policy page to learn how certificate issuance policies work and how they can be configured.
People use private CAs for all sorts of things, in many different contexts:
web apps, mobile apps, code signing, cloud VM instances, SSH, IoT devices, etc.
step-ca must be flexible enough to handle a wide variety of flows.
X.509 and SSH certificate templates open up these possibilities. With certificate templates, you can do things like:
- Add custom SANs or extensions to X.509 certificates
- Make longer certificate chains, with multiple intermediate CAs
- Use SSH
- Add conditionals around a certificate's parameters, and fail if they are not met
- Enrich a certificate with data from a webhook
step-ca templates page to learn how to use templates.
Other operational modes
Aside from being an online Certificate Authority,
step-ca has a couple of non-standard modes of operation:
Registration Authority (RA) mode, and offline mode.
Registration Authority (RA) mode
step-ca can operate in Registration Authority (RA) mode.
An RA is a server that acts as an authentication layer for an upstream signing CA.
RA mode lets you separate certificate request authentication (the RA) from certificate signing operations (the CA). This operational mode centralizes key management: a single CA can serve several RAs.
When in RA mode,
step-ca can peer with three kinds of upstream CA:
step-caserver ("StepCAS" mode)
- A Google CloudCAS CA
- A Hashicorp Vault CA
To create an RA-based PKI topology, see our Registration Authority (RA) Mode documentation.
Sometimes it's useful to access a local CA offline, without running the
For this purpose, the
step CLI can be used in offline mode (with the
Offline mode uses the configuration, database, certificates, and keys of an existing
This table shows some of the feature differences between an online
step CLI in offline mode, and the
step certificate subcommand.
Example: Offline Mode
Let's create a certificate without
$ step ca init --name "Local CA" --provisioner admin --dns localhost --address ":443" $ step ca certificate --offline foo.smallstep.com foo.crt foo.key
- Read the Getting Started guide to set up a CA and get your first certificate.