Automatizzare il rinnovo della PKI interna: integrare ACME, HashiCorp Vault e systemd-timers

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.

Perché è necessaria l’automazione del rinnovo PKI

I certificati scadono tipicamente in contemporanea su centinaia di host. La sostituzione manuale è soggetta a errori, provoca interruzioni e lascia lacune nell’audit. L’automazione riduce il carico operativo, diminuisce i rischi di downtime e garantisce processi di sicurezza coerenti. Rimane però centrale la governance: durata di validità, ruoli, log di audit e concetti di accesso secondo il principio del minimo privilegio devono essere definiti prima della messa in produzione.

Automatizzare il rinnovo PKI interno: panoramica architetturale

La separazione raccomandata è composta da tre livelli:

• Livello di firma: Vault come CA/Signer interna. La PKI‑Engine di Vault firma le CSR; la Root‑Key rimane idealmente offline.
• Livello protocollo/integrazione: un ACME‑proxy o servizio front-end compatibile ACME riceve le richieste ACME e le traduce in chiamate di firma a Vault.
• Livello operazioni: systemd‑timers su host o runner centrali pianificano ed eseguono job di rinnovo, distribuiscono e convalidano i certificati.

Questa separazione migliora la sicurezza, l’auditabilità e la flessibilità operativa: firma, autenticazione e scheduling hanno responsabilità distinte.

Decisioni di design e prerequisiti

Domande importanti prima di iniziare:

• Root vs. Intermediate: usate Vault come Intermediate, firmato dal Root mantenuto offline. Questo minimizza l’esposizione della Root.
• Durata: durate più brevi (es. 90 giorni) aumentano la sicurezza, ma incrementano la frequenza dei rinnovi e il carico.
• Distribuzione della fiducia: assicuratevi che i client ricevano il CA‑bundle (tramite CM‑tooling, pacchetto, MDM).
• Autenticazione delle macchine: mTLS (es. con certificati macchina di produzione) o Vault AppRole sono pattern comuni — entrambi hanno vantaggi e svantaggi in termini di gestione dei segreti e durata.
• Observability e audit: attivate i Vault Audit Devices e raccogliete i log del proxy/degli host.

Pattern di implementazione: richiesta diretta del client vs. ACME‑proxy

Due pattern comuni:

ACME client diretto sugli host

I client (es. acme.sh, certbot) richiedono i certificati autonomamente. Vantaggio: decentralizzato e robusto; svantaggio: maggiore sforzo di configurazione e autenticazione più complessa verso Vault.

ACME‑proxy centrale

Un proxy centrale convalida le richieste, autentica gli host (mTLS, OAuth) e comunica con Vault. Vantaggio: controllo centrale, audit semplificato; svantaggio: percorso di rete aggiuntivo e requisiti di disponibilità.

Configurazione concreta: Vault PKI, ACME‑proxy, systemd‑timers

I passaggi chiave sono:

1. Configurare la PKI Engine di Vault e impostare l’Intermediate.
2. Implementare l’ACME‑proxy (es. con lego o un leggero componente Go), che autentica le richieste e le mappa verso Vault.
3. Creare unità systemd‑timer che eseguono periodicamente script di rinnovo, verificano i certificati e ricaricano i servizi.

Vault PKI: comandi di esempio

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 separa così Root e Intermediate, consentendo una gestione sicura delle chiavi. Se le firme falliscono: verificare i permessi dei token di Vault, i log di audit e le impostazioni TTL.

ACME‑Proxy: Aufgaben und Mapping

Il proxy dovrebbe:

• Autenticare gli host (mTLS o token).
• Verificare valori come CN/SAN rispetto ai pattern consentiti.
• Associare le richieste a una Vault‑Role e farle firmare.
• Implementare rate‑limiting e audit.

Esempio di mapping YAML:

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: pianificazione affidabile

I systemd‑timer offrono RandomizedDelaySec, integrazione con Journald, Persistent=true (esegue i job dopo un’interruzione di sistema) e maggiore controllabilità rispetto a cron. Esempio 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

Lo script stesso dovrebbe operare in modo atomico: lockfile, directory temporanea e codici di errore chiari. Esempio di scheletro:

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

Esempio pratico: Vault‑Policy e ACME‑Role

