# step-ca: a private X.509 and SSH certificate authority you can run yourself

> step-ca is Smallstep's open source online CA and ACME server, written in Go and licensed under Apache-2.0. It is a good fit for small teams that need short-lived TLS and SSH certificates without buying a PKI suite, and a poor fit if you need CRLs, OCSP or an admin UI.

**smallstep/certificates** — 🛡️ A private certificate authority (X.509 & SSH) & ACME server for secure automated certificate management, so you can use TLS everywhere & SSO for SSH.

- Repository: https://github.com/smallstep/certificates
- Website: https://smallstep.com/certificates
- Stars: 8,913 · Forks: 595
- Language: Go
- License: Apache-2.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/smallstep-certificates

## The gap step-ca fills: a private CA small teams can actually run

Standing up a public key infrastructure is out of reach for many small teams, and the README says so directly: "Setting up a public key infrastructure (PKI) is out of reach for many small teams. step-ca makes it easier." The project is an online certificate authority, the server half of a pair, with the step CLI as the client for working with certificates and keys. Both are maintained by Smallstep Labs.

The intended audience is DevOps rather than a corporate PKI office. The README lists the jobs it is meant for: HTTPS server and client certificates that work in browsers, TLS certificates for VMs, containers, APIs, database connections and Kubernetes pods, and SSH certificates for people and for hosts. If your problem is "every internal service needs a certificate and nobody wants to run a Windows CA," this is the target case. If your problem is "we need a certificate that the public internet trusts," it is not, because step-ca is a private CA and the trust comes from distributing your own root.

## How issuance works: provisioners decide who gets a certificate

The architecture separates the CA from the thing that authorizes a request. The README calls these provisioners, and they are the core mechanism: a request is authorized by presenting some credential, and the provisioner type determines what that credential is. The repository has a policy/ directory and a webhook/ directory alongside authority/ and ca/, which matches the description of a request pipeline that authorizes, applies policy, then signs.

The list of accepted credentials is long and specific. An ACME challenge response from any ACMEv2 client. An OAuth OIDC single sign-on token from Okta, GSuite, Azure AD, Auth0, or a self-hosted OIDC service like Keycloak or Dex. A cloud instance identity document from AWS, GCP or Azure. A single-use, short-lived JWK token issued by a CD tool such as Puppet, Chef, Ansible or Terraform. A trusted X.509 certificate through the X5C provisioner. A Nebula host certificate. A SCEP challenge. An SSH host certificate needing renewal through the SSHPOP provisioner.

That breadth is the design bet. Instead of one enrollment path, step-ca lets each environment prove identity the way it already can. The trade-off is configuration surface: every provisioner is another set of keys, claims and policy to get right, and the README does not enumerate the failure modes of each one.

## Installing step-ca and issuing a first certificate

The README does not contain install commands. It points to the project's own installation page at smallstep.com/docs/step-ca/installation, and the repository ships packaging material under debian/, docker/ and systemd/ for those who prefer to build or package it themselves. The Makefile builds the server binary from the package path github.com/smallstep/certificates/cmd/step-ca with the binary name step-ca, so a source build is a Go build of that target.

```bash
PKG?=github.com/smallstep/certificates/cmd/step-ca
BINNAME?=step-ca
```

Those two variables at the top of the Makefile are what the build target uses; the default target runs lint, test and build in that order, and the ci target runs testcgo and build. The Makefile also bootstraps its own tooling, including golangci-lint, govulncheck, gotestsum, goreleaser and cosign, so a first build pulls a fair amount of toolchain.

```bash
make bootstra%
make build
```

The bootstrap target installs the lint and release tools listed above. After the build you have a step-ca binary, and the next step is initialization, which the project documents on its own site rather than in the README. The README's contribution to a first run is the examples/ directory: examples/basic-client, examples/bootstrap-client, examples/bootstrap-tls-server, examples/bootstrap-mtls-server, examples/docker, examples/pki, examples/ansible and examples/puppet. Those directories are the honest starting point for a first real use, because they show a client talking to a running CA rather than an abstract config.

## ACME support and what it does not cover

step-ca is an ACME server implementing RFC 8555, so any ACMEv2 client can request certificates from it. The README documents support for the three common challenge types: http-01, where you place a token at a well-known URL to prove control of the web server; dns-01, where you add a TXT record to prove control of the DNS record set; and tls-alpn-01, where you respond at the TLS layer, as Caddy does. Smallstep has written client examples for certbot, acme.sh, win-acme, Caddy, Traefik, Apache and nginx.

This is where the comparison with the commercial product starts to matter. The README's own comparison list puts ACME External Account Binding (EAB) on the commercial side, not in step-ca. If your ACME clients require EAB, that is a real constraint, not a detail. The same list places active revocation through CRL and OCSP, multiple certificate authorities, a turnkey high-volume high-availability CA, an admin UI, fine-grained role-based access control and HSM-bound private keys outside the open source server. Read that list before you plan a deployment, because it is the project's own statement of scope.

## Short-lived certificates and passive revocation

The README's answer to revocation is to avoid needing it. It advertises short-lived certificates with automated enrollment, renewal and passive revocation, and links to a blog post explaining the idea. The mechanism is lifetime: a certificate that expires in hours does not need a revocation list, because the window in which a compromised key is useful is small.

