{"id":85,"date":"2026-06-12T16:37:22","date_gmt":"2026-06-12T16:37:22","guid":{"rendered":"https:\/\/shattered.io\/it\/2026\/06\/12\/openssl-certificati-chiavi\/"},"modified":"2026-06-12T20:22:13","modified_gmt":"2026-06-12T20:22:13","slug":"openssl-certificati-chiavi","status":"publish","type":"post","link":"https:\/\/shattered.io\/it\/2026\/06\/12\/openssl-certificati-chiavi\/","title":{"rendered":"OpenSSL 3.5 LTS: Chiavi e Certificati in 12 Step [2026]"},"content":{"rendered":"\n

OpenSSL<\/strong> \u00e8 lo strumento crittografico pi\u00f9 diffuso al mondo: protegge la maggior parte del traffico HTTPS, firma pacchetti software e genera le chiavi che custodiscono dati aziendali e personali. Eppure la riga di comando spaventa molti, e gli errori costano cari. Questa guida pratica del 12 giugno 2026 ti porta da zero a un progetto completo in 12 step, con comandi verificati, esempi di output reali e le scelte di sicurezza giuste per il 2026. Niente teoria astratta: digiti, vedi il risultato, capisci perch\u00e9 funziona.<\/p>\n\n\n\n

Useremo OpenSSL<\/strong> per generare chiavi RSA ed EC, creare una piccola Certificate Authority interna, firmare certificati con i nomi alternativi (SAN) richiesti dai browser moderni, convertire formati, cifrare file e testare connessioni TLS 1.3 reali. Alla fine avrai uno script riutilizzabile e una checklist di sicurezza. La scadenza del supporto per OpenSSL 3.0 LTS, fissata al 7 settembre 2026, rende questo il momento giusto per allinearsi alle versioni e alle pratiche attuali.<\/p>\n\n\n\n

Cos’\u00e8 OpenSSL e perch\u00e9 conta nel 2026<\/h2>\n\n\n\n

OpenSSL<\/strong> \u00e8 una libreria crittografica open source e una suite di strumenti da riga di comando. Implementa i protocolli TLS e SSL, gli algoritmi di cifratura simmetrica e asimmetrica, le funzioni hash e la gestione di certificati X.509. Quando il tuo browser mostra il lucchetto, dietro c’\u00e8 quasi sempre codice OpenSSL o una sua derivazione. Web server come Nginx e Apache, runtime come Node.js e Python, container Docker e migliaia di apparati di rete dipendono da questa libreria.<\/p>\n\n\n\n

Il comando openssl<\/code> da terminale \u00e8 il coltellino svizzero del professionista della sicurezza. Genera chiavi, crea richieste di firma, ispeziona certificati scaduti, cifra backup, calcola digest e diagnostica handshake TLS che falliscono in produzione. Saperlo usare distingue chi risolve un incidente in cinque minuti da chi apre un ticket e aspetta un giorno.<\/p>\n\n\n\n

Il quadro delle versioni nel 2026 richiede attenzione. La serie OpenSSL 3.0 LTS<\/strong> ha chiuso il supporto completo il 7 settembre 2025 e riceve solo correzioni di sicurezza fino al 7 settembre 2026, secondo il calendario ufficiale del progetto. La serie OpenSSL 3.5 LTS<\/strong>, rilasciata nell’aprile 2025, \u00e8 oggi la scelta a lungo termine consigliata e resta supportata fino all’aprile 2030. Esistono linee pi\u00f9 recenti non LTS, ma per i server in produzione conviene la stabilit\u00e0 della 3.5. Verifica sempre la tua versione prima di iniziare, perch\u00e9 alcune opzioni e provider sono cambiati tra la serie 1.1.1 e la 3.x.<\/p>\n\n\n\n

La transizione architetturale della serie 3.x ha spostato gli algoritmi deprecati fuori dal percorso predefinito. MD5, DES e altre primitive legacy ora vivono in un legacy provider<\/code> separato: se un vecchio script smette di funzionare dopo l’aggiornamento, quasi sempre la causa \u00e8 questa. Capire la differenza tra default provider, legacy provider e FIPS provider ti evita ore di frustrazione.<\/p>\n\n\n\n

Prerequisiti e versioni richieste<\/h2>\n\n\n\n

Questo tutorial funziona su Linux, macOS e Windows (con WSL2 o Git Bash). Ecco cosa ti serve, con le versioni di riferimento di met\u00e0 2026:<\/p>\n\n\n\n

Componente<\/th>Versione consigliata<\/th>Note<\/th><\/tr><\/thead>
OpenSSL<\/td>3.5 LTS (minimo 3.0)<\/td>Evita la serie 1.1.1, in EOL dal settembre 2023<\/td><\/tr>
Sistema operativo<\/td>Linux\/macOS\/WSL2<\/td>Bash o Zsh per gli script<\/td><\/tr>
Editor di testo<\/td>VS Code, nano, vim<\/td>Per i file di configurazione<\/td><\/tr>
Spazio su disco<\/td>50 MB<\/td>Chiavi e certificati sono piccoli<\/td><\/tr>
Privilegi<\/td>Utente normale<\/td>Niente root, tranne per installare pacchetti<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Non serve alcuna conoscenza pregressa di crittografia avanzata, ma aiuta capire la differenza tra chiave pubblica e privata e cosa sia una funzione hash. Se questi concetti ti sono nuovi, leggi prima la nostra guida sulle firme digitali<\/a> e su SHA-256<\/a>. Tutti i comandi che seguono sono testati su OpenSSL 3.x e indichiamo dove il comportamento cambia tra versioni.<\/p>\n\n\n\n

Step 1: Installare e verificare OpenSSL<\/h2>\n\n\n\n

Prima di tutto controlla se OpenSSL<\/strong> \u00e8 gi\u00e0 presente e quale versione hai. Su Linux e macOS apri il terminale e digita:<\/p>\n\n\n\n

openssl version -a<\/code><\/pre>\n\n\n\n
L’output mostra versione, data di build e directory dei certificati. Un esempio tipico:<\/p>\n\n\n\n
OpenSSL 3.5.7 30 Apr 2025 (Library: OpenSSL 3.5.7)\nbuilt on: ...\nOPENSSLDIR: \"\/usr\/lib\/ssl\"\nENGINESDIR: \"\/usr\/lib\/x86_64-linux-gnu\/engines-3\"<\/code><\/pre>\n\n\n\n
Se la versione \u00e8 inferiore alla 3.0, aggiorna. Su Debian e Ubuntu:<\/p>\n\n\n\n
sudo apt update && sudo apt install openssl\n# Verifica i provider disponibili (novit\u00e0 della serie 3.x)\nopenssl list -providers<\/code><\/pre>\n\n\n\n
Su macOS con Homebrew usa brew install openssl@3<\/code>. Attenzione: macOS include una versione di sistema spesso datata. Aggiungi la versione Homebrew al PATH<\/code> per usarla davvero. Su Windows, scarica un build affidabile o lavora dentro WSL2, che ti d\u00e0 un ambiente Linux pulito. Crea poi una cartella di lavoro dedicata, cos\u00ec non sparpagli chiavi sensibili nella home:<\/p>\n\n\n\n
mkdir -p ~\/lab-openssl && cd ~\/lab-openssl\nchmod 700 ~\/lab-openssl<\/code><\/pre>\n\n\n\n
Il permesso 700<\/code> impedisce ad altri utenti del sistema di leggere le chiavi private che genererai. Questa abitudine, banale ma trascurata, evita esposizioni accidentali su server condivisi.<\/p>\n\n\n\n
Step 2: Generare una chiave privata RSA<\/h2>\n\n\n\n
La chiave privata \u00e8 il segreto da cui dipende tutto il resto. Nel 2026 il comando moderno \u00e8 genpkey<\/code>, che sostituisce il vecchio genrsa<\/code>. Genera una chiave RSA da 3072 bit, oggi raccomandata per certificati a lunga durata:<\/p>\n\n\n\n
openssl genpkey -algorithm RSA \\\n  -pkeyopt rsa_keygen_bits:3072 \\\n  -out rsa.key<\/code><\/pre>\n\n\n\n
Per compatibilit\u00e0 con sistemi pi\u00f9 vecchi puoi usare 2048 bit, che resta il minimo accettabile secondo le linee guida NIST SP 800-57. Evita 1024 bit: \u00e8 considerato insicuro da anni. Per cifrare la chiave con una passphrase (consigliato per chiavi che non risiedono in un sistema automatizzato) aggiungi un cifrario:<\/p>\n\n\n\n
openssl genpkey -algorithm RSA \\\n  -pkeyopt rsa_keygen_bits:3072 \\\n  -aes-256-cbc \\\n  -out rsa-protetta.key<\/code><\/pre>\n\n\n\n
OpenSSL chieder\u00e0 una passphrase e la richieder\u00e0 a ogni uso. Per ispezionare la chiave senza esporla, usa:<\/p>\n\n\n\n
openssl pkey -in rsa.key -text -noout | head -5<\/code><\/pre>\n\n\n\n
Vedrai il modulo, l’esponente pubblico e i parametri privati. La chiave \u00e8 in formato PEM, riconoscibile dalle righe -----BEGIN PRIVATE KEY-----<\/code>. Imposta subito i permessi corretti, perch\u00e9 una chiave privata leggibile da tutti vanifica ogni sicurezza:<\/p>\n\n\n\n
chmod 600 rsa.key<\/code><\/pre>\n\n\n\n
RSA resta universalmente compatibile, ma \u00e8 lenta e produce chiavi grandi. Per la maggior parte dei nuovi progetti le curve ellittiche, che vediamo allo step successivo, offrono la stessa sicurezza con chiavi molto pi\u00f9 piccole e operazioni pi\u00f9 rapide.<\/p>\n\n\n\n
Step 3: Generare chiavi EC (ECDSA) ed Ed25519<\/h2>\n\n\n\n
La crittografia a curve ellittiche d\u00e0 sicurezza equivalente a RSA con chiavi molto pi\u00f9 corte. Una chiave EC da 256 bit regge il confronto con una RSA da 3072 bit. Genera una chiave sulla curva prime256v1<\/code> (nota anche come P-256), la pi\u00f9 compatibile:<\/p>\n\n\n\n
openssl genpkey -algorithm EC \\\n  -pkeyopt ec_paramgen_curve:prime256v1 \\\n  -out ec.key<\/code><\/pre>\n\n\n\n
Per un margine di sicurezza superiore, ad esempio per una CA interna a lunga vita, usa secp384r1<\/code> (P-384). Ispeziona la chiave appena creata:<\/p>\n\n\n\n
openssl pkey -in ec.key -text -noout | head -4<\/code><\/pre>\n\n\n\n
Private-Key: (256 bit)\npriv:\n    3b:df:2c:90:65:01:ee:d4:0f:24:a4:ff:1b:88:55:\n    8b:94:dd:39:2b:28:52:fd:6d:16:23:f6:4e:dc:05:<\/code><\/pre>\n\n\n\n
OpenSSL 3.x supporta anche Ed25519<\/strong>, una curva moderna progettata da Daniel J. Bernstein, veloce e resistente a molti errori di implementazione. \u00c8 la scelta migliore per le firme quando CA, client e strumenti la supportano:<\/p>\n\n\n\n
openssl genpkey -algorithm Ed25519 -out ed25519.key<\/code><\/pre>\n\n\n\n
Ed25519 non accetta parametri di dimensione: la curva ne definisce uno solo. Per le chiavi di accesso SSH e per la firma di artefatti software \u00e8 ormai lo standard de facto. Per i certificati TLS pubblici, per\u00f2, verifica prima il supporto della tua Certificate Authority, perch\u00e9 alcune ancora preferiscono ECDSA P-256 o RSA. La tabella seguente riassume le scelte:<\/p>\n\n\n\n
Algoritmo<\/th>Dimensione chiave<\/th>Velocit\u00e0<\/th>Compatibilit\u00e0<\/th>Uso consigliato 2026<\/th><\/tr><\/thead>
RSA 2048<\/td>Grande<\/td>Lenta<\/td>Universale<\/td>Sistemi legacy<\/td><\/tr>
RSA 3072<\/td>Molto grande<\/td>Molto lenta<\/td>Universale<\/td>Certificati a lunga durata<\/td><\/tr>
ECDSA P-256<\/td>Piccola<\/td>Veloce<\/td>Alta<\/td>TLS generico<\/td><\/tr>
ECDSA P-384<\/td>Piccola<\/td>Veloce<\/td>Alta<\/td>CA interne, margine extra<\/td><\/tr>
Ed25519<\/td>Minima<\/td>Velocissima<\/td>Media<\/td>SSH, firma software<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Step 4: Creare una CSR (Certificate Signing Request)<\/h2>\n\n\n\n
Una richiesta di firma del certificato (CSR) contiene la tua chiave pubblica e i dati identificativi, ed \u00e8 ci\u00f2 che invii a una Certificate Authority per ottenere un certificato firmato. Crea una CSR dalla chiave EC dello step precedente:<\/p>\n\n\n\n
openssl req -new -key ec.key -out richiesta.csr \\\n  -subj \"\/C=IT\/ST=Lazio\/L=Roma\/O=Esempio Srl\/CN=www.esempio.it\"<\/code><\/pre>\n\n\n\n
Il parametro -subj<\/code> evita le domande interattive: utile negli script. I campi seguono lo standard X.500: C<\/code> \u00e8 il paese, ST<\/code> la regione, L<\/code> la citt\u00e0, O<\/code> l’organizzazione e CN<\/code> il nome comune (di solito il dominio). I browser moderni ignorano il CN e si basano sui Subject Alternative Names, quindi aggiungili tramite un file di configurazione:<\/p>\n\n\n\n
cat > san.cnf <<'EOF'\n[req]\ndistinguished_name = dn\nreq_extensions = v3_req\nprompt = no\n\n[dn]\nC = IT\nO = Esempio Srl\nCN = www.esempio.it\n\n[v3_req]\nsubjectAltName = @alt\n\n[alt]\nDNS.1 = www.esempio.it\nDNS.2 = esempio.it\nDNS.3 = api.esempio.it\nEOF\n\nopenssl req -new -key ec.key -out richiesta-san.csr -config san.cnf<\/code><\/pre>\n\n\n\n
Verifica il contenuto della CSR prima di inviarla, per assicurarti che i SAN siano presenti:<\/p>\n\n\n\n
openssl req -in richiesta-san.csr -noout -text | grep -A2 \"Alternative\"<\/code><\/pre>\n\n\n\n
Se i SAN mancano, il certificato verr\u00e0 rifiutato dai browser con l’errore NET::ERR_CERT_COMMON_NAME_INVALID<\/code>. Questo \u00e8 uno degli errori pi\u00f9 frequenti per chi crea certificati a mano, e la causa numero uno di ticket inutili.<\/p>\n\n\n\n
Step 5: Generare un certificato self-signed<\/h2>\n\n\n\n
Per sviluppo, test interni o ambienti di staging non serve una CA pubblica: basta un certificato autofirmato. Crealo in un comando solo, includendo i SAN:<\/p>\n\n\n\n
openssl req -x509 -new -key ec.key -sha256 -days 365 \\\n  -out cert.pem -config san.cnf -extensions v3_req<\/code><\/pre>\n\n\n\n
Il flag -x509<\/code> produce un certificato invece di una CSR, -days 365<\/code> ne fissa la validit\u00e0 a un anno e -sha256<\/code> impone la firma con SHA-256. Non esiste una durata predefinita portabile in OpenSSL: il valore dipende sempre da -days<\/code>, quindi specificalo sempre. Ispeziona subito il risultato:<\/p>\n\n\n\n
openssl x509 -in cert.pem -noout -subject -issuer -dates -fingerprint -sha256<\/code><\/pre>\n\n\n\n
subject=C = IT, O = Esempio Srl, CN = www.esempio.it\nissuer=C = IT, O = Esempio Srl, CN = www.esempio.it\nnotBefore=Jun 12 16:29:45 2026 GMT\nnotAfter=Jun 12 16:29:45 2027 GMT\nsha256 Fingerprint=26:36:20:BC:2E:85:36:62:EC:48:0F:6D:9F:79:DA:BB:...<\/code><\/pre>\n\n\n\n
Quando subject<\/code> e issuer<\/code> coincidono, il certificato \u00e8 autofirmato: il browser mostrer\u00e0 un avviso di sicurezza, comportamento atteso in locale. Per evitarlo, importa il certificato nello store di fiducia del sistema o, meglio ancora, crea una piccola CA interna come vediamo allo step successivo. Per i siti pubblici, invece, usa una CA gratuita come Let’s Encrypt<\/a>, che automatizza il rinnovo e l’emissione.<\/p>\n\n\n\n
Step 6: Costruire una CA locale e firmare certificati<\/h2>\n\n\n\n
Una Certificate Authority interna risolve il problema degli avvisi: importi una sola volta il certificato radice nei dispositivi e tutti i certificati che firmi diventano fidati. Inizia creando la chiave e il certificato radice della CA, con una validit\u00e0 lunga e una curva robusta:<\/p>\n\n\n\n
# Chiave della CA su P-384 per margine di sicurezza\nopenssl genpkey -algorithm EC \\\n  -pkeyopt ec_paramgen_curve:secp384r1 -out ca.key\nchmod 600 ca.key\n\n# Certificato radice valido 10 anni\nopenssl req -x509 -new -key ca.key -sha384 -days 3650 \\\n  -out ca.pem -subj \"\/C=IT\/O=Esempio CA\/CN=Esempio Root CA\"<\/code><\/pre>\n\n\n\n
Ora firma la CSR creata allo step 4 con la CA. Servono le estensioni corrette, altrimenti i client moderni rifiutano il certificato:<\/p>\n\n\n\n
openssl x509 -req -in richiesta-san.csr \\\n  -CA ca.pem -CAkey ca.key -CAcreateserial \\\n  -out server.pem -days 365 -sha256 \\\n  -extfile san.cnf -extensions v3_req<\/code><\/pre>\n\n\n\n
Il flag -CAcreateserial<\/code> genera un file ca.srl<\/code> con il numero di serie progressivo. I numeri di serie devono essere unici per ogni certificato emesso da una CA: se ne riusi uno, i client lo rifiutano. Verifica la catena di fiducia:<\/p>\n\n\n\n
openssl verify -CAfile ca.pem server.pem<\/code><\/pre>\n\n\n\n
Una risposta server.pem: OK<\/code> conferma che il certificato del server \u00e8 firmato correttamente dalla tua CA. A questo punto distribuisci ca.pem<\/code> ai dispositivi che devono fidarsi dei tuoi servizi interni. Questo schema \u00e8 la base di ogni infrastruttura a chiave pubblica (PKI) aziendale e dei certificati mTLS che proteggono le comunicazioni tra microservizi.<\/p>\n\n\n\n
Step 7: Ispezionare e verificare i certificati<\/h2>\n\n\n\n
Saper leggere un certificato \u00e8 met\u00e0 del lavoro di un sistemista. Per vedere tutto il contenuto in formato leggibile:<\/p>\n\n\n\n
openssl x509 -in server.pem -text -noout<\/code><\/pre>\n\n\n\n
Per estrarre solo i campi che ti servono, usa flag mirati. Controllare la scadenza di un certificato \u00e8 un’operazione quotidiana:<\/p>\n\n\n\n
# Scade entro 30 giorni? Codice di uscita 0 = s\u00ec\nopenssl x509 -in server.pem -checkend 2592000 -noout\necho $?<\/code><\/pre>\n\n\n\n
Questo comando \u00e8 perfetto per uno script di monitoraggio: se restituisce 1<\/code>, il certificato \u00e8 ancora valido oltre i 30 giorni; se restituisce 0<\/code>, \u00e8 ora di rinnovare. Verifica anche che una chiave privata corrisponda davvero al suo certificato confrontando le impronte della chiave pubblica:<\/p>\n\n\n\n
openssl pkey -in ec.key -pubout | openssl sha256\nopenssl x509 -in server.pem -pubkey -noout | openssl sha256<\/code><\/pre>\n\n\n\n
Se i due hash SHA-256 coincidono, chiave e certificato sono una coppia valida. Questo controllo evita l’errore classico di installare su un server una chiave che non corrisponde al certificato, che genera un fallimento dell’handshake TLS difficile da diagnosticare. Per approfondire il ruolo degli hash in questi controlli, vedi la nostra guida sulle funzioni hash crittografiche<\/a>.<\/p>\n\n\n\n
Step 8: Convertire i formati (PEM, DER, PKCS#12)<\/h2>\n\n\n\n
Sistemi diversi vogliono formati diversi. PEM (testo Base64) \u00e8 lo standard Unix; DER (binario) serve a Java e ad alcuni apparati; PKCS#12 (un unico file .p12<\/code> con chiave e certificato) \u00e8 richiesto da Windows e dai browser per l’import. Converti PEM in DER:<\/p>\n\n\n\n
openssl x509 -in cert.pem -outform der -out cert.der<\/code><\/pre>\n\n\n\n
Crea un bundle PKCS#12 che riunisce chiave privata, certificato e catena della CA in un solo file protetto da password:<\/p>\n\n\n\n
openssl pkcs12 -export \\\n  -inkey ec.key -in server.pem -certfile ca.pem \\\n  -out bundle.p12 -name \"Server Esempio\"<\/code><\/pre>\n\n\n\n
OpenSSL chieder\u00e0 una password di export. Per estrarre di nuovo i componenti da un file .p12<\/code>, ad esempio ricevuto da un fornitore:<\/p>\n\n\n\n
# Estrai solo il certificato (niente chiave)\nopenssl pkcs12 -in bundle.p12 -clcerts -nokeys -out estratto.pem\n\n# Estrai solo la chiave privata\nopenssl pkcs12 -in bundle.p12 -nocerts -out chiave-estratta.key<\/code><\/pre>\n\n\n\n
Attenzione a un dettaglio della serie 3.x: i file .p12<\/code> generati con OpenSSL 3.0 e successivi usano algoritmi pi\u00f9 moderni che alcuni sistemi datati non leggono. Se Windows o un vecchio Java rifiutano il file, aggiungi -legacy<\/code> al comando di export per usare la cifratura compatibile. \u00c8 una delle incompatibilit\u00e0 pi\u00f9 segnalate dopo l’aggiornamento alla serie 3.<\/p>\n\n\n\n
Step 9: Cifrare file e calcolare i digest<\/h2>\n\n\n\n
OpenSSL<\/strong> cifra anche file arbitrari con crittografia simmetrica. Per cifrare un backup con AES-256, sempre derivando la chiave dalla password con un metodo robusto:<\/p>\n\n\n\n
openssl enc -aes-256-cbc -salt -pbkdf2 -iter 600000 \\\n  -in backup.tar -out backup.tar.enc<\/code><\/pre>\n\n\n\n
I parametri qui sono cruciali. -salt<\/code> aggiunge casualit\u00e0, -pbkdf2<\/code> usa una funzione di derivazione moderna e -iter 600000<\/code> impone abbastanza iterazioni da rallentare gli attacchi a forza bruta. Senza -pbkdf2<\/code>, OpenSSL ricade su una derivazione debole e legacy: non ometterlo mai. Per decifrare:<\/p>\n\n\n\n
openssl enc -d -aes-256-cbc -pbkdf2 -iter 600000 \\\n  -in backup.tar.enc -out backup.tar<\/code><\/pre>\n\n\n\n
Per la cifratura di interi dischi conviene comunque preferire strumenti dedicati come quelli descritti nella nostra guida su VeraCrypt<\/a>, ma per script automatizzati OpenSSL resta pratico. Calcola anche i digest per verificare l’integrit\u00e0 di un download:<\/p>\n\n\n\n
openssl dgst -sha256 immagine.iso<\/code><\/pre>\n\n\n\n
SHA2-256(immagine.iso)= f440616eb749b6883ed4010c6bfe97a01c61c89a2d94510401eb3f231afba148<\/code><\/pre>\n\n\n\n
Confronta l’hash ottenuto con quello pubblicato dal fornitore. Usa SHA-256 o SHA-3, mai MD5 o SHA-1: entrambi sono vulnerabili a collisioni, come abbiamo documentato nell’analisi della collisione SHA-1 di SHAttered<\/a>.<\/p>\n\n\n\n
Step 10: Testare connessioni TLS con s_client<\/h2>\n\n\n\n
Il sottocomando s_client<\/code> \u00e8 lo strumento diagnostico pi\u00f9 potente per chi gestisce server web. Apre una connessione TLS reale e mostra tutto: certificato, catena, protocollo e cifrario negoziati. Verifica un sito pubblico:<\/p>\n\n\n\n
openssl s_client -connect esempio.it:443 -servername esempio.it < \/dev\/null<\/code><\/pre>\n\n\n\n
Il parametro -servername<\/code> invia l’estensione SNI, indispensabile sui server che ospitano pi\u00f9 domini sullo stesso IP. Per forzare TLS 1.3 e vedere quale cifrario viene scelto:<\/p>\n\n\n\n
openssl s_client -connect esempio.it:443 -tls1_3 < \/dev\/null \\\n  | grep -E \"Protocol|Cipher\"<\/code><\/pre>\n\n\n\n
OpenSSL 3.x supporta i tre suite di cifratura standard di TLS 1.3: TLS_AES_256_GCM_SHA384<\/code>, TLS_CHACHA20_POLY1305_SHA256<\/code> e TLS_AES_128_GCM_SHA256<\/code>. Per estrarre solo il certificato presentato dal server e salvarlo:<\/p>\n\n\n\n
openssl s_client -connect esempio.it:443 -servername esempio.it < \/dev\/null \\\n  2>\/dev\/null | openssl x509 -out remoto.pem<\/code><\/pre>\n\n\n\n
Questo \u00e8 utilissimo per diagnosticare certificati scaduti o catene incomplete in produzione. Per capire meglio cosa avviene durante l’handshake TLS, leggi la nostra guida su HTTPS e TLS<\/a>. La diagnostica con s_client<\/code> \u00e8 una competenza che ripaga ogni volta che un servizio HTTPS smette di funzionare senza spiegazioni evidenti.<\/p>\n\n\n\n
Step 11: Avviare un server HTTPS di test<\/h2>\n\n\n\n
OpenSSL include un server TLS minimale, perfetto per testare il certificato che hai appena firmato senza configurare Nginx. Avvialo con la chiave e il certificato del server:<\/p>\n\n\n\n
openssl s_server -key ec.key -cert server.pem \\\n  -accept 4443 -www<\/code><\/pre>\n\n\n\n
Il flag -www<\/code> fa rispondere il server con una pagina HTML che riassume i parametri TLS della connessione. Da un altro terminale, collegati con il client e indica la CA come trust anchor:<\/p>\n\n\n\n
openssl s_client -connect localhost:4443 -CAfile ca.pem < \/dev\/null \\\n  | grep \"Verify return code\"<\/code><\/pre>\n\n\n\n
Una risposta Verify return code: 0 (ok)<\/code> conferma che l’intera catena, dalla CA al certificato del server, \u00e8 valida. Se vedi code 19<\/code> o code 20<\/code>, manca la CA o la catena \u00e8 incompleta. Puoi anche puntare un browser su https:\/\/localhost:4443<\/code>: dopo aver importato ca.pem<\/code> nello store di fiducia, il lucchetto comparir\u00e0 senza avvisi. Questo ciclo (genera, firma, avvia, verifica) riproduce in piccolo l’intera vita di un certificato TLS in produzione.<\/p>\n\n\n\n
Step 12: Lo script completo del progetto<\/h2>\n\n\n\n
Mettiamo insieme tutto in un unico script riutilizzabile che, partendo da zero, crea una CA, genera una chiave del server, firma un certificato con i SAN e verifica la catena. Salvalo come genera-pki.sh<\/code>:<\/p>\n\n\n\n
#!\/usr\/bin\/env bash\nset -euo pipefail\n\nDOMINIO=\"${1:-www.esempio.it}\"\nGIORNI_CA=3650\nGIORNI_CERT=365\n\necho \"==> Creo la directory di lavoro\"\nmkdir -p pki && cd pki && umask 077\n\necho \"==> 1) Chiave e certificato radice della CA\"\nopenssl genpkey -algorithm EC \\\n  -pkeyopt ec_paramgen_curve:secp384r1 -out ca.key\nopenssl req -x509 -new -key ca.key -sha384 -days \"$GIORNI_CA\" \\\n  -out ca.pem -subj \"\/C=IT\/O=Esempio CA\/CN=Esempio Root CA\"\n\necho \"==> 2) Chiave del server (P-256)\"\nopenssl genpkey -algorithm EC \\\n  -pkeyopt ec_paramgen_curve:prime256v1 -out server.key\n\necho \"==> 3) File di configurazione con i SAN\"\ncat > san.cnf <<EOF\n[req]\ndistinguished_name = dn\nreq_extensions = v3_req\nprompt = no\n[dn]\nC = IT\nO = Esempio Srl\nCN = ${DOMINIO}\n[v3_req]\nsubjectAltName = @alt\n[alt]\nDNS.1 = ${DOMINIO}\nEOF\n\necho \"==> 4) CSR e firma con la CA\"\nopenssl req -new -key server.key -out server.csr -config san.cnf\nopenssl x509 -req -in server.csr \\\n  -CA ca.pem -CAkey ca.key -CAcreateserial \\\n  -out server.pem -days \"$GIORNI_CERT\" -sha256 \\\n  -extfile san.cnf -extensions v3_req\n\necho \"==> 5) Verifica della catena\"\nopenssl verify -CAfile ca.pem server.pem\n\necho \"==> Fatto. File generati in $(pwd)\"<\/code><\/pre>\n\n\n\n
Rendi lo script eseguibile e lancialo passando il dominio:<\/p>\n\n\n\n
chmod +x genera-pki.sh\n.\/genera-pki.sh api.esempio.it<\/code><\/pre>\n\n\n\n
L’istruzione set -euo pipefail<\/code> ferma lo script al primo errore, e umask 077<\/code> garantisce che ogni file creato nasca con permessi restrittivi. In meno di un secondo ottieni una PKI funzionante e ripetibile. Per integrare le chiavi cos\u00ec generate in un’applicazione, vedi la nostra guida sulla crittografia end-to-end in Node.js<\/a>.<\/p>\n\n\n\n
5 errori comuni da evitare con OpenSSL<\/h2>\n\n\n\n
Anche gli amministratori esperti cadono in trappole ricorrenti. Ecco le cinque pi\u00f9 costose e come prevenirle.<\/p>\n\n\n\n