Automatiser le renouvellement de la PKI interne : intégrer ACME, HashiCorp Vault et systemd-timers

Einleitung: L’automatisation du renouvellement PKI interne est essentielle pour les exploitants et administrateurs lorsqu’un grand nombre de certificats TLS internes sont gérés — par exemple pour des services internes, des passerelles IoT, des VPNs ou l’authentification client. Dans cet article, je montre de manière pragmatique comment coupler ACME (Automated Certificate Management Environment — protocole pour l’émission automatisée de certificats) avec HashiCorp Vault (Vault — gestion des secrets et moteur PKI optionnel de signature) et utiliser systemd‑timers (systemd‑Timers — ordonnanceur moderne sur Linux avec intégration Journald), afin que les renouvellements soient planifiés, exécutés et distribués de façon fiable.

Pourquoi l’automatisation du renouvellement de la PKI est nécessaire

Les certificats expirent typiquement simultanément sur des centaines d’hôtes. Le remplacement manuel est source d’erreurs, provoque des interruptions et des lacunes d’audit. L’automatisation réduit la charge, diminue les risques d’indisponibilité et garantit des processus de sécurité cohérents. La gouvernance reste toutefois centrale : durée de validité, rôles, journaux d’audit et concepts d’accès en moindre privilège doivent être définis avant la mise en production.

Automatisation du renouvellement PKI interne: aperçu d’architecture

La séparation recommandée comprend trois couches :

• Couche de signature : Vault en tant que CA/signataire interne. Le moteur PKI de Vault signe les CSRs ; la clé Root reste idéalement hors ligne.
• Couche protocole/intégration : un ACME‑proxy ou un service frontal compatible ACME reçoit les requêtes ACME et les traduit en appels de signature vers Vault.
• Couche opérations : des systemd‑timers sur les hôtes ou sur des runners centraux planifient et exécutent des jobs de renouvellement, distribuent et valident les certificats.

Cette séparation améliore la sécurité, l’auditabilité et la flexibilité opérationnelle : signature, authentification et ordonnancement ont des responsabilités distinctes.

Décisions de conception et prérequis

Questions importantes avant de démarrer :

• Root vs. Intermediate : utilisez Vault comme Intermediate, signé par le Root conservé hors ligne. Cela minimise l’exposition du Root.
• Durée de validité : des durées plus courtes (p. ex. 90 jours) augmentent la sécurité, mais accroissent la fréquence des renouvellements et la charge.
• Distribution de la confiance : assurez‑vous que les clients reçoivent le bundle CA (via CM‑Tooling, paquet, MDM).
• Authentification des machines : mTLS (p. ex. avec des certificats machines de production) ou Vault AppRole sont des modèles courants — les deux ont des avantages et inconvénients en matière de gestion des secrets et de durée de vie.
• Observabilité et audit : activez les Vault Audit Devices et collectez les logs du proxy / des hôtes.

Modèles d’implémentation : client direct vs ACME‑proxy

Deux modèles courants :

Client ACME direct sur les hôtes

Les clients (p. ex. acme.sh, certbot) demandent les certificats eux‑mêmes. Avantage : décentralisé et robuste ; inconvénient : plus de configuration et une authentification à Vault plus complexe.

ACME‑proxy central

Un proxy central valide les requêtes, authentifie les hôtes (mTLS, OAuth) et communique avec Vault. Avantage : contrôle centralisé, audit simplifié ; inconvénient : chemin réseau supplémentaire et contraintes de disponibilité.

Installation concrète : Vault PKI, ACME‑Proxy, systemd‑timers

Les étapes clés sont :

1. Configurer le moteur PKI de Vault et mettre en place l’Intermediate.
2. Implémenter l’ACME‑proxy (p. ex. avec lego ou un composant de service Go léger), qui authentifie les requêtes et les mappe vers Vault.
3. Créer des unités systemd‑timer qui exécutent périodiquement des scripts de renouvellement, vérifient les certificats et rechargent les services.

Vault PKI : exemples de commandes

vault secrets enable pki
vault secrets tune -max-lease-ttl=87600h pki
vault write pki/root/generate/internal common_name="Company Internal Root" ttl=87600h
vault write pki/intermediate/generate/internal common_name="Company Intermediate" | tee csr.json
vault write pki/root/sign-intermediate csr=@csr.json format=pem_bundle ttl=43800h > signed_intermediate.pem
vault write pki/intermediate/set-signed certificate=@signed_intermediate.pem

