Certificate Authority Core Concepts

This document defines and describes certificate authority core concepts that are integral to the design and practical usage of step-ca.

Readers who are not yet familiar with public key infrastructure (PKI) and certificate management may want to check out...

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:

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 immediately 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 *.internal.example.com.

Visit the 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. So 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:

Visit the step-ca templates page to learn how to use templates.

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.

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:

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 step-ca server. For this purpose, the step CLI can be used in offline mode (with the --offline flag). Offline mode uses the configuration, database, certificates, and keys of an existing step-ca installation.

This table shows some of the feature differences between an online step-ca server, step CLI in offline mode, and the step certificate subcommand.

Let's create a certificate without step-ca: