Step-CA : autorité de certification interne pour infra moderne

Gérer une PKI interne sur un parc de plus de 50 services, c'est le moment où le sysadmin réalise qu'il a accumulé du retard sur dix renouvellements OpenSSL faits à la main. Les "self-signed" expirent, les certificats internes ne sont pas en CT logs, le pattern "easy-rsa + cron" tient mal à grande échelle.

Step-CA, par Smallstep, vise les ops. Open source, écrite en Go, supporte ACME pour l'automation, RA distantes, certificats SSH, intégration Kubernetes. Pour les organisations qui veulent émettre du certificat à grande échelle sans subir HashiCorp Vault PKI engine ou des stacks legacy, c'est le bon outil.

Pas un substitut à Let's Encrypt pour les services publics. Un complément pour tout ce qui ne sort pas sur Internet : services internes, réseau de management, mTLS service-mesh, certificats SSH éphémères.

• Pourquoi pas Let's Encrypt seul
• Architecture step-ca et provisioners
• Déploiement initial : root + intermediate
• ACME pour automatisation interne
• Intégration Kubernetes via cert-manager
• Certificats SSH avec step-ca
• Rotation, révocation, monitoring
• Pièges et signaux d'alerte

Let's Encrypt est devenu le standard pour les services publics. Il ne couvre pas plusieurs cas :

Services internes. Un domaine db-master.internal ou api.lan ne résoud pas depuis Internet, donc pas de validation HTTP-01 ou DNS-01 par Let's Encrypt. Il faut une CA interne capable d'émettre pour ces noms.

Certificats short-lived agressifs. Let's Encrypt limite à 90 jours. Pour de la prod sécuritaire, on veut des certs de 24-48h, voire 1h. Step-CA permet ça facilement.

Certificats client (mTLS). Pour authentifier un service auprès d'un autre par certificat client, on a besoin de pouvoir émettre ces certs. Pas la zone Let's Encrypt.

SSH certificates. Step-CA peut aussi émettre des certificats SSH éphémères, signés par une CA SSH interne. Voir openssh-ca pour le contexte.

Air-gapped / isolés. Une infra qui ne sort pas sur Internet n'a pas accès à Let's Encrypt.