Vault sépare ainsi le Root et l’Intermediate, ce qui permet une gestion sécurisée des clés. En cas d’échec des signatures : vérifiez les autorisations des tokens Vault, les journaux d’audit et les paramètres de TTL.

ACME‑Proxy : tâches et mapping

Le proxy doit :

• Authentifier les hôtes (mTLS ou token).
• Vérifier que des valeurs comme CN/SAN correspondent aux motifs autorisés.
• Associer les requêtes à un rôle Vault et demander leur signature.
• Implémenter du rate-limiting et générer des logs d’audit.

Exemple YAML‑mapping :

acme:
  auth_method: mTLS
  allowed_roles:
    - name: webserver
      allowed_sans:
        - '*.svc.internal'
      vault_role: webserver-role
    - name: dbserver
      allowed_sans:
        - 'db-*.internal'
      vault_role: dbserver-role
rate_limit:
  requests_per_minute: 60

systemd‑timers : planification fiable

Les systemd‑timers offrent RandomizedDelaySec, intégration avec Journald, Persistent=true (relance les jobs après une panne système) et un meilleur contrôle qu’avec cron. Exemple Service+Timer :

# /etc/systemd/system/pki-renew.service
[Unit]
Description=Run PKI renewal script
After=network-online.target

[Service]
Type=oneshot
User=root
ExecStart=/usr/local/bin/pki-renew.sh

# /etc/systemd/system/pki-renew.timer
[Unit]
Description=Timer for PKI renewal

[Timer]
OnCalendar=*-*-* 02:00:00
RandomizedDelaySec=3600
Persistent=true

[Install]
WantedBy=timers.target

Le script lui-même doit fonctionner de manière atomique : fichier de verrouillage, répertoire temporaire et codes d’erreur explicites. Exemple de squelette :

#!/bin/bash
set -euo pipefail
LOCKDIR=/var/lock/pki-renew.lock
if ! mkdir "$LOCKDIR" 2>/dev/null; then
  echo "Another run in progress" >&2
  exit 0
fi
trap 'rm -rf "$LOCKDIR"' EXIT

# Anfrage an ACME-Proxy und lokale Installation
/usr/local/bin/acme-request --cn "$(hostname -f)" --out /etc/ssl/private/host.pem
systemctl reload nginx || systemctl RESTart nginx

Exemple pratique : Vault‑Policy et ACME‑Role

Les policies limitent les rôles qui peuvent signer des SANs/CNs. Exemple de Vault‑Policy (HCL) :

# webserver-policy.hcl
path "pki/issue/webserver-role" {
  capabilities = ["create", "update"]
}

# Allow read of CA bundle
path "pki/cert/ca" {
  capabilities = ["read"]
}

Le rôle lui-même définit les motifs SAN et le TTL :

vault write pki/roles/webserver-role  
  allowed_domains="svc.internal"  
  allow_subdomains=true  
  max_ttl="72h"

Si la policy est trop permissive, il existe un risque d’abus ; si elle est trop RESTrictive, l’automatisation échoue. Testez de manière itérative en staging.

Déploiement et installation atomique des certificats

Une erreur opérationnelle fréquente est une installation de certificats incohérente, où les fichiers sont partiellement écrits et où les services redémarrent avec des fichiers incomplets. Utilisez des schémas atomiques : écrivez les nouveaux artefacts dans un chemin temporaire, validez le fichier puis remplacez-le via un lien symbolique. Cela garantit une image cohérente du système de fichiers et facilite le rollback.

# installation atomique
TMPDIR=/tmp/new-cert-$$
mkdir -m 700 "$TMPDIR"
cp cert.pem "$TMPDIR/"
cp key.pem "$TMPDIR/"
# validation
openssl x509 -noout -text -in "$TMPDIR/cert.pem" >/dev/null
# remplacement atomique
mv /etc/ssl/current /etc/ssl/old-$(date +%s) || true
ln -sfn "$TMPDIR" /etc/ssl/current
systemctl reload myservice

Auf Windows oder in containerisierten Umgebungen weichen Sie auf passende Mechanismen aus: z. B. PKCS#12‑Bundles für IIS/Windows oder Mount‑Overlays für Container.

HSM, TPM und Vault Transit: Schlüssel nie exportieren

