Internes PKI‑Renewal automatisieren: ACME, HashiCorp Vault und systemd‑timers integrieren

Einleitung: Internes PKI‑Renewal automatisieren ist für Betreiber und Administratoren essenziell, wenn viele interne TLS‑Zertifikate verwaltet werden — etwa für interne Dienste, IoT‑Gateways, VPNs oder Client‑Authentifikation. In diesem Beitrag zeige ich praxisnah, wie Sie ACME (Automated Certificate Management Environment — Protokoll zur automatisierten Zertifikatsausgabe) mit HashiCorp Vault (Vault — Geheimnisverwaltung und optionale PKI‑Signing‑Engine) koppeln und systemd‑timers (systemd‑Timers — moderner Scheduler auf Linux mit Journald‑Integration) einsetzen, damit Erneuerungen verlässlich geplant, ausgeführt und verteilt werden.

Warum Automatisierung des PKI‑Renewals nötig ist

Zertifikate laufen typischerweise zeitgleich bei hunderten Hosts ab. Manuelles Ersetzen ist fehleranfällig, verursacht Ausfälle und Audit‑Lücken. Automatisierung reduziert Aufwand, verringert Ausfallrisiken und stellt konsistente Sicherheitsprozesse sicher. Dennoch bleibt Governance zentral: Gültigkeitsdauer, Rollen, Audit‑Logs und Least‑Privilege‑Zugriffskonzepte müssen definiert sein, bevor Sie produktiv gehen.

Internes PKI‑Renewal automatisieren: Architekturüberblick

Die empfohlene Trennung besteht aus drei Schichten:

• Signatur‑Schicht: Vault als interne CA/Signer. Vaults PKI‑Engine signiert CSRs; Root‑Key bleibt idealerweise offline.
• Protokoll‑/Integrations‑Schicht: Ein ACME‑Proxy oder ACME‑kompatibler Frontend‑Service empfängt ACME Requests und übersetzt sie zu Vault‑Sign‑Calls.
• Operations‑Schicht: systemd‑timers auf Hosts oder zentralen Runnern planen und führen Renewal‑Jobs aus sowie verteilen und validieren Zertifikate.

Diese Trennung verbessert Sicherheit, Auditierbarkeit und Betriebsflexibilität: Signieren, Authentifizierung und Scheduling haben eigene Verantwortlichkeiten.

Designentscheidungen und Voraussetzungen

Wichtige Fragen vor dem Start:

• Root vs. Intermediate: Nutzen Sie Vault als Intermediate, signiert vom offline gehaltenen Root. Das minimiert Root‑Exposition.
• Laufzeit: Kürzere Laufzeiten (z. B. 90 Tage) erhöhen Sicherheit, erhöhen aber Renewal‑Frequenz und Last.
• Vertrauensverteilung: Sorgen Sie dafür, dass Clients das CA‑Bundle erhalten (via CM‑Tooling, Paket, MDM).
• Maschinenauthentifizierung: mTLS (z. B. mit Produktions‑Maschinen‑Zertifikaten) oder Vault AppRole sind übliche Muster — beide haben Vor‑ und Nachteile bezüglich Secret‑Handling und Lebensdauer.
• Observability und Audit: Aktivieren Sie Vault Audit Devices und sammeln Sie Proxy‑/Host‑Logs.

Implementationsmuster: Direktes Client‑Request vs. ACME‑Proxy

Zwei gängige Muster:

Direkter ACME‑Client auf Hosts

Clients (z. B. acme.sh, certbot) fordern Zertifikate selbst an. Vorteil: dezentral und robust; Nachteil: mehr Konfigurationsaufwand und komplexere Authentifizierung zu Vault.

ACME‑Proxy zentral

Ein zentraler Proxy validiert Requests, authentifiziert Hosts (mTLS, OAuth), und spricht mit Vault. Vorteil: zentrale Kontrolle, vereinfachtes Auditing; Nachteil: zusätzlicher Netzwerkpfad und Verfügbarkeitsanforderungen.

Konkreter Setup: Vault PKI, ACME‑Proxy, systemd‑timers

Die Kernschritte sind:

