step-ca is an online Certificate Authority (CA) for secure, automated X.509 and SSH certificate management. It's the server counterpart to step CLI. It is secured with TLS, and it offers several configurable certificate provisioners, flexible certificate templating, and pluggable database backends to suit a wide variety of contexts and workflows. It employs sane default algorithms and attributes, so you don't have to be a security engineer to use it securely.

Teams use step-ca to:

• Generate TLS certificates for private infrastructure using the ACME protocol.
• Automate TLS certificate renewal.
• Add Automated Certificate Management Environment (ACME) support to a legacy subordinate CA.
• Issue short-lived SSH certificates via OAuth OIDC single sign on.
• Issue customized X.509 and SSH certificates.
• and much more ...

Don't want to run your own CA?

To get up and running quickly, or as an alternative to running your own step-ca server, consider creating a hosted Smallstep authority.

step-ca issues X.509 certificates for use with TLS, mutual TLS (mTLS) authentication, document signing, and X.509 authentication more broadly. With step-ca, you can:

• Automate certificate issuance and renewal for clients, servers, and Kubernetes workloads.
• Issue certificates to humans, e.g., using Single Sign-on (OpenID Connect) for authentication.
• Choose key types (RSA, ECDSA and EdDSA) and lifetimes to suit your needs.
• Issue short-lived certificates with automated enrollment, renewal, and passive revocation.
• Operate an online intermediate CA on an existing root CA, eg. to add support for ACME to an existing PKI.
• Operate a local Registration Authority (RA) on an internal network or inside a Kubernetes cluster that authorizes certificate requests for an upstream step-ca server.
• Deploy a high availability (HA) Certificate Authority using root federation and/or multiple intermediaries.

step-ca is capable of issuing SSH certificates to users and hosts. Delegate SSH authentication to step-ca and set up a transparent chain of trust for authorized access.

• Avoid the risk of trust-on-first-use (TOFU) when connecting to SSH hosts.
• Issue a short-lived SSH user certificate via Single Sign-on.

Provisioners are methods of using the CA to get certificates for humans or machines. They offer different modes of authorization for the CA.

For example, you can have your CA issue certificates in exchange for:

• ACME challenge responses from any ACMEv2 client
• OAuth OIDC single sign-on tokens, e.g.:
  • ID tokens from Okta, Google Workspace, Microsoft Entra ID and Auth0
  • ID tokens from an OAuth OIDC service you host, like Keycloak or Dex
• Cloud instance identity documents for VMs on AWS, GCP, and Azure
• Single-use, short-lived JWK tokens, e.g., issued by your CD tool — Puppet, Chef, Ansible, Terraform, etc.

X.509 Templates let you customize certificate fields, e.g.:

• Add custom Subject Alternative Names (SANs) or non-standard X.509 Object Identifiers (OIDs) to certificates.
• Restrict certificates by domain name or key size.
• Issue CA certificates with longer path lengths for multiple intermediaries.

step-ca ships with several built-in templates for everyday operations, and you can use Golang's text/template syntax to create new templates.

For strong protection of your CA signing keys, we've built step-ca integrations for PKCS #11 HSMs, Google Cloud KMS, AWS KMS, and YubiKey PIV, among others.

step-ca plays well with Kubernetes cert-manager and Envoy Secret Discovery Service. For more information, see Integrations.

While we think step-ca is the best open source, online Certificate Authority on the internet, every piece of software comes with limitations and tradeoffs.

step-ca is designed to favor a simple deployment of a scalable two-tiered X.509 PKI, with one Root CA and one Intermediate CA that issues end-entity certificates with passive revocation.

Here are some limitations of step-ca that grew out of our design choices:

• It issues X.509 certificates from a single configured Intermediate CA; multiple issuing CAs are not supported
• Its root CA is always offline; a single-tier PKI is not supported
• Issuance policies are authority-wide
• Known ACME concurrency limits for high-availability CAs
• Very limited options for active revocation (CRL, OCSP)
• Very limited options for legacy CA protocols
• Very limited options for device attestation
• No integration with Certificate Transparency (CT) logs
• No support for certificate issuance history or metrics
• No dynamic SCEP support (eg. for Intune or Jamf)
• No support for ACME External Account Binding (EAB)

If your use case demands these features, you should talk to us because you may be better served by our commercial product.