Für besonders schützenswerte Schlüssel verwenden Sie HSMs (Hardware Security Module — dedizierte, zertifizierte Key‑Stores) oder TPM (Trusted Platform Module — motherboard‑gebundenes Root of Trust). Vaults Transit Engine erlaubt signieren/verifizieren, ohne private Keys zu exportieren. Betriebsfolge: Root in HSM, Vault konfiguriert Transit als Signer, intermediates werden erzeugt und signiert über Transit, Clients erhalten nur Zertifikate.

Container und Kubernetes: Besonderheiten

In Cloud‑ und Containerumgebungen gelten zusätzliche Einschränkungen: Dateisysteme sind ephemer, Init‑Containers können Zertifikate vor Start bereitstellen. Kubernetes‑Cluster verwenden häufig Secrets; hier sollten Sie die Secrets verschlüsseln (e.g. Sealed Secrets) und Rollouts über Deployments mit readiness‑Probes steuern. Achten Sie auf die Rechte von kubelets: diese dürfen nicht unbegrenzten Zugriff auf Signierpfade erhalten.

Monitoring‑Details und Metriken

Bauen Sie Metriken granular auf: pki_renew_requests_total, pki_renew_success_total, pki_renew_failures_total, pki_cert_age_seconds sowie exporter‑seitige Gauges für verbliebene Tage bis Ablauf. Alerts sollten nicht nur Fehlerquoten, sondern auch Anstiege der Renew‑Latenz beobachten — ein Indikator für Performance‑Probleme beim Proxy.

Chaos‑Tests, Staging‑Checks und Validierung

Testen Sie resilient: simulieren Sie Vault‑Ausfälle, Netzwerk‑Partitionen und Rate‑Limit‑Hits. Führen Sie Canaries durch, bevor Sie global umstellen: eine kleine Gruppe von Hosts erhält das neue CA‑Bundle, z. B. per Ansible‑Playbook. Nutzen Sie synthetische End‑to‑End‑Tests, die ein TLS‑Handshake vor und nach Renewal prüfen.

Operational Runbook: Schritt‑für‑Schritt bei Renewal‑Fehlern

1. Prüfen Sie Systemzeit: timedatectl status — Clock drift bricht TLS.
2. Vault Health und Audit: vault status und Audit‑Logs einsehen.
3. Proxy‑Logs: prüfen Sie 401/403 (Auth), 429 (Rate limit) und 5xx (Serverfehler).
4. Host‑Skript prüfen: Lockfiles, SELinux‑Kontext, fehlende Binaries, Berechtigungen.
5. Führen Sie manuelles Request per Staging‑ACME aus, um Pfad‑Probleme zu identifizieren.

Beispiel: robustes Renewal‑Skript mit flock und Logging

#!/usr/bin/env bash
set -euo pipefail
exec 3>&1
LOG=/var/log/pki-renew.log
flock -n /var/lock/pki-renew.lock -c "bash -c '
  echo "$(date -Iseconds) START" | tee -a $LOG
  /usr/local/bin/acme-request --cn "$(hostname -f)" --out /etc/ssl/private/host.pem || { echo "request failed" | tee -a $LOG; exit 2; }
  chown root:ssl-cert /etc/ssl/private/host.pem && chmod 640 /etc/ssl/private/host.pem
  systemctl try-reload-or-RESTart myservice || { echo "reload failed" | tee -a $LOG; exit 3; }
  echo "$(date -Iseconds) OK" | tee -a $LOG
'"

Exit‑Codes helfen Alerting‑Tools, eindeutige Ursachen zuzuweisen. Logrotation nicht vergessen.

Typische Stolperfallen und Vorsichtsmaßnahmen

• Uhrzeit/Timezone: TLS ist zeitabhängig; abweichende Systemzeiten führen zu Validierungsfehlern.
• Permissions de fichiers/SELinux : les services ne peuvent pas lire les certificats, bien qu’ils soient présents.
• Catalogage des responsabilités : Qui peut signer manuellement à court terme ? Des rôles clairs empêchent les actions non autorisées.
• Rate‑Limits : testez contre un proxy de staging, afin que la production ne soit pas subitement bloquée.

Fazit

Automatiser le renouvellement PKI interne réduit la charge opérationnelle et les risques d’indisponibilité, mais exige une architecture propre, des politiques RBAC, de l’observabilité et des procédures d’urgence définies. La combinaison de HashiCorp Vault comme signataire, d’un ACME‑proxy comme passerelle de protocole et de systemd‑timers comme planificateur est éprouvée en pratique : elle sépare les responsabilités, facilite l’audit et permet de monter en charge si vous prenez en compte les limits de débit (rate‑limits) et l’étalement. Testez en staging, effectuez des contrôles chaos et documentez des runbooks — ainsi, votre système de renouvellement reste contrôlable et résilient.

