Gestire una PKI privata: configurare OpenSSL e CFSSL, CRL/OCSP e integrazione HSM

In questo articolo spiego come gestire una Private PKI — ossia una Public Key Infrastructure (PKI) interna che emette e gestisce certificati X.509. Una PKI è centrale per TLS, code‑signing, autenticazione client e accessi VPN. Tratto aspetti pratici: scelta OpenSSL vs. CFSSL, architettura CA, CRL (Certificate Revocation List) e OCSP (Online Certificate Status Protocol) per il controllo delle revoche, nonché integrazione HSM tramite PKCS#11. Il pubblico di riferimento sono amministratori, system engineers e operatori: perciò il focus è su esercizio, rischi, procedure di verifica, troubleshooting e strategie di fallback.

Perché gestire una PKI privata?

Una PKI privata fornisce controllo sulle regole di emissione, sulle durate e sul materiale chiave. Diversamente dalle CA pubbliche, è pensata per certificati interni che non sono presenti nel root store del browser. Ciò consente durate brevi, roll‑out automatizzati e un’applicazione rigorosa delle policy. I rischi però sono maggiori: compromissione della chiave root, configurazione di revoca errata o automazione insufficiente possono mettere a rischio disponibilità e sicurezza.

Decisioni architetturali fondamentali

Prima della messa in opera è necessario chiarire le questioni architetturali. Determinanti sono la gerarchia delle CA, il grado di automazione, la custodia delle chiavi e la strategia di revoca.

Topologia CA: Root, Sub‑CA, Issuing

La best practice è una gerarchia a più livelli: una Root‑CA mantenuta offline (Root‑Key, massimo anello di fiducia) e una o più Sub‑CA online (Issuing CAs) che firmano i certificati attivi. Questa separazione riduce il rischio: una Issuing CA compromessa è più contenibile; la chiave root rimane al sicuro offline per periodi più lunghi.

Scelta del software: OpenSSL vs. CFSSL (vs. Vault)

OpenSSL è un toolkit flessibile e adattabile; adatto per PKI semplici o a basso volume o per workflow controllati dall’amministratore. CFSSL (CloudFlare SSL) è un server PKI specializzato con REST API, configurazione JSON e automazione integrata. HashiCorp Vault offre inoltre un modello simile a KMS con certificati dinamici e policy. Scegliete in base ai requisiti:

• OpenSSL: controllo completo, script, ma maggiore sviluppo interno per API e automazione.
• CFSSL: pronto per API, percorsi di automazione più semplici, adatto per DevOps/CI interni.
• Vault: forte funzionalità di gestione delle policy e dei secret; sensato se Vault è già in uso.

Prerequisiti e principi di sicurezza

Prima dell’implementazione servono policy chiare: dimensioni delle chiavi (2048/3072/4096 RSA o ECDSA P‑256/P‑384), durate, processi di renewal, audit‑logging e ruoli (p.es. CA‑officer, auditor). L’HSM (Hardware Security Module) protegge le chiavi private contro l’estrazione; PKCS#11 è l’API standard a tale scopo. Definite piani di backup e recovery per il materiale chiave e le banche dati della CA.

Linee guida: Certificate Policy (CP) e Certification Practice Statement (CPS)

CP/CPS sono regole documentate che disciplinano emissione, utilizzo e revoca. Anche se interne, questi documenti sono essenziali per la chiarezza operativa e come riferimento negli audit.

Passo‑per‑passo: Root e Sub‑CA OpenSSL (esempio breve)

Questo esempio mostra il minimo: generare la Root CA offline, una Sub‑CA per la firma operativa. Nota: OpenSSL si configura tramite file di config (scopo: estensioni, percorsi). Gli errori più comuni sono permessi errati o la mancanza dei file serial/index.

Generare la Root CA (offline):

# Root private key (offline, auf HSM empfohlen) und self-signed cert (10 Jahre)
openssl genpkey -algorithm RSA -out root.key.pem -pkeyopt rsa_keygen_bits:4096
openssl req -x509 -new -nodes -key root.key.pem -sha256 -days 3650 -out root.cert.pem -subj "/C=DE/O=ACME/OU=PKI Root/CN=ACME Root CA"