This is a genuine design choice with a genuine cost. Passive revocation only works if renewal actually happens, which means your clients must be able to reach the CA on schedule. If a client misses renewals, it stops working, and the failure looks like an outage rather than a security event. The README does not document a fallback for clients that cannot renew. Teams that need to invalidate a certificate immediately, for a legal hold or a breach with a long detection delay, are outside what this model provides, and the README points those needs at the commercial CA instead.

## Storage backends and the operational footprint

The CA stores its state in a database, and the README lists Badger, BoltDB, Postgres and MySQL as options. The choice is not cosmetic. Badger and BoltDB are embedded, which means a single node holding the data, while Postgres and MySQL are network databases that allow more than one CA process to share state. The README describes the commercial offering as a turnkey high-volume, high-availability CA, which implies the open source server is not positioned that way.

The go.mod file shows the dependency weight: cloud SDKs for Google Cloud, Vault API clients with approle, aws and kubernetes auth, Prometheus client libraries, New Relic, Nebula, TPM support through go-tpm and go-attestation, and the linkedca package. A monitoring/ directory and a webhook/ directory exist in the tree, so metrics and outbound hooks are part of the server. That is a lot of surface for a single binary, and it is the reason the build bootstraps several tools. If you want a CA that does one thing with a minimal dependency tree, this is not that project.

## Alternatives and where step-ca is the wrong tool

The closest comparison the README itself draws is with Smallstep's commercial certificate manager, and the difference is scope rather than protocol. The commercial product adds multiple CAs, active revocation, SCEP and NDES for migrating off Active Directory Certificate Services, device identity with Secure Enclave and TPM 2.0 attestation, MDM integration for Jamf and Intune, a web admin UI, EAB and FIPS-compliant software. If you need any of those, the open source server is the wrong tool and the README says so.

There is also a category difference worth naming. A private CA like step-ca issues certificates that only your own trust stores accept, which is exactly right for internal services and exactly wrong for a public website. And the two-tier PKI design the README describes, an online intermediate serving common DevOps cases, means the root is expected to stay offline. Teams that want a single self-contained CA process with no offline root ceremony are fighting the intended shape. On the SSH side, step-ca issues certificates in exchange for SSO identity tokens or cloud instance documents, which replaces static authorized_keys files with a short-lived credential model; if your environment cannot reach an identity provider, that path is closed.

## Licence, maintenance and upgrade cost

The repository is licensed Apache-2.0, and the README badge links to the same licence. Apache-2.0 permits commercial use and modification with the usual notice and patent terms; it is not a copyleft licence, so embedding the server in a product does not force you to publish your own code. That is a general property of the licence text, not legal advice, and the project also runs a CLA assistant for contributions, which is a governance detail rather than a restriction on users.

The repository is not archived, and the last push was on 2026-09-21. Recent releases are v0.30.2 on 2026-03-23, v0.30.1 on 2026-03-19 and v0.30.0 on 2026-03-18, so the release cadence in that window was rapid. The upgrade cost is the usual one for a CA: the server owns your trust anchor and your issued certificates, so a version bump is not a drop-in restart. The CHANGELOG.md at the repository root is where release notes live, and the go.mod declares go 1.26.0, so building from source requires a matching Go toolchain. The README does not document rollback or downgrade procedures, which is worth confirming against the changelog before you upgrade a production CA.

## Conclusion

Adopt step-ca if you are a small team that wants short-lived TLS and SSH certificates issued from your own CA, with automated enrollment through ACME, OIDC, cloud instance identity or JWK tokens, and you are comfortable with a two-tier PKI. Do not adopt it expecting active revocation, an admin UI, HSM-bound keys or a turnkey high-availability deployment, because the README lists those under the commercial product. Before you commit, verify which database backend you will run and confirm that the passive revocation model of short-lived certificates matches your incident response requirements.

## FAQ

### Is step-ca free to use?

Yes. The repository is licensed Apache-2.0, which permits commercial use and modification. Smallstep also sells a commercial certificate manager that adds features the README lists separately, such as active revocation and an admin UI.

### Does step-ca work as an ACME server with certbot or Caddy?

The README states that step-ca is an ACME server supporting RFC 8555 and the http-01, dns-01 and tls-alpn-01 challenge types, and that Smallstep has written client examples for certbot, acme.sh, win-acme, Caddy, Traefik, Apache and nginx. ACME External Account Binding is listed under the commercial product rather than the open source server.

### Which database backends does step-ca support?

The README lists Badger, BoltDB, Postgres and MySQL. Badger and BoltDB are embedded, while Postgres and MySQL are network databases, which matters if you want more than one CA process sharing state.

### How does step-ca handle certificate revocation?

The README describes short-lived certificates with automated enrollment, renewal and passive revocation, which limits exposure by keeping lifetimes short rather than by publishing revocation lists. Active revocation through CRL and OCSP appears in the README's list of commercial-only features.

### Can step-ca issue SSH certificates as well as TLS certificates?

Yes. The README says it issues SSH certificates for people in exchange for single sign-on identity tokens and for hosts in exchange for cloud instance identity documents, and it lists an SSHPOP provisioner for SSH host certificates needing renewal.

## Sources

- [License: Apache-2.0](https://github.com/smallstep/certificates/blob/master/LICENSE)
- [Project website](https://smallstep.com/certificates)
- [README](https://github.com/smallstep/certificates/blob/master/README.md)
- [Releases](https://github.com/smallstep/certificates/releases)
- [smallstep/certificates on GitHub](https://github.com/smallstep/certificates)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/smallstep-certificates