DEV.co
Open-Source Security · smallstep

certificates

step-ca is an open-source private certificate authority (CA) built in Go that automates TLS and SSH certificate management for internal infrastructure. It provides ACME server capabilities, multiple provisioning methods (OIDC, cloud instance identity, JWK tokens), and supports short-lived certificates with passive revocation.

Source: GitHub — github.com/smallstep/certificates
8.6k
GitHub stars
566
Forks
Go
Primary language
Apache-2.0
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
Repositorysmallstep/certificates
Ownersmallstep
Primary languageGo
LicenseApache-2.0 — OSI-approved
Stars8.6k
Forks566
Open issues289
Latest releasev0.30.2 (2026-03-23)
Last updated2026-07-06
Sourcehttps://github.com/smallstep/certificates

What certificates is

A Go-based online CA implementing RFC5280 (X.509) and RFC8555 (ACMEv2) standards, supporting RSA/ECDSA/EdDSA keys, multiple database backends (Badger, BoltDB, Postgres, MySQL), and SSH certificate issuance. Designed as a two-tier PKI for DevOps use cases with provisioners for OAuth OIDC, cloud identity, JWK, X5C, SCEP, and SSHPOP.

Quickstart

Get the certificates source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/smallstep/certificates.gitcd certificates# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Internal ACME Server for Development & Pre-Production

Replace public CAs in non-production environments. Supports http-01, dns-01, and tls-alpn-01 challenges for any ACMEv2 client (certbot, acme.sh, Caddy, Traefik, nginx, Apache). Eliminates browser trust warnings and certificate cost in internal workflows.

SSH Certificate Authority with SSO Integration

Centralize SSH authentication via OAuth OIDC providers (Okta, Azure AD, GSuite, Keycloak, Dex). Issue short-lived user and host certificates to replace authorized_keys files, eliminate TOFU warnings, and enforce MFA/security policies through SSO.

Automated TLS Issuance for Cloud VMs, Containers, and Kubernetes

Issue certificates for internal services using cloud instance identity documents (AWS, GCP, Azure), Kubernetes pod identities, or JWK tokens from CD/IaC tools (Terraform, Ansible, Puppet, Chef). Enables certificate renewal automation without manual key rotation.

Implementation considerations

  • Database backend selection (Badger, BoltDB, Postgres, MySQL) affects scaling and durability; PostgreSQL/MySQL recommended for production deployments requiring persistence guarantees.
  • Provisioner configuration complexity: evaluate which identity sources (OIDC, cloud identity, JWK, X5C) align with your authentication infrastructure before deployment.
  • Certificate lifetime and renewal policy design: short-lived certificates require coordinated client-side automation; plan refresh intervals and provisioner token rotation.
  • Root CA key management: step-ca can operate as intermediate CA; plan secure offline storage and ceremony for root key protection if not delegating to existing PKI.
  • Monitoring and audit logging: configure step-ca output and establish logging/alerting for certificate issuance, provisioner usage, and failed requests before production use.

When to avoid it — and what to weigh

  • You need active revocation (CRL/OCSP) — step-ca relies on short-lived certificates and passive revocation. For compliance requirements or scenarios needing immediate certificate revocation, this is insufficient. Consider commercial Smallstep offering or alternatives.
  • You require high-volume or high-availability CA — step-ca is optimized for typical DevOps scale, not enterprise-grade high-availability deployments. For millions of certificates or strict uptime SLAs, evaluate commercial CAs or Smallstep's managed offering.
  • You need FIPS compliance or HSM-bound keys — step-ca does not provide FIPS-mode operation or HSM integration. If regulatory compliance (FIPS 140-2/3) or hardware security module binding is mandatory, this is not suitable.
  • You need multi-CA hierarchies or legacy protocol support — step-ca is optimized for two-tier PKI. If you require complex hierarchies, SCEP for legacy AD CS migration, NDES, or device attestation (Secure Enclave/TPM), the commercial product is recommended.

License & commercial use