Sécurité opérationnelle, récupération et montée en charge — compléments pratiques

Dans l’exploitation en production d’une pile de renouvellement PKI automatisée, ce ne sont pas seulement les configurations qui déterminent le succès, mais aussi les processus opérationnels et les scénarios de panne. Vous trouverez ci‑dessous des indications concrètes sur la sauvegarde/récupération, la haute disponibilité, les processus de rollover et la protection contre les abus — le tout avec un regard tourné vers les administrateurs et les décideurs IT.

Vault‑Backup, Unseal und Auto‑Unseal‑Strategien

Ne sécurisez pas seulement les sauvegardes de base de données, mais surtout les matériaux d’Unseal : Shamir‑Shares, HSM‑Keys ou configurations Cloud‑KMS. Si vous utilisez Shamir, définissez des Recovery‑Shops et des rôles (qui a accès à combien de Shares). L’Auto‑Unseal via Cloud‑KMS ou HSM réduit la charge manuelle lors des redémarrages, mais introduit de nouveaux risques de dépendance : segmentez strictement les droits d’accès KMS et conservez des journaux d’accès (audit) pour les événements d’Unseal.

HA, Replikation und regionaler Ausfall

Vault en mode HA (Integrated Storage ou un backend cohérent comme Consul) permet la réplication en lecture/écriture. Décidez si vous avez besoin d’une réplication active‑active ou active‑passive. Pour l’ACME‑proxy, on recommande une mise à l’échelle horizontale avec sticky‑sessions ou une persistance centrale pour les compteurs de rate‑limit, afin qu’un basculement ne génère pas de requêtes en double. Testez le basculement Cross‑DC : mettez hors service une région, validez les latences de signature et si l’Auto‑Unseal intervient.

Key/CA‑Rollover und Kompatibilität

Un rollover planifié de la CA intermédiaire est une opération normale mais critique. Menez le rollover par étapes : préparez la nouvelle CA intermédiaire, signez‑la avec le Root de confiance, distribuez parallèlement les nouveaux bundles CA et prévoyez des durées de chevauchement plus longues pour que les clients acceptent les deux chaînes. Documentez les scénarios de retour : comment revenir à l’ancienne CA intermédiaire si des clients sont incompatibles.

Revocation, CRL und OCSP‑Design

Décidez tôt si vous utilisez les CRL, OCSP ou les deux. Les CRL sont simples à mettre en œuvre mais peu évolutives ; OCSP fonctionne en ligne mais exige une infrastructure de répondant à faible latence et hautement disponible. Pour les réseaux internes, un OCSP‑responder léger devant la PKI de Vault peut suffire ; assurez‑vous que les clients reçoivent des URL CRL/OCSP correctement configurées et testez les scénarios hors ligne lorsque les répondants ne sont pas accessibles.

Notfallprozesse und minimaler Zugriff

Définissez clairement : qui est autorisé, en cas d’urgence, à signer ou à retirer une signature manuellement ? Établissez un processus avec approbation des changements, audit à court terme et escalades RBAC temporaires. Automatisez l’export des audits pour une analyse forensique rapide. Protégez les points de signature par une authentification supplémentaire (p. ex. mTLS + Vault AppRole) et limitez les taux de signature par rôle.

Mise à l’échelle de l’ACME‑Proxy et contrôles de monitoring

Mettez à l’échelle les instances de proxy derrière un load‑balancer ; prévoyez une Redis/DB centrale pour les rate‑limits et l’état des requêtes. Mesurez la latence et les taux d’erreur séparément : une latence élevée lors de la signature indique des goulets d’étranglement côté backend (Vault CPU/HSM). Les alertes doivent, en plus des erreurs, signaler une densité de renouvellements accrue — un indicateur précoce de problèmes système ou de planification.

En résumé : investissez du temps dans les procédures de recovery, des plans de rollback clairs, des tests de rollover et des baselines de monitoring. Ce n’est qu’ainsi que votre automatisation PKI restera non seulement pratique, mais aussi fiable en exploitation, auditable et évolutive.

Les timers systemd et la gestion des certificats sont également importants pour ce sujet. Le présent article met ces aspects en perspective de manière compréhensible et montre ce qui importe au quotidien.