The Smallstep Platform is powered by a number of components that can be combined to deliver automated certificate management for a broad set of use cases and implementations.

A certificate is a sort of credential. Concretely, a certificate is a data structure that contains a name, public key, validity period (a.k.a., lifetime), and additional metadata. Certificates are signed by a trusted certificate authority (CA) and issued to endpoints. A relying party validates a certificate and extracts the subject name to authenticate the identity of an endpoint.

An Endpoint is an entity (person, device, workload) that is issued a certificate. Certificate Manager attempts to group certificate renewals for an Endpoint for alerting, audit, and billing purposes.

Certificate Manager can be configured to alert you when an Endpoint’s last certificate is approaching expiry and has not been renewed.

The Certificate Manager dashboard provides an Endpoint detail view that makes it easy for administrators to view the historical certificate lineage for an Endpoint. This aggregated view simplifies operations, auditing, reporting, and compliance inquiries.

Certificate Manager billing is also metered on Endpoint-months.

Billing per-certificate would penalize deployments that use short-lived certificates and automated renewal. Endpoint billing is designed to encourage this best practice.

Two Endpoint examples:

Endpoint grouping is automatic and intuitive for most use cases:

For billing purposes, there is a limit of three active certificates per Endpoint. Each active certificate above three is billed as an additional Endpoint. To avoid being charged for multiple Endpoints you can revoke unused certificates after they’ve been renewed.

If you’d like to opt-in to certificate-based billing, inquire about high-volume fixed pricing, or have any other questions about Endpoint-based billing for your use case please contact us.

Authorities are the foundation of the Smallstep Platform. They are trusted services that provide core certificate signing and management functions (issue, sign, renew, and revoke certificates), and can run at any level of the PKI trust chain. Authorities are highly configurable, and multiple authorities can be used together to meet complex requirements.

There are different types of authorities supported:

An issuing authority is an online certificate authority that authenticates and authorizes certificate requests and issues certificates. Issuing authorities sign certificates themselves. To do so, they are provisioned with a special CA certificate and private key.

There are two types of issuing authority:

If an issuing authority's private key is compromised, it can be used to maliciously issue certificates that will be trusted by the rest of your infrastructure. To protect these keys, step-ca integrates with hardware and software key managers, including PKCS#11 Hardware Security Modules (HSMs), YubiKeys, and cloud key management systems (KMSs) from AWS, GCP, and Azure. For hosted authorities, smallstep secures these keys for you in GCP's CloudKMS, with options for software or FIPS 140-2 Level 3 hardware protection levels.

At the bottom of the PKI trust chain is the root authority. Typically, a Root CA is only invoked to sign intermediate CA certificates. This indirection allows for redundant topologies and facilitates migrations. It also means root CA private keys can be managed, stored, and accessed with more care.

For the most security-sensitive use cases root signing keys can even be kept offline in a physically secure environment. A root CA is directly trusted by relying parties. The root CA's certificate must be deployed to VMs, devices, and containers, then software and systems must be configured to trust it.

Automated certificate management requires an online CA with an API that's capable of authenticating certificate signing requests (CSRs) and issuing certificates. An intermediate CA (also called a subordinate CA) is an issuing CA which recursively chains up to the root CA. It is used to sign and issue certificates for devices, people, workloads, or whatever else you need to identify. It also allows you to keep your root signing keys offline, which improves security.

For most scenarios, this is a nuance you won't have to worry about. By default, Certificate Manager will create a non-issuing root CA and a separate issuing authority for you automatically. For advanced scenarios, you can use your own offline root CA, provision multiple issuing authorities from a single root, configure multiple levels of intermediates, and revoke and re-issue intermediate authority certificates as necessary.

A registration authority is an online service that accepts and authenticates certificate requests. But, instead of issuing certificates itself, a registration authority passes authentic requests to an issuing authority (an Intermediate CA or Root CA) to sign and catalog. Registration authorities support all Provisioner types and are an optional component. They deliver most of the benefits of a linked issuing authority with less operational complexity since there's no signing key to manage.
Registration Authorities are also useful for connecting remote sites to a central set of signing authorities.

A validation authority distributes certificate revocation status. Validation authorities implement two open standards to support active revocation:

Provisioners verify the legitimacy of certificate signing requests and attest to the identity of the requesting service or human. Provisioners are used to bootstrap new entities into the PKI, and make it easy to automate certificate management where possible, and support semi-automated / self-serve workflows where required.

Certificate lifetimes, access control policies, renewal, templates, and many other options are configurable per-provisioner. Since an issuing authority can have multiple provisioners, you implement complex authentication and authorization policies and issue different kinds of certificates from one issuing authority.

Each Provisioner addresses a particular environment, enabling different use cases. A few examples include:

Inventories are catalogs or lists of entities like hosts, services, locations, or people. Inventories provide a secure mapping between details that are available from the credential used to request a certificate and additional metadata that needs to be bound in the issued certificate. You can use Inventories along with other Smallstep Platform components to:

Templates give you granular control over certificate details and can be used to customize x.509 or SSH certificates for any use case. By default, Certificate Manager is tuned to issue short-lived certificates for use with TLS. Templates let you customize every detail of a certificate, down to the OID, to support any use case. With Templates, you can add custom SANs or extensions to:

Concretely, a template is a JSON representation of a certificate that's materialized using Go's text/template module and sprig functions. They look like this:

Context from certificate requests and authentication credentials are made available as template variables, so you can adjust certificate details based on who's requesting the certificate.

Events power alerting for certificate lifecycle activities. Used to help administrators operate the Smallstep Platform, Events can be generated and surfaced via standard mechanisms.