step-ca — Private Certificate Authority for DevOps

What it is

step-ca is a private online Certificate Authority created by Smallstep that brings the automation of the public web PKI to internal infrastructure. It issues X.509 certificates for TLS and SSH certificates for authentication, supporting the ACME protocol that powers Let's Encrypt. This means internal services can get certificates automatically using the same tools (certbot, ACME clients) used on the public internet.

step-ca targets DevOps engineers and platform teams who need encrypted internal traffic, mutual TLS between microservices, and SSH certificate-based authentication without exposing services to public certificate authorities.

How it saves time or tokens

step-ca automates certificate issuance and renewal that would otherwise require manual generation and distribution. The ACME protocol handles certificate lifecycle automatically, eliminating expired certificate incidents. SSH certificates replace SSH key management entirely -- no more distributing authorized_keys files across servers.

How to use

1. Install the step CLI and step-ca: brew install step step-ca.
2. Initialize a new CA: step ca init --name 'My CA' --dns ca.example.com --address :443.
3. Start the CA server: step-ca $(step path)/config/ca.json.

Example

# Initialize a new private CA
step ca init --name 'Internal CA' --dns ca.internal --address :8443

# Start the CA
step-ca $(step path)/config/ca.json

# Get a certificate for a service
step ca certificate myapp.internal myapp.crt myapp.key

# Renew automatically with a daemon
step ca renew --daemon myapp.crt myapp.key

# Issue an SSH certificate
step ssh certificate user@host ssh_key

Related on TokRepo

• AI Tools for Security -- explore security tools for certificate management and encryption
• AI Tools for DevOps -- discover DevOps automation for infrastructure security

Common pitfalls

• The root CA key must be kept secure; compromise of this key invalidates the entire certificate chain. Use hardware security modules (HSMs) in production.
• Clients need the CA root certificate installed in their trust store; without it, TLS connections to internal services will fail with certificate verification errors.
• ACME challenges for internal services require DNS or TLS-ALPN challenges, not HTTP-01, since internal services are not publicly accessible.