Configs2026年4月13日·1 分钟阅读

step-ca — Private Certificate Authority for DevOps

step-ca is an open-source online Certificate Authority for secure automated certificate management. It provides ACME, SSH certificates, and mTLS for internal infrastructure — enabling TLS everywhere and SSO for SSH in your organization.

AI
AI Open Source · Community
快速使用

先拿来用,再决定要不要深挖

这里应该同时让用户和 Agent 知道第一步该复制什么、安装什么、落到哪里。

# Install step CLI and step-ca
brew install step
brew install step-ca
# Or download from smallstep.com

# Initialize a new CA
step ca init --name "My CA" --dns ca.example.com --address :443

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

# Get a certificate (ACME protocol)
step ca certificate myapp.internal myapp.crt myapp.key

# Or use with certbot-like ACME
step ca certificate --acme myapp.internal myapp.crt myapp.key

Introduction

step-ca is a private ACME Certificate Authority that brings the automation of the public web PKI to your internal infrastructure. Just as certbot gets free certificates from the public internet, step-ca issues certificates for internal services — enabling mutual TLS, encrypted internal traffic, and SSH certificate-based authentication.

With over 8,000 GitHub stars, step-ca is created by Smallstep and used by organizations that need automated certificate management for microservices, Kubernetes, databases, and internal tools without exposing them to public CAs.

What step-ca Does

step-ca runs as an online Certificate Authority that issues X.509 certificates (for TLS) and SSH certificates (for SSH authentication). It supports the ACME protocol (same as the public internet), enabling automatic certificate issuance and renewal. This means you can use standard tools like certbot, Caddy, and Traefik with your private CA.

Architecture Overview

[step-ca Server]
Private Certificate Authority
ACME, OIDC, JWK provisioners
        |
+-------+-------+-------+
|       |       |       |
[X.509  [SSH     [mTLS]
Certs]   Certs]   Mutual]
TLS for  SSO for  Service-to-
services SSH      service auth
        |
   [Provisioners]
   ACME: auto-issue via protocol
   OIDC: issue via SSO login
   JWK: issue via token
   Cloud: AWS/GCP/Azure identity
        |
   [Integrations]
   Caddy, Traefik, Nginx
   Kubernetes cert-manager
   systemd, cron renewal
   OpenSSH certificates

Self-Hosting & Configuration

# Initialize CA with ACME support
step ca init \
  --name "Internal CA" \
  --dns ca.internal \
  --address :8443 \
  --provisioner admin@example.com

# Enable ACME provisioner
step ca provisioner add acme --type ACME

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

# Issue a certificate for a service
step ca certificate api.internal api.crt api.key --ca-url https://ca.internal:8443

# Auto-renew with step CLI
step ca renew --daemon api.crt api.key

# SSH certificate authentication
step ssh certificate admin@example.com ssh_user_key \
  --principal admin --principal root

# Use with Kubernetes cert-manager
# Install step-issuer for cert-manager
# to automatically issue certs for Ingress/Services
// ca.json — CA configuration
{
  "address": ":8443",
  "dnsNames": ["ca.internal"],
  "authority": {
    "provisioners": [
      {
        "type": "ACME",
        "name": "acme"
      },
      {
        "type": "OIDC",
        "name": "google",
        "clientID": "...",
        "configurationEndpoint": "https://accounts.google.com/.well-known/openid-configuration"
      }
    ]
  },
  "tls": {
    "minVersion": 1.2,
    "maxVersion": 1.3
  }
}

Key Features

  • ACME Protocol — same automation as public web CAs (certbot compatible)
  • X.509 Certificates — TLS for internal services, databases, and APIs
  • SSH Certificates — replace SSH keys with short-lived certificates (SSO for SSH)
  • mTLS — mutual TLS for service-to-service authentication
  • Multiple Provisioners — ACME, OIDC (SSO), JWK, cloud identity
  • Auto-Renewal — certificates renew automatically before expiry
  • Kubernetes — cert-manager integration for automatic K8s certs
  • Short-Lived Certs — issue certificates valid for hours, not years

Comparison with Similar Tools

Feature step-ca HashiCorp Vault PKI EJBCA cfssl mkcert
Type Online CA PKI engine Enterprise CA CLI CA Dev certs
ACME Yes No Yes No No
SSH Certs Yes Yes No No No
Complexity Low Moderate High Low Very Low
Auto-Renewal Yes Via Vault agent Yes Manual No
Production Yes Yes Yes Basic No (dev only)
Best For DevOps PKI Vault users Enterprise Simple CA Local dev

FAQ

Q: step-ca vs mkcert — when should I use which? A: mkcert for local development certificates. step-ca for production internal PKI with automated certificate lifecycle, SSH certificates, and mTLS. mkcert is a dev tool; step-ca is infrastructure.

Q: Can I use step-ca with Caddy? A: Yes. Point Caddy to your step-ca ACME endpoint and it automatically gets certificates for internal domains — just like it does with public domains.

Q: How do SSH certificates work? A: Instead of distributing SSH public keys, step-ca issues short-lived SSH certificates. Users authenticate via SSO (OIDC), receive a certificate valid for 8 hours, and SSH servers trust the CA. No more managing authorized_keys files.

Q: Is step-ca free? A: Yes, step-ca is open source (Apache-2.0). Smallstep offers a commercial managed service (Smallstep Certificate Manager) for teams that want hosted PKI.

Sources

讨论

登录后参与讨论。
还没有评论,来写第一条吧。

相关资产