Le policy limitano quali ruoli possono firmare quali SAN/CN. Esempio di 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"]
}

Il ruolo definisce pattern SAN e TTL:

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

Se la policy è troppo permissiva, c’è rischio di abuso; se è troppo RESTrittiva, l’automazione si interrompe. Eseguire test iterativi in staging.

Deployment e installazione atomica dei certificati

Un errore operativo comune è un’installazione inconsistente dei certificati, in cui i file vengono scritti solo parzialmente e i servizi vengono riavviati con file incompleti. Usare schemi atomici: scrivere i nuovi artefatti in un percorso temporaneo, convalidare il file e scambiare tramite symlink. In questo modo si ottiene un’immagine del filesystem consistente e il rollback è semplice.

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

Su Windows o in ambienti containerizzati ricorrete a meccanismi appropriati: p. es. PKCS#12‑Bundles per IIS/Windows o mount‑overlays per container.

HSM, TPM e Vault Transit: non esportare mai le chiavi

Per chiavi particolarmente sensibili utilizzate HSM (Hardware Security Module — store di chiavi dedicati e certificati) o TPM (Trusted Platform Module — root of trust legato alla scheda madre). La Transit Engine di Vault consente di firmare/verificare senza esportare le chiavi private. Sequenza operativa: root nell’HSM, Vault configura Transit come signer, i certificati intermedi vengono generati e firmati tramite Transit, i client ricevono solo i certificati.

Container e Kubernetes: particolarità

In ambienti cloud e container si applicano vincoli aggiuntivi: i filesystem sono effimeri, gli Init‑Containers possono fornire i certificati prima dell’avvio. I cluster Kubernetes usano spesso Secrets; qui dovRESTe cifrare i Secrets (p. es. Sealed Secrets) e gestire i rollout tramite Deployment con readiness‑probes. PRESTate attenzione ai privilegi dei kubelet: non devono avere accesso illimitato ai percorsi di firma.

Dettagli di monitoraggio e metriche

Costruite le metriche in modo granulare: pki_renew_requests_total, pki_renew_success_total, pki_renew_failures_total, pki_cert_age_seconds oltre a gauge lato exporter per i giorni rimanenti fino alla scadenza. Gli alert non dovrebbero monitorare solo le percentuali di errore, ma anche gli aumenti della latenza di renew — un indicatore di problemi di performance sul proxy.

Chaos‑Tests, controlli di staging e validazione

Testate la resilienza: simulate guasti di Vault, partizioni di rete e colpi ai rate limit. Eseguite canaries prima di cambiare globalmente: un piccolo gruppo di host riceve il nuovo CA‑bundle, p. es. tramite playbook Ansible. Usate test sintetici end‑to‑end che verifichino un TLS‑handshake prima e dopo il rinnovo.

Runbook operativo: procedura passo‑passo per errori di rinnovo

1. Verificare l’ora di sistema: timedatectl status — il drift dell’orologio rompe TLS.
2. Stato di Vault e audit: vault status e consultare i log di audit.
3. Log del proxy: controllare 401/403 (auth), 429 (rate limit) e 5xx (errori server).
4. Controllare lo script host: Lockfiles, SELinux‑Kontext, binari mancanti, permessi.
5. Eseguire una richiesta manuale tramite Staging‑ACME per identificare problemi di percorso.

Esempio: script robusto di rinnovo con flock e 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
'"

I codici di uscita aiutano gli strumenti di alerting ad assegnare cause univoche. Non dimenticate la rotazione dei log.

Insidie tipiche e precauzioni

• Ora/Fuso orario: TLS dipende dal tempo; differenze nell’orologio di sistema provocano errori di validazione.
• Permessi dei file/SELinux: i servizi non riescono a leggere i certificati, pur essendo presenti.
• Catalogazione delle responsabilità: chi può firmare manualmente a breve termine? Ruoli chiari prevengono azioni non autorizzate.
• Rate‑Limits: testate contro un proxy di staging, in modo che la produzione non venga improvvisamente bloccata.

Fazit