1. Vault PKI Engine einrichten und Intermediate konfigurieren.
2. ACME‑Proxy implementieren (z. B. mit lego oder einer leichten Go‑Service‑Komponente), die Requests authentifiziert und an Vault mappt.
3. systemd‑timer Units erstellen, die Renewal‑Skripte periodisch ausführen, Zertifikate prüfen und Services reloaden.

Vault PKI: Beispielbefehle

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 trennt dadurch Root und Intermediate, was eine sichere Schlüsselverwaltung ermöglicht. Falls Signaturen fehlschlagen: prüfen Sie Vault‑Token‑Berechtigungen, Audit‑Logs und TTL‑Einstellungen.

ACME‑Proxy: Aufgaben und Mapping

Der Proxy sollte:

• Hosts authentifizieren (mTLS oder Token).
• Werte wie CN/SAN gegenüber erlaubten Patterns prüfen.
• Requests einer Vault‑Role zuordnen und signieren lassen.
• Rate‑Limiting und Audit erzeugen.

Beispiel 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: zuverlässiges Scheduling

Systemd‑timers bieten RandomizedDelaySec, Journald‑Integration, Persistent=true (führt Jobs nach Systemausfall nach) und bessere Steuerbarkeit als cron. Beispiel 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

Das Skript selbst sollte atomar arbeiten: Lockfile, temporäres Verzeichnis und saubere Fehlercodes. Beispiel skeleton:

#!/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

Praxisbeispiel: Vault‑Policy und ACME‑Role

Policies begrenzen, welche Rollen welche SANs/CNs signieren dürfen. Beispiel 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"]
}

Die Rolle selbst definiert SAN‑Pattern und TTL:

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

Ist die Policy zu offen, droht Missbrauch; ist sie zu restriktiv, bricht Automation. Testen Sie iterativ in Staging.

Deployment und atomare Installation von Zertifikaten

Ein häufiger Betriebsfehler ist eine inkonsistente Zertifikatsinstallation, bei der Files halbgeschrieben sind und Services mit unvollständigen Dateien neu starten. Verwenden Sie atomare Muster: schreiben Sie neue Artefakte an temporären Pfad, validieren Sie die Datei und tauschen Sie per symlink. So ist ein konsistentes Dateisystembild möglich und Rollback einfach.

# atomare Installation
TMPDIR=/tmp/new-cert-$$
mkdir -m 700 "$TMPDIR"
cp cert.pem "$TMPDIR/"
cp key.pem "$TMPDIR/"
# Validieren
openssl x509 -noout -text -in "$TMPDIR/cert.pem" >/dev/null
# Atomisch tauschen
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.
• Dateirechte/SELinux: Services können Zertifikate nicht lesen, obwohl sie vorhanden sind.
• Katalogisierung der Zuständigkeiten: Wer darf kurzfristig manuell signieren? Klare Rollen verhindern unautorisierte Aktionen.
• Rate‑Limits: Testen Sie gegen Staging‑Proxy, damit Produktion nicht plötzlich blockiert ist.

Fazit

Internes PKI‑Renewal automatisieren reduziert Betriebsaufwand und Ausfallrisiken, verlangt aber eine saubere Architektur, RBAC‑Policies, Observability und definierte Notfallwege. Die Kombination von HashiCorp Vault als Signer, einem ACME‑proxy als Protokollbrücke und systemd‑timers als Scheduler ist praxisbewährt: Sie trennt Verantwortlichkeiten, erleichtert Audit und skaliert, wenn Sie Rate‑Limits und Staggering beachten. Testen Sie in Staging, führen Sie Chaos‑Checks durch und dokumentieren Sie Runbooks — so bleibt Ihr Renewal‑System kontrollierbar und ausfallsicher.

Betriebssicherheit, Recovery und Skalierung — praxisnahe Ergänzungen

Beim produktiven Betrieb eines automatisierten PKI‑Renewal‑Stacks entscheiden nicht nur Konfigurationen über Erfolg, sondern auch Betriebsprozesse und Ausfallszenarien. Nachfolgend finden Sie konkrete Hinweise zu Backup/Recovery, Hochverfügbarkeit, Rollover‑Prozessen und Schutz gegen Missbrauch — alles mit Blick auf Admins und IT‑Entscheider.

