step-ca is an open-source online certificate authority that issues X.509 and SSH certificates and runs as an ACME server, built for DevOps teams that need automated certificate management without a commercial PKI contract.

What it is

step-ca is an online certificate authority for secure, automated certificate management, written in Go and maintained by Smallstep Labs. It is the server counterpart to the step command-line tool, and the two are designed to be used together when working with certificates and keys. It lives in the public key infrastructure (PKI) ecosystem, alongside and in place of the certificate authority services that teams would otherwise assemble themselves or buy: it is the thing that signs, renews, and distributes certificates rather than a client that merely consumes them.

The concrete problem it solves is that standing up a PKI is out of reach for many small teams. Certificate issuance and renewal is manual, short-lived certificates are impractical without automation, and SSH access tends to rely on static keys copied between hosts. step-ca replaces that manual issuance and key distribution with an automated authority that issues HTTPS server and client certificates, TLS certificates for DevOps workloads, and SSH certificates for both people and hosts.

Key capabilities

• Issues HTTPS server and client certificates that work in browsers, following RFC 5280 and CA/Browser Forum baseline requirements.
• Runs as an ACME server supporting all popular ACME challenge types, so existing ACME clients can enrol against it.
• Issues SSH certificates for people in exchange for single sign-on identity tokens, and for hosts in exchange for cloud instance identity documents.
• Issues TLS certificates for VMs, containers, APIs, database connections, and Kubernetes pods.
• Supports short-lived certificates with automated enrolment, renewal, and passive revocation, and lets the operator choose key types (RSA, ECDSA, EdDSA) and lifetimes.
• Can operate as an online intermediate CA for an existing root CA instead of acting as a root.
• Ships a Go wrapper for programmatic client usage and works with the step command-line client for scripting; storage backends include Badger and BoltDB.

Who uses it and how

• DevOps teams that need TLS everywhere without an operations-heavy PKI, including certificate issuance for VMs, containers, APIs, and database connections.
• Teams replacing static SSH keys with SSH certificates: people get certificates from their SSO identity, hosts get certificates from cloud instance identity documents.
• Platform and Kubernetes operators issuing short-lived certificates to pods on automated enrolment and renewal cycles.
• Organisations with an existing root CA that want step-ca as an online intermediate CA, keeping the root offline.
• Engineers who automate issuance from scripts through the step CLI or the Go wrapper instead of clicking through a UI.

Getting started

Installation is documented at smallstep.com/docs/step-ca/installation, and step-ca is normally paired with the step command-line client at github.com/smallstep/cli for enrolment and certificate operations. Smallstep's hosted website at smallstep.com/certificates is the project's entry point for documentation and downloads.

How it compares

step-ca is Apache-2.0 licensed and self-hosted, while Smallstep's commercial CA is a paid product targeting the same PKI space. The commercial offering adds capabilities step-ca does not include: multiple certificate authorities, active revocation via CRL and OCSP, a turnkey high-volume high-availability CA, an API for infrastructure-as-code management of the PKI, SCEP and NDES support for migrating from Active Directory Certificate Services, device identity with Secure Enclave and TPM 2.0 attestation, a web admin UI, ACME External Account Binding, identity provider integration, role-based access control, FIPS-compliant software, and HSM-bound private keys. step-ca is optimised for a two-tier PKI covering common DevOps use cases, and the trade is a free permissive licence and full data ownership in exchange for operating the CA and giving up those enterprise features.

When to use it — and when not to

Choose step-ca when a small team needs a working private CA with ACME, SSH certificates, and short-lived certificate automation, and is willing to run the CA process and its storage backends (Badger or BoltDB) and protect the signing keys themselves. Do not choose it if the requirement is active revocation with CRL or OCSP, multiple certificate authorities, turnkey high availability at volume, SCEP or NDES migration, MDM-driven enrolment, or FIPS and HSM key binding — those are commercial-edition features. The project is also strictly a two-tier PKI design, and with 299 open issues and a README that documents features more than it documents operations, a prospective self-hoster should read the installation docs before committing.