Generare Sub‑CA e firmarla con il Root (Sub‑CA online):

openssl genpkey -algorithm RSA -out subca.key.pem -pkeyopt rsa_keygen_bits:4096
openssl req -new -key subca.key.pem -out subca.csr.pem -subj "/C=DE/O=ACME/OU=PKI SubCA/CN=ACME SubCA"
openssl x509 -req -in subca.csr.pem -CA root.cert.pem -CAkey root.key.pem -CAcreateserial -out subca.cert.pem -days 1825 -sha256 -extensions v3_ca -extfile /etc/ssl/openssl.cnf

Insidie tipiche: copiando le chiavi Root sul sistema online si compromette il Root. Meglio un flusso di firma: firmare la CSR offline e trasferire online solo il certificato della Sub‑CA.

Integrazione HSM: perché e come (PKCS#11)

Gli HSM proteggono fisicamente le chiavi private e impediscono la loro semplice esportazione. PKCS#11 è un’API indipendente dalla piattaforma con cui il software comunica con gli HSM. SoftHSM è un’implementazione software di PKCS#11 per i test; i Cloud‑HSM (AWS, Azure, Google) offrono HSM gestiti con procedure di integrazione proprie.

SoftHSM per test

SoftHSM è utile per i test; non sostituisce un HSM produttivo certificato FIPS. Per creare una chiave in SoftHSM:

# Initialisierung (Beispiel mit SoftHSM2)
softhsm2-util --init-token --slot 0 --label "test-token" --pin 1234 --so-pin 5678
# Import eines RSA-Schlüssels (PKCS#12) in SoftHSM
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so -l --pin 1234 --import mykey.p12 --type private

Negli ambienti di produzione configurate il vostro software CA (OpenSSL, CFSSL, Vault) in modo che le chiavi private restino tramite PKCS#11 e le operazioni di firma siano eseguite nell’HSM. OpenSSL richiede, per esempio, un engine PKCS#11 o la configurazione p11tool/engine_pkcs11.

# Beispiel: OpenSSL mit engine_pkcs11 (vereinfacht)
openssl engine dynamic -pre SO_PATH:/usr/lib/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD

Errori comuni: ID di slot/token errati, timeout del PIN, ACL sull’HSM. Automatizzate i test in loop come i flussi di firma e di sottoscrizione prima di andare in produzione.

Revoca: CRL e OCSP in esercizio

La revoca è critica: la CRL (Certificate Revocation List) è un elenco di numeri di serie revocati; i client la scaricano periodicamente. OCSP consente la verifica online dello stato di singoli certificati. Entrambe hanno vantaggi e svantaggi:

• CRL: semplice, scalabile tramite CDN/HTTP, ma l’elenco può diventare grande e i client devono scaricare aggiornamenti regolari.
• OCSP: stato in tempo reale, basso trasferimento dati per richiesta, ma richiede un OCSP‑Responder affidabile (alta disponibilità) e risposte firmate (certificato dell’OCSP‑Responder o OCSP stapling per TLS).

Per le PKI interne spesso è sensata una combinazione: la CA di emissione pubblica le CRL periodicamente (es. ogni 12 ore) e gestisce un OCSP‑Responder per bassa latenza e verifiche online immediate.

Creare una CRL con OpenSSL

# CRL erstellen (angenommen index.txt und serial vorhanden)
openssl ca -config openssl.cnf -gencrl -out crl.pem
# CRL in DER für HTTP-Distribution konvertieren
openssl crl -in crl.pem -outform DER -out crl.der

Importante: i webserver, i CDN o i fileserver devono fornire le CRL con header di cache coerenti. Verificate che i client seguano correttamente l’URL del CRL‑Distribution‑Point (CDP) presente nel certificato.

OCSP‑Responder (Esempio con OpenSSL)

# OCSP responder starten (vereinfacht, für Tests)
openssl ocsp -index index.txt -port 2560 -rsigner ocsp.cert.pem -rkey ocsp.key.pem -CA root.cert.pem -text

In produzione utilizzate responder OCSP specializzati (p. es. da CFSSL, EJBCA o appliance commerciali) e assicurate alta disponibilità (load balancer, Anycast). OCSP‑Stapling (TLS‑Registration del relativo stato OCSP) riduce le interrogazioni lato client.

CFSSL: REST‑API und Automatisierung

CFSSL offre API per le richieste di firma e la gestione di CRL/OCSP. Tipiche sono JSON‑policy e un deployment semplice in Docker/Kubernetes. CFSSL è adatto se desiderate integrare l’emissione automatizzata di certificati in pipeline CI/CD o processi di provisioning.

{
  "signing":{
    "default":{
      "expiry":"8760h"
    },
    "profiles":{
      "server":{
        "expiry":"720h",
        "usages":["signing","key encipherment","server auth"]
      }
    }
  }
}

CFSSL è più semplice da gestire per i client REST rispetto a script job OpenSSL; prestate attenzione all’autenticazione dell’API (mTLS, token) e ai rate‑limit, altrimenti un account compromesso può generare certificati in massa.

Operazioni, monitoraggio e audit

Essenziali sono i log di audit (chi ha richiesto/approvato un certificato), il monitoraggio (stato di salute del servizio CA, tempi di risposta OCSP, stato di pubblicazione delle CRL), il backup dei database CA (index.txt, serial) e test regolari di ripristino. Prevedete allertamento in caso di errori: pubblicazioni CRL fallite, OCSP‑Responder inattivo o errori di comunicazione con l’HSM.

Audit e integrità dei log

Integrità dei log significa: i log devono essere verificabili. Firmate i log di audit o archiviateli in modalità append‑only su un servizio di log esterno. Senza log verificabili, la ricostruzione durante l’incident response è problematica.

Risoluzione dei problemi: insidie tipiche

Ecco le cause più frequenti e le sequenze di verifica:

1. Data/ora del client errata: verificate NTP; certificati scaduti o campi NotBefore/NotAfter non validi causano errori TLS.
2. CRL/OCSP non raggiungibili: testate l’URL CDP nel certificato e l’URL OCSP; verificate la raggiungibilità HTTP(S) e i firewall.
3. PIN/Lifecycle HSM: blocco del PIN o blocco dovuto ad autenticazioni fallite; verificate lo stato del token e i log dell’HSM.
4. Catena mancante: il server fornisce solo il certificato End‑Entity, ma non la Sub‑CA; verificate la configurazione della TLS Chain sui webserver o sui provisioner.
5. Incoerenze di formato: PEM vs DER; molti strumenti richiedono formati espliciti.

Passaggi di verifica di esempio

# Prüfen des Zertifikatspfads und CRL/OCSP URLs
openssl x509 -in service.cert.pem -text -noout | sed -n '/X509v3 CRL/D, /Authority Information Access/ p'

# OCSP-Abfrage eines spezifischen Zertifikats (Testumgebung)
openssl ocsp -issuer subca.cert.pem -cert service.cert.pem -url http://ocsp.example.local:2560 -text -resp_text

Automatisierung und Lebenszyklusmanagement

Automazione riduce gli errori umani nel rinnovo/revoca. Per ambienti interni ci sono due vie tipiche: CA interna compatibile ACME (es. cfssl+acme‑bridge o soluzioni tipo Boulder) oppure automazione basata su API tramite CFSSL/Vault. ACME è un protocollo che permette ai client di richiedere e rinnovare automaticamente certificati; qui è importante l’autenticazione dei client (HTTP‑01 interno, DNS‑01 o mTLS).

Aspetti importanti nel ciclo di vita:

• Notifica automatica prima della scadenza (es. 30/7/1 giorni).
• Rinnovo zero‑touch per server e load balancer tramite hook/agent.
• Test automatici dopo il rinnovo: verifica della catena e OCSP‑stapling.

# Beispiel: Ansible Task (vereinfachte Darstellung) um CRL zu verteilen
- name: Upload CRL to webserver
  copy:
    src: /var/pki/crl/crl.der
    dest: /srv/www/ssl/crl/crl.der
    owner: root
    mode: '0644'
  notify: RESTart nginx

- name: RESTart nginx
  service:
    name: nginx
    state: RESTarted

Client‑Trust‑Verteilung und Bereitstellung

È fondamentale che tutti i client e i sistemi rilevanti si fidino del Root e degli intermedi interni. Vie tipiche di distribuzione:

• Windows: GPO distribuisce il certificato Root in Trusted Root Certification Authorities.
• Linux/Servers: bundle CA centrale in /etc/pki/ca‑trust/source/anchors ed eseguire update‑ca‑trust.
• Dispositivi mobili/endpoint: MDM (Mobile Device Management) o installazione manuale per dispositivi gestiti.

Testate il rollout a fasi e verificate che i client, dopo la distribuzione, stabiliscano correttamente connessioni TLS e verifichino OCSP/CRL.

Skalierung, Performance und Hochverfügbarkeit

La scalabilità riguarda soprattutto OCSP e la distribuzione delle CRL. Gli OCSP responder devono garantire bassa latenza; misure consuete:

• Caching OCSP (responder e load balancer) e Anycast per la distribuzione geografica.
• CDN per la fornitura delle CRL con appropriati header Cache‑Control e TTL.
• Monitoraggio dei tempi di risposta e delle percentuali di errore; failover automatico del responder.

# Beispiel: Prometheus Alert (vereinfachtes Beispiel)
- alert: OCSPResponderDown
  expr: probe_success{job="ocsp_probe"} == 0
  for: 2m
  labels:
    severity: critical
  annotations:
    summary: "OCSP Responder nicht erreichbar"
    description: "OCSP Responder {{ $labels.instance }} antwortet nicht."

Disaster Recovery und Incident‑Runbook

Preparate un runbook chiaro per gli incidenti. Passi importanti in caso di compromissione del Root/CA o guasto HSM:

1. Isolate i sistemi interessati e preservate le evidenze (log). Documentate i timestamp.
2. Revocate i certificati compromessi e pubblicate immediatamente un aggiornamento CRL e lo stato OCSP „revoked“.
3. Se il Root è compromesso: piano per cross‑sign o ricostruzione della PKI con rollout parallelo di nuove Root/Sub‑CA; informate i team coinvolti.
4. Testate il ripristino dai backup, incluso l’import HSM o le procedure per HSM sostitutivi.

Esercitazioni DR regolari (almeno annuali) sono obbligatorie: testate per iscritto i passi di ripristino ed eseguite una validazione end‑to‑end.

Praktische Prüf‑Commands & Beispiele

Alcune verifiche utili che dovRESTe integrare regolarmente nei vostri runbook:

# Zertifikatspfadprüfung
openssl verify -CAfile chain.pem service.cert.pem

# CRL herunterladen und prüfen
curl -sS -o crl.der http://crl.example.local/crl.der
openssl crl -in crl.der -inform DER -text -noout

# OCSP Testabfrage einer Produktions-URL
openssl ocsp -issuer subca.cert.pem -cert service.cert.pem -url http://ocsp.example.local:2560 -header "HOST" "ocsp.example.local" -resp_text

# HSM Slot/Token-Status (pkcs11-tool)
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so -L
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so -T

Conclusione

Gestire una PKI privata richiede più che emettere certificati: politiche chiare, conservazione sicura delle chiavi (idealmente HSM), automazione per emissione/rinnovo/revoca, monitoraggio e procedure di ripristino testate. OpenSSL offre il massimo controllo, CFSSL facilita l’automazione basata su API. CRL e OCSP si completano in robustezza e tempi di reazione. Testate i workflow HSM, verificate automaticamente la raggiungibilità di CRL/OCSP e mantenete un runbook scritto per rotazione e gestione degli incidenti. Una PKI ben documentata minimizza i rischi operativi e mantiene affidabilmente in funzione le vostre dipendenze TLS interne.

Risorse e link interni

Per integrazioni più profonde consultate la documentazione degli strumenti: CFSSL, OpenSSL Engine PKCS#11, SoftHSM e le specifiche del vendor HSM. Pianificate inoltre un audit delle policy PKI e prove regolari di RESTore, analoghe ai test di recovery dei backup in altri sistemi critici.

Per questo argomento sono importanti anche l’integrazione OpenSSL PKI e HSM. L’articolo colloca questi aspetti in modo chiaro e mostra cosa conta nella pratica quotidiana.