Apache License 2.0 (Apache-2.0): permissive OSI-approved license allowing commercial use, modification, and distribution with attribution and disclaimer of liability.

Apache 2.0 explicitly permits commercial use, including building proprietary services around step-ca. No license restrictions prevent commercial deployments. However, Smallstep Labs (maintainer) offers a commercial product with additional features (HSM, multi-CA, FIPS, managed CA); evaluate whether commercial support, SLAs, or enterprise features justify separate commercial licensing.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

SignalAssessment
MaintenanceActive
DocumentationStrong
License clarityClear
Deployment complexityModerate
DEV.co fitStrong
Assessment confidenceHigh
Security considerations

step-ca implements standard PKI and ACME protocols (RFC5280, RFC8555) with support for modern key types (RSA, ECDSA, EdDSA). No public security audits mentioned in provided data. Short-lived certificates reduce impact of key compromise. Passive revocation model trades real-time revocation for operational simplicity. Root CA key protection is operator responsibility (offline storage not automated). Database backend security depends on deployment (e.g., Postgres over TLS). Evaluate HSM integration needs separately; not built-in. OIDC integration security depends on identity provider configuration and token validation. No penetration test results or CVE history provided; requires independent security assessment.

Alternatives to consider

HashiCorp Vault with PKI secrets engine

General-purpose secrets management with integrated CA functionality, multi-cloud support, and programmatic APIs. More heavyweight; includes broader secret management beyond certificates. Steeper learning curve but richer feature set for large teams.

Let's Encrypt (public) + cert-manager (Kubernetes)

Free public TLS for internet-facing services with Kubernetes-native automation via cert-manager. Does not support internal PKI, SSH, or private CA scenarios. Suitable for public-web-only use cases; inadequate for internal infrastructure.

Smallstep Certificate Manager (commercial)

Commercial offering from step-ca maintainers with managed deployment, HSM support, multi-CA, active revocation, FIPS compliance, device identity, MDM integration, and role-based access control. Suitable for enterprises requiring SLA, compliance, or feature gaps in open-source version.

Software development agency

Build on certificates with DEV.co software developers

Ready to automate certificate management? Start with the installation guide at smallstep.com/docs/step-ca/installation, explore provisioner options, and test in your environment. For enterprise requirements (HSM, multi-CA, FIPS), contact Smallstep Labs.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

Related on DEV.co

Explore the category and the services that help you build with it.

certificates FAQ

Can step-ca replace Let's Encrypt for internal infrastructure?
Yes, for internal/private services only. step-ca runs as a private CA and is not trusted by browsers for public internet. Use for internal HTTPS, development, pre-prod, Kubernetes, and VMs. For public-facing services, use Let's Encrypt via ACME.
Do I need to run my own root CA or can step-ca be an intermediate?
step-ca can operate as an online intermediate CA subordinate to an existing root CA. This allows delegation while keeping the root offline. Alternatively, step-ca can generate and manage its own root; offline storage and ceremony are your responsibility.
What databases are supported for production?
Badger (embedded KV store), BoltDB (embedded), PostgreSQL, and MySQL. For production, PostgreSQL or MySQL recommended for durability, replication, and backup support. Badger/BoltDB suitable for smaller deployments or when embedded databases suffice.
Does step-ca support active revocation (CRL/OCSP)?
No. step-ca relies on short-lived certificates (hours to days) and passive revocation via non-renewal. If immediate revocation is required, evaluate alternatives or commercial Smallstep offering.

Software development & web development with DEV.co

Need help beyond evaluating certificates? DEV.co is a software development agency offering software development services and web development for teams of every size. Our software developers and web developers build custom software, web applications, APIs, and open-source security integrations — and maintain them long-term.

Evaluate step-ca for Your Infrastructure

Ready to automate certificate management? Start with the installation guide at smallstep.com/docs/step-ca/installation, explore provisioner options, and test in your environment. For enterprise requirements (HSM, multi-CA, FIPS), contact Smallstep Labs.