L’automatizzazione interna del PKI‑Renewal riduce il carico operativo e i rischi di interruzione, ma richiede un’architettura pulita, policy RBAC, osservabilità e percorsi di emergenza definiti. La combinazione di HashiCorp Vault come signer, un ACME‑proxy come ponte di protocollo e systemd‑timers come scheduler è comprovata in pratica: separa le responsabilità, facilita l’audit e scala, se si tiene conto dei Rate‑Limits e dello staggering. Testate in staging, eseguite Chaos‑Checks e documentate i runbook — così il vostro sistema di rinnovo resta controllabile e resistente ai guasti.

Sicurezza operativa, recovery e scalabilità — integrazioni pratiche

Nell’esercizio produttivo di uno stack automatizzato per il PKI‑Renewal non decidono solo le configurazioni, ma anche i processi operativi e gli scenari di guasto. Di seguito trovate indicazioni concrete su backup/recovery, alta disponibilità, processi di rollover e protezione contro l’abuso — tutto con lo sguardo rivolto ad amministratori e decisori IT.

Vault‑Backup, Unseal und Auto‑Unseal‑Strategien

Non salvate solo i backup del database, ma soprattutto i materiali per l’Unseal: Shamir‑Shares, HSM‑Keys o le configurazioni Cloud‑KMS. Se usate Shamir, dovete definire Recovery‑Shops e ruoli (chi ha accesso a quante shares). L’Auto‑Unseal tramite Cloud‑KMS o HSM riduce il lavoro manuale ai riavvii, ma introduce nuovi rischi di dipendenza: gestite rigorosamente i diritti di accesso al KMS e mantenete registri di accesso (audit) per gli eventi di Unseal.

HA, Replikation und regionaler Ausfall

Vault in modalità HA (Integrated Storage o backend coerente come Consul) permette la replica Read/Write. Decidete se vi serve replica active‑active o active‑passive. Per l’ACME‑Proxy è consigliabile lo scaling orizzontale con Sticky‑Sessions o una persistenza centrale per i contatori dei rate‑limit, in modo che un failover non generi double‑requests. Testate il Cross‑DC‑Failover: disattivate una regione, validate le latenze di firma e verificate se l’Auto‑Unseal interviene.

Key/CA‑Rollover und Kompatibilität

Un rollover pianificato della Intermediate‑CA è un’operazione normale ma critica. Eseguite il rollover in passi: preparate la nuova Intermediate, firmatela con il Root radicato, distribuite i nuovi CA‑Bundle in parallelo e prevedete tempi di overlap estesi, così che i client accettino entrambe le chain. Documentate gli scenari di rollback: come tornare alla intermediate precedente se i client risultano incompatibili.

Revocation, CRL und OCSP‑Design

Decidete per tempo se impiegare CRL, OCSP o entrambi. Le CRL sono facili da implementare, ma scalano male; OCSP è online‑capable ma richiede responder a bassa latenza e alta disponibilità. Per le reti interne un OCSP‑Responder leggero davanti alla Vault‑PKI può essere adeguato; assicuratevi che i client ricevano URL CRL/OCSP correttamente configurate e testate scenari offline quando i responder non sono raggiungibili.

Notfallprozesse und minimaler Zugriff

Definite chiaramente: chi è autorizzato a firmare/annullare la firma manualmente in caso di emergenza? Stabilite un processo con Change‑Approval, audit a breve termine e escalation RBAC temporanee. Automatizzate l’export degli audit per una rapida analisi forense. Proteggete i punti di firma con autenticazione aggiuntiva (es. mTLS + Vault AppRole) e limitate le rate di firma per ruolo.

Scalabilità del proxy ACME e controlli di monitoraggio

Scalate le istanze del proxy dietro un load‑balancer; predisponete un Redis/DB centrale per i rate‑limit e lo stato delle richieste. Misurate latenza e tassi di errore separatamente: un’elevata latenza durante la firma indica colli di bottiglia nel backend (CPU di Vault/HSM). Gli alert dovrebbero segnalare, oltre agli errori, anche un aumento della densità dei renewal — un indicatore precoce di problemi di sistema o di pianificazione.

In sintesi: investite tempo in procedure di recovery, piani di rollback chiari, test di rollover e baseline di monitoraggio. Solo così la vostra automazione PKI resterà non solo comoda, ma anche operativamente sicura, auditabile e scalabile.

Per questo ambito sono importanti anche i Systemd-Timers e la gestione dei certificati. Il contributo colloca questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.