Creazione e gestione delle catene di certificati

Una CA radice è un certificato autofirmato che funge da ancora di fiducia ultima. La chiave privata della CA radice deve essere conservata offline, su un sistema isolato dalla rete o in un HSM, perché la sua compromissione minerebbe l'intera PKI. "openssl req -x509 -new -nodes -key root_key.pem -sha256 -days 3650 -out root_cert.pem" genera un certificato radice autofirmato valido per 10 anni.

Le CA intermedie sono firmate dalla CA radice e vengono usate per l'emissione quotidiana dei certificati. Per prima cosa, generi la chiave intermedia e la CSR: "openssl req -new -key intermediate_key.pem -out intermediate.csr". Quindi la CA radice la firma: "openssl x509 -req -in intermediate.csr -CA root_cert.pem -CAkey root_key.pem -CAcreateserial -days 1825 -out intermediate_cert.pem".

I certificati delle entità finali (certificati foglia) sono firmati dalla CA intermedia per server o client specifici. Generi la chiave del server e la CSR con Subject Alternative Names (SAN), quindi firmi il certificato con la CA intermedia: "openssl x509 -req -in server.csr -CA intermediate_cert.pem -CAkey intermediate_key.pem -CAcreateserial -extensions v3_req -days 365 -out server_cert.pem".

La chiave privata della CA radice viene conservata offline e usata solo per firmare un numero ridotto di certificati di CA intermedie. L'emissione quotidiana dei certificati viene eseguita dalle CA intermedie online. Se una CA intermedia viene compromessa, è possibile revocarla e sostituirla senza compromettere la radice. La chiave radice rimane al sicuro perché non è mai stata esposta online.

Il comando "openssl ca" offre un flusso di lavoro per le CA più completo rispetto a "openssl x509 -req". Gestisce un database dei certificati (index.txt), assegna i numeri di serie a partire da un file seriale e gestisce la generazione delle CRL. Richiede un file di configurazione openssl.cnf appropriato, con sezioni specifiche per la CA che definiscono la policy dei certificati e i vincoli sulla lunghezza del percorso.

Un file completo della catena di certificati per un web server contiene il certificato dell'entità finale seguito dai certificati delle CA intermedie nell'ordine corretto, terminando subito prima della radice. I certificati radice non vengono inclusi perché i browser dispongono di archivi di certificati radice preinstallati. Ordine di concatenazione: "cat server_cert.pem intermediate_cert.pem > chain.pem". Un ordine errato causa errori durante l'handshake TLS.

"openssl verify -CAfile root_cert.pem -untrusted intermediate_cert.pem server_cert.pem" verifica l'intera catena. Il flag "-untrusted" fornisce i certificati intermedi che fanno parte della catena, ma non sono ancora considerati attendibili. Se la verifica ha esito positivo, l'output è "server_cert.pem: OK". Gli errori più comuni indicano certificati intermedi mancanti o certificati scaduti.

Tra i problemi frequenti delle catene di certificati vi sono: certificati intermedi mancanti (il server invia solo il certificato foglia), ordine di concatenazione errato (il certificato foglia deve essere il primo), certificato intermedio scaduto (facile da non notare poiché si monitora la scadenza del certificato foglia), certificati autofirmati non presenti nell'archivio di attendibilità e mancata corrispondenza del nome (il SAN del certificato non corrisponde al nome host). Tutti questi problemi sono diagnosticabili con "openssl s_client -showcerts".

PKCS#12 (.pfx o .p12) è un formato contenitore che raggruppa la chiave privata, il certificato dell'entità finale e i certificati intermedi in un unico file cifrato. Creazione: "openssl pkcs12 -export -out bundle.pfx -inkey server_key.pem -in server_cert.pem -certfile intermediate_cert.pem". È richiesto da IIS, .NET, dai keystore Java e da molte applicazioni aziendali.

PEM è ASCII codificato in base64, leggibile, supporta più oggetti in un singolo file ed è usato da Apache, nginx e dagli strumenti OpenSSL. DER è binario, contiene un solo oggetto per file ed è usato da Java (per le importazioni JKS), Android e alcuni strumenti aziendali. PKCS#12/PFX è un contenitore binario cifrato per più oggetti, usato da Windows e IIS. Prima della distribuzione, verifichi sempre quale formato è previsto dal sistema di destinazione.

Le CA moderne devono registrare tutti i certificati emessi nei log di Certificate Transparency (CT) prima della consegna. Quando si crea una CA privata per uso interno, la registrazione nei log CT non è richiesta. Tuttavia, i certificati esposti pubblicamente devono contenere Signed Certificate Timestamps (SCT) incorporati per essere considerati attendibili da Chrome. Le CA private possono adottare le proprie policy senza requisiti CT.

Le CA radice sono autofirmate, vengono conservate offline e firmano solo le CA intermedie. Le CA intermedie gestiscono l'emissione quotidiana. I file della catena contengono il certificato foglia seguito dai certificati intermedi, mentre la radice viene omessa. Verifichi la catena con "openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem". I contenitori PKCS#12 raggruppano chiave e certificati per Windows/Java. Un ordine errato della catena è una causa comune di errori durante la distribuzione, diagnosticabile con s_client -showcerts.