Vault‑Backup, Unseal und Auto‑Unseal‑Strategien

Sichern Sie nicht nur Datenbank‑Backups, sondern vor allem die Unseal‑Materialien: Shamir‑Shares, HSM‑Keys oder Cloud‑KMS‑Konfigurationen. Bei Nutzung von Shamir müssen Sie Recovery‑Shops und Rollen definieren (wer hat Zugriff auf wie viele Shares). Auto‑Unseal über Cloud‑KMS oder HSM reduziert manuellen Aufwand bei Neustarts, schafft aber neue Abhängigkeits‑Risiken: Lagern Sie KMS‑Zugriffsrechte strikt und führen Sie Zugriffsprotokolle (Audit) für Unseal‑Events.

HA, Replikation und regionaler Ausfall

Vault im HA‑Modus (Integrated Storage oder konsistenter Backend wie Consul) erlaubt Read/Write‑Replikation. Entscheiden Sie, ob Sie aktive‑aktive oder aktive‑passive Replikation brauchen. Für ACME‑Proxy empfiehlt sich horizontales Scaling mit Sticky‑Sessions oder zentraler Persistenz für Rate‑Limit‑Zähler, damit ein Failover keine Double‑Requests erzeugt. Testen Sie Cross‑DC‑Failover: schalten Sie eine Region aus, validieren Sie Signierlatenzen und ob Auto‑Unseal greift.

Key/CA‑Rollover und Kompatibilität

Ein geplanter Rollover der Intermediate‑CA ist ein normaler, aber kritischer Vorgang. Führen Sie den Rollover schrittweise: präparieren Sie neues Intermediate, signieren Sie es mit gerootetem Root, verteilen Sie neue CA‑Bundles parallel und setzen Sie längere Overlap‑Zeiten, damit Clients beide Chains akzeptieren. Dokumentieren Sie die Rückfallszenarien: wie man auf altes Intermediate zurücksetzt, falls Clients inkompatibel sind.

Revocation, CRL und OCSP‑Design

Entscheiden Sie früh, ob Sie CRLs, OCSP oder beides einsetzen. CRLs sind einfach zu implementieren, aber skalieren schlecht; OCSP ist online‑fähig, benötigt aber latenzarmes, hochverfügbares Responder‑Infrastructure. Für interne Netze kann ein leichtgewichtiger OCSP‑Responder in Front der Vault‑PKI dienen; stellen Sie sicher, dass Clients korrekt konfigurierte CRL/OCSP‑URLs erhalten und testen Sie Offline‑Szenarien, wenn Responder nicht erreichbar sind.

Notfallprozesse und minimaler Zugriff

Definieren Sie klar: Wer darf im Notfall manuell signieren/unsign? Legen Sie einen Prozess mit Change‑Approval, Kurzfrist‑Auditing und temporären RBAC‑Eskalationen fest. Automatisieren Sie Audit‑Export für schnelle Forensik. Schützen Sie Signierendpunkte mit zusätzlicher Authentifizierung (z. B. mTLS + Vault AppRole) und begrenzen Sie Signier‑Raten pro Rolle.

Skalierung des ACME‑Proxys und Monitoring‑Checks

Skalieren Sie Proxy‑Instanzen hinter einem Load‑Balancer; halten Sie eine zentrale Redis/DB für Rate‑Limits und Request‑State bereit. Messen Sie Latenz und Fehlerquoten separat: hohe Latenz beim Signieren deutet auf Backend‑Bottlenecks (Vault CPU/HSM) hin. Alerts sollten neben Fehlern auch erhöhte Renewal‑Dichte melden — ein Frühindikator für System‑ oder Planungsfehler.

Zusammenfassend: Investieren Sie Zeit in Recovery‑Prozeduren, klare Rollback‑Pläne, Rollover‑Tests und Monitoring‑Baselines. Nur so bleibt Ihre PKI‑Automatisierung nicht nur bequem, sondern auch betriebssicher, auditfähig und skalierbar.

Für dieses Thema sind auch Systemd-Timers und Zertifikatsmanagement wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.