Pour les organisations qui combinent services publics (Let's Encrypt) et services internes (step-ca), on cohabite sans heurts. Chaque service utilise la CA appropriée.

Step-CA est un binaire Go qui expose une API REST et ACME. Il maintient :

• Un certificat root CA stocké en HSM ou fichier chiffré.
• Un ou plusieurs certificats intermediate qui signent les certs émis.
• Une base de provisioners (mécanismes d'authentification pour demander un certificat).
• Un journal d'émission pour traçabilité.

Provisioners disponibles :

• ACME : compatible avec n'importe quel client ACME (cert-manager, certbot, lego). Le moyen recommandé pour automatiser.
• JWK : authentification par token JWT signé.
• OIDC : auth par token OIDC (Google, GitHub, Keycloak). Idéal pour devs qui demandent des certs.
• K8sSA : auth par service account Kubernetes. Pour pods qui tirent leurs propres certs.
• X5C : authentification par certificat existant. Pour la rotation chained.
• AWS / GCP / Azure : provisioners cloud avec attestation de l'instance.
• SCEP : compatibilité legacy pour MDM, IoT.

Configuration via ca.json ou variables d'environnement. Modèle simple à comprendre, déclaratif, versionable en Git.

Le pattern recommandé : root offline, intermediate online.

# Bootstrap initial
step ca init \
  --name="MaCorpo Internal CA" \
  --dns="ca.internal" \
  --address="0.0.0.0:8443" \
  --provisioner="admin@example.fr"

# Cela génère :
# - ~/.step/certs/root_ca.crt et clé privée root
# - ~/.step/certs/intermediate_ca.crt et clé privée intermediate
# - ~/.step/config/ca.json

À ce stade, il faut déplacer la clé root offline. Sur une YubiKey HSM, sur un disque chiffré dans un coffre, sur du papier (paper backup) en cas de désastre. Le CA online n'a besoin que de la clé intermediate.

Démarrage :

step-ca ~/.step/config/ca.json

Pour la prod, faire tourner step-ca en service systemd ou conteneur Docker, derrière un reverse proxy avec TLS termination si besoin. La doc Smallstep fournit les unit files.

Distribution du root cert sur tous les clients du parc : push via Ansible, ajout au truststore système (update-ca-certificates sur Debian, update-ca-trust sur RHEL). Sans ça, les clients refuseront les certs émis par step-ca.

L'atout décisif de step-ca : implémenter ACME comme Let's Encrypt mais pour vos noms internes.

Configurer un provisioner ACME dans ca.json :

{
	"type": "ACME",
	"name": "acme-internal",
	"forceCN": true
}

Sur un serveur qui veut un certificat, utiliser n'importe quel client ACME (lego, certbot, acme.sh) configuré avec l'URL de step-ca :

lego --server="https://ca.internal/acme/acme-internal/directory" \
     --domains="api.internal" \
     --email="ops@example.fr" \
     run

Validation HTTP-01 ou DNS-01 selon le contexte. Le certificat est émis, valide pour les noms internes, signé par votre intermediate, vérifié par le root distribué partout.

C'est exactement le même flux que Let's Encrypt, sans dépendance Internet et avec contrôle complet sur la durée.

cert-manager est l'outil standard K8s pour gérer les certs. Il sait consommer step-ca via ACME comme issuer.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: stepca-internal
spec:
  acme:
    server: https://ca.internal/acme/acme-internal/directory
    email: ops@example.fr
    privateKeySecretRef:
      name: stepca-account-key
    solvers:
      - http01:
          ingress:
            class: nginx

Toute Certificate ressource créée avec cet issuer reçoit un cert step-ca. Pour mTLS service-mesh (Istio, Linkerd), step-ca peut aussi être l'identity provider du mesh. Linkerd 2 supporte step-ca natif comme trust anchor.

Pattern recommandé : un cluster K8s = un step-ca dédié, ou un step-ca centralisé multi-cluster avec provisioner X5C entre intermediates.

Au-delà des certificats x509, step-ca peut signer des certificats SSH OpenSSH.

# Provisionner un cert SSH user pour Alice
step ssh certificate alice@example.fr alice-key
# step-ca signe la clé publique d'Alice avec un cert SSH
# valide 1h, principal "alice", autorisé sur les hosts qui trustent step-ca

Côté serveur SSH, configurer TrustedUserCAKeys pointant vers le ssh-ca de step-ca :

TrustedUserCAKeys /etc/ssh/ssh_ca.pub

Le cert porte l'identité, la durée de vie, les principaux autorisés (matchent les AuthorizedPrincipalsFile). Plus de gestion authorized_keys par utilisateur, par host. Voir openssh-ca pour les détails du modèle.

Pour combiner avec une YubiKey FIDO2, l'utilisateur s'authentifie en OIDC (provisioner OIDC step-ca), reçoit un cert SSH 1h, signe avec la YubiKey lors du SSH effectif. Aucune clé privée long-terme stockée.

Rotation. Step-ca recommande des certs courts (24h-7j) plutôt que de la révocation. Avec ACME automatisé, rotation triviale, pas de cron à orchestrer.

Révocation. CRL et OCSP supportés. Pour un parc moderne, on préfère les short-lived qui éliminent le besoin de révocation. Si on a un certificat valide pour 24h et qu'il fuit, il est expiré demain.

Monitoring. Step-ca expose des métriques Prometheus : nombre de certs émis, erreurs ACME, temps de réponse. À intégrer dans stack monitoring.

Logs d'émission. Chaque émission est loggée avec identité du provisioner, sujet, durée. Auditable.

Backup. Sauvegarder ca.json + clé intermediate (chiffrée) + base d'émission. Restauration testée en lab.

Distribution du root. Si on émet des certs et qu'un client n'a pas le root dans son truststore, fail. Vérifier la distribution avant de bascule en prod. Tester avec un client "vierge".

Durée de vie intermediate. Le cert intermediate a une durée propre (typiquement 5 ans). Sa rotation doit être planifiée, et les services consommant les certs doivent accepter le nouvel intermediate avant l'expiration de l'ancien.

ACME sur réseau privé. Le serveur step-ca doit être joignable par les clients ACME (port 443 ou 8443). Ne pas oublier de l'exposer sur le LAN d'admin.

Provisioner password / token. Les provisioners JWK ou ACME EAB demandent un secret. Stocker dans un secret manager (Vault, sealed-secrets), pas en plain dans le repo Git.

Pas pour les certs publics. Les navigateurs ne trustent pas votre root. Pour www.example.fr, on garde Let's Encrypt. step-ca = interne uniquement.

HSM. Pour la conformité (PCI, HDS), stocker la clé intermediate dans un HSM matériel, pas un fichier. step-ca supporte PKCS#11 et YubiKey PIV.

Capacité d'émission. Step-ca tient des centaines de req/s. Pour des parcs >10k clients ACME, scaler horizontalement avec base PostgreSQL partagée.

Step-ca remplace avantageusement les PKI internes legacy à la easy-rsa. L'apport : automation ACME complète, plus de cron OpenSSL, plus de certs expirés en pleine nuit. Le travail réel est dans la distribution du root sur le parc et la définition des provisioners. Une CA interne tient rarement seule sur la durée : rotations d'intermediate, surveillance des expirations et secret des provisioners forment un suivi continu que vous pouvez aussi confier à une équipe d'exploitation.

• Smallstep step-ca documentation : référence install, provisioners, ops.
• GitHub smallstep/certificates : code source, releases.
• ACME protocol RFC 8555 : spec du protocole d'automation.
• Smallstep step CLI : CLI cliente pour gérer la CA et les certs.
• cert-manager documentation : intégration Kubernetes via ACME.
• NIST SP 800-57 Key Management : référentiel cryptographique pour les durées et la rotation.