OpenSSL è lo strumento crittografico più 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é funziona.

Useremo OpenSSL 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.

Cos’è OpenSSL e perché conta nel 2026

OpenSSL è 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’è 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.

Il comando openssl da terminale è 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.

Il quadro delle versioni nel 2026 richiede attenzione. La serie OpenSSL 3.0 LTS 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, rilasciata nell’aprile 2025, è oggi la scelta a lungo termine consigliata e resta supportata fino all’aprile 2030. Esistono linee più recenti non LTS, ma per i server in produzione conviene la stabilità della 3.5. Verifica sempre la tua versione prima di iniziare, perché alcune opzioni e provider sono cambiati tra la serie 1.1.1 e la 3.x.

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 separato: se un vecchio script smette di funzionare dopo l’aggiornamento, quasi sempre la causa è questa. Capire la differenza tra default provider, legacy provider e FIPS provider ti evita ore di frustrazione.

Prerequisiti e versioni richieste

Questo tutorial funziona su Linux, macOS e Windows (con WSL2 o Git Bash). Ecco cosa ti serve, con le versioni di riferimento di metà 2026:

ComponenteVersione consigliataNote
OpenSSL3.5 LTS (minimo 3.0)Evita la serie 1.1.1, in EOL dal settembre 2023
Sistema operativoLinux/macOS/WSL2Bash o Zsh per gli script
Editor di testoVS Code, nano, vimPer i file di configurazione
Spazio su disco50 MBChiavi e certificati sono piccoli
PrivilegiUtente normaleNiente root, tranne per installare pacchetti

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 e su SHA-256. Tutti i comandi che seguono sono testati su OpenSSL 3.x e indichiamo dove il comportamento cambia tra versioni.

Step 1: Installare e verificare OpenSSL

Prima di tutto controlla se OpenSSL è già presente e quale versione hai. Su Linux e macOS apri il terminale e digita:

openssl version -a

L’output mostra versione, data di build e directory dei certificati. Un esempio tipico:

OpenSSL 3.5.7 30 Apr 2025 (Library: OpenSSL 3.5.7)
built on: ...
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-3"

Se la versione è inferiore alla 3.0, aggiorna. Su Debian e Ubuntu:

sudo apt update && sudo apt install openssl
# Verifica i provider disponibili (novità della serie 3.x)
openssl list -providers

Su macOS con Homebrew usa brew install openssl@3. Attenzione: macOS include una versione di sistema spesso datata. Aggiungi la versione Homebrew al PATH per usarla davvero. Su Windows, scarica un build affidabile o lavora dentro WSL2, che ti dà un ambiente Linux pulito. Crea poi una cartella di lavoro dedicata, così non sparpagli chiavi sensibili nella home:

mkdir -p ~/lab-openssl && cd ~/lab-openssl
chmod 700 ~/lab-openssl

Il permesso 700 impedisce ad altri utenti del sistema di leggere le chiavi private che genererai. Questa abitudine, banale ma trascurata, evita esposizioni accidentali su server condivisi.

Step 2: Generare una chiave privata RSA

La chiave privata è il segreto da cui dipende tutto il resto. Nel 2026 il comando moderno è genpkey, che sostituisce il vecchio genrsa. Genera una chiave RSA da 3072 bit, oggi raccomandata per certificati a lunga durata:

openssl genpkey -algorithm RSA \
  -pkeyopt rsa_keygen_bits:3072 \
  -out rsa.key

Per compatibilità con sistemi più vecchi puoi usare 2048 bit, che resta il minimo accettabile secondo le linee guida NIST SP 800-57. Evita 1024 bit: è considerato insicuro da anni. Per cifrare la chiave con una passphrase (consigliato per chiavi che non risiedono in un sistema automatizzato) aggiungi un cifrario:

openssl genpkey -algorithm RSA \
  -pkeyopt rsa_keygen_bits:3072 \
  -aes-256-cbc \
  -out rsa-protetta.key

OpenSSL chiederà una passphrase e la richiederà a ogni uso. Per ispezionare la chiave senza esporla, usa:

openssl pkey -in rsa.key -text -noout | head -5

Vedrai il modulo, l’esponente pubblico e i parametri privati. La chiave è in formato PEM, riconoscibile dalle righe -----BEGIN PRIVATE KEY-----. Imposta subito i permessi corretti, perché una chiave privata leggibile da tutti vanifica ogni sicurezza:

chmod 600 rsa.key

RSA resta universalmente compatibile, ma è 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ù piccole e operazioni più rapide.

Step 3: Generare chiavi EC (ECDSA) ed Ed25519

La crittografia a curve ellittiche dà sicurezza equivalente a RSA con chiavi molto più corte. Una chiave EC da 256 bit regge il confronto con una RSA da 3072 bit. Genera una chiave sulla curva prime256v1 (nota anche come P-256), la più compatibile:

openssl genpkey -algorithm EC \
  -pkeyopt ec_paramgen_curve:prime256v1 \
  -out ec.key

Per un margine di sicurezza superiore, ad esempio per una CA interna a lunga vita, usa secp384r1 (P-384). Ispeziona la chiave appena creata:

openssl pkey -in ec.key -text -noout | head -4
Private-Key: (256 bit)
priv:
    3b:df:2c:90:65:01:ee:d4:0f:24:a4:ff:1b:88:55:
    8b:94:dd:39:2b:28:52:fd:6d:16:23:f6:4e:dc:05:

OpenSSL 3.x supporta anche Ed25519, una curva moderna progettata da Daniel J. Bernstein, veloce e resistente a molti errori di implementazione. È la scelta migliore per le firme quando CA, client e strumenti la supportano:

openssl genpkey -algorithm Ed25519 -out ed25519.key

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 è ormai lo standard de facto. Per i certificati TLS pubblici, però, verifica prima il supporto della tua Certificate Authority, perché alcune ancora preferiscono ECDSA P-256 o RSA. La tabella seguente riassume le scelte:

AlgoritmoDimensione chiaveVelocitàCompatibilitàUso consigliato 2026
RSA 2048GrandeLentaUniversaleSistemi legacy
RSA 3072Molto grandeMolto lentaUniversaleCertificati a lunga durata
ECDSA P-256PiccolaVeloceAltaTLS generico
ECDSA P-384PiccolaVeloceAltaCA interne, margine extra
Ed25519MinimaVelocissimaMediaSSH, firma software

Step 4: Creare una CSR (Certificate Signing Request)

Una richiesta di firma del certificato (CSR) contiene la tua chiave pubblica e i dati identificativi, ed è ciò che invii a una Certificate Authority per ottenere un certificato firmato. Crea una CSR dalla chiave EC dello step precedente:

openssl req -new -key ec.key -out richiesta.csr \
  -subj "/C=IT/ST=Lazio/L=Roma/O=Esempio Srl/CN=www.esempio.it"

Il parametro -subj evita le domande interattive: utile negli script. I campi seguono lo standard X.500: C è il paese, ST la regione, L la città, O l’organizzazione e CN 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:

cat > san.cnf <<'EOF'
[req]
distinguished_name = dn
req_extensions = v3_req
prompt = no

[dn]
C = IT
O = Esempio Srl
CN = www.esempio.it

[v3_req]
subjectAltName = @alt

[alt]
DNS.1 = www.esempio.it
DNS.2 = esempio.it
DNS.3 = api.esempio.it
EOF

openssl req -new -key ec.key -out richiesta-san.csr -config san.cnf

Verifica il contenuto della CSR prima di inviarla, per assicurarti che i SAN siano presenti:

openssl req -in richiesta-san.csr -noout -text | grep -A2 "Alternative"

Se i SAN mancano, il certificato verrà rifiutato dai browser con l’errore NET::ERR_CERT_COMMON_NAME_INVALID. Questo è uno degli errori più frequenti per chi crea certificati a mano, e la causa numero uno di ticket inutili.

Step 5: Generare un certificato self-signed

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:

openssl req -x509 -new -key ec.key -sha256 -days 365 \
  -out cert.pem -config san.cnf -extensions v3_req

Il flag -x509 produce un certificato invece di una CSR, -days 365 ne fissa la validità a un anno e -sha256 impone la firma con SHA-256. Non esiste una durata predefinita portabile in OpenSSL: il valore dipende sempre da -days, quindi specificalo sempre. Ispeziona subito il risultato:

openssl x509 -in cert.pem -noout -subject -issuer -dates -fingerprint -sha256
subject=C = IT, O = Esempio Srl, CN = www.esempio.it
issuer=C = IT, O = Esempio Srl, CN = www.esempio.it
notBefore=Jun 12 16:29:45 2026 GMT
notAfter=Jun 12 16:29:45 2027 GMT
sha256 Fingerprint=26:36:20:BC:2E:85:36:62:EC:48:0F:6D:9F:79:DA:BB:...

Quando subject e issuer coincidono, il certificato è autofirmato: il browser mostrerà 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, che automatizza il rinnovo e l’emissione.

Step 6: Costruire una CA locale e firmare certificati

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à lunga e una curva robusta:

# Chiave della CA su P-384 per margine di sicurezza
openssl genpkey -algorithm EC \
  -pkeyopt ec_paramgen_curve:secp384r1 -out ca.key
chmod 600 ca.key

# Certificato radice valido 10 anni
openssl req -x509 -new -key ca.key -sha384 -days 3650 \
  -out ca.pem -subj "/C=IT/O=Esempio CA/CN=Esempio Root CA"

Ora firma la CSR creata allo step 4 con la CA. Servono le estensioni corrette, altrimenti i client moderni rifiutano il certificato:

openssl x509 -req -in richiesta-san.csr \
  -CA ca.pem -CAkey ca.key -CAcreateserial \
  -out server.pem -days 365 -sha256 \
  -extfile san.cnf -extensions v3_req

Il flag -CAcreateserial genera un file ca.srl 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:

openssl verify -CAfile ca.pem server.pem

Una risposta server.pem: OK conferma che il certificato del server è firmato correttamente dalla tua CA. A questo punto distribuisci ca.pem ai dispositivi che devono fidarsi dei tuoi servizi interni. Questo schema è la base di ogni infrastruttura a chiave pubblica (PKI) aziendale e dei certificati mTLS che proteggono le comunicazioni tra microservizi.

Step 7: Ispezionare e verificare i certificati

Saper leggere un certificato è metà del lavoro di un sistemista. Per vedere tutto il contenuto in formato leggibile:

openssl x509 -in server.pem -text -noout

Per estrarre solo i campi che ti servono, usa flag mirati. Controllare la scadenza di un certificato è un’operazione quotidiana:

# Scade entro 30 giorni? Codice di uscita 0 = sì
openssl x509 -in server.pem -checkend 2592000 -noout
echo $?

Questo comando è perfetto per uno script di monitoraggio: se restituisce 1, il certificato è ancora valido oltre i 30 giorni; se restituisce 0, è ora di rinnovare. Verifica anche che una chiave privata corrisponda davvero al suo certificato confrontando le impronte della chiave pubblica:

openssl pkey -in ec.key -pubout | openssl sha256
openssl x509 -in server.pem -pubkey -noout | openssl sha256

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.

Step 8: Convertire i formati (PEM, DER, PKCS#12)

Sistemi diversi vogliono formati diversi. PEM (testo Base64) è lo standard Unix; DER (binario) serve a Java e ad alcuni apparati; PKCS#12 (un unico file .p12 con chiave e certificato) è richiesto da Windows e dai browser per l’import. Converti PEM in DER:

openssl x509 -in cert.pem -outform der -out cert.der

Crea un bundle PKCS#12 che riunisce chiave privata, certificato e catena della CA in un solo file protetto da password:

openssl pkcs12 -export \
  -inkey ec.key -in server.pem -certfile ca.pem \
  -out bundle.p12 -name "Server Esempio"

OpenSSL chiederà una password di export. Per estrarre di nuovo i componenti da un file .p12, ad esempio ricevuto da un fornitore:

# Estrai solo il certificato (niente chiave)
openssl pkcs12 -in bundle.p12 -clcerts -nokeys -out estratto.pem

# Estrai solo la chiave privata
openssl pkcs12 -in bundle.p12 -nocerts -out chiave-estratta.key

Attenzione a un dettaglio della serie 3.x: i file .p12 generati con OpenSSL 3.0 e successivi usano algoritmi più moderni che alcuni sistemi datati non leggono. Se Windows o un vecchio Java rifiutano il file, aggiungi -legacy al comando di export per usare la cifratura compatibile. È una delle incompatibilità più segnalate dopo l’aggiornamento alla serie 3.

Step 9: Cifrare file e calcolare i digest

OpenSSL cifra anche file arbitrari con crittografia simmetrica. Per cifrare un backup con AES-256, sempre derivando la chiave dalla password con un metodo robusto:

openssl enc -aes-256-cbc -salt -pbkdf2 -iter 600000 \
  -in backup.tar -out backup.tar.enc

I parametri qui sono cruciali. -salt aggiunge casualità, -pbkdf2 usa una funzione di derivazione moderna e -iter 600000 impone abbastanza iterazioni da rallentare gli attacchi a forza bruta. Senza -pbkdf2, OpenSSL ricade su una derivazione debole e legacy: non ometterlo mai. Per decifrare:

openssl enc -d -aes-256-cbc -pbkdf2 -iter 600000 \
  -in backup.tar.enc -out backup.tar

Per la cifratura di interi dischi conviene comunque preferire strumenti dedicati come quelli descritti nella nostra guida su VeraCrypt, ma per script automatizzati OpenSSL resta pratico. Calcola anche i digest per verificare l’integrità di un download:

openssl dgst -sha256 immagine.iso
SHA2-256(immagine.iso)= f440616eb749b6883ed4010c6bfe97a01c61c89a2d94510401eb3f231afba148

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.

Step 10: Testare connessioni TLS con s_client

Il sottocomando s_client è lo strumento diagnostico più potente per chi gestisce server web. Apre una connessione TLS reale e mostra tutto: certificato, catena, protocollo e cifrario negoziati. Verifica un sito pubblico:

openssl s_client -connect esempio.it:443 -servername esempio.it < /dev/null

Il parametro -servername invia l’estensione SNI, indispensabile sui server che ospitano più domini sullo stesso IP. Per forzare TLS 1.3 e vedere quale cifrario viene scelto:

openssl s_client -connect esempio.it:443 -tls1_3 < /dev/null \
  | grep -E "Protocol|Cipher"

OpenSSL 3.x supporta i tre suite di cifratura standard di TLS 1.3: TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256 e TLS_AES_128_GCM_SHA256. Per estrarre solo il certificato presentato dal server e salvarlo:

openssl s_client -connect esempio.it:443 -servername esempio.it < /dev/null \
  2>/dev/null | openssl x509 -out remoto.pem

Questo è 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. La diagnostica con s_client è una competenza che ripaga ogni volta che un servizio HTTPS smette di funzionare senza spiegazioni evidenti.

Step 11: Avviare un server HTTPS di test

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:

openssl s_server -key ec.key -cert server.pem \
  -accept 4443 -www

Il flag -www 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:

openssl s_client -connect localhost:4443 -CAfile ca.pem < /dev/null \
  | grep "Verify return code"

Una risposta Verify return code: 0 (ok) conferma che l’intera catena, dalla CA al certificato del server, è valida. Se vedi code 19 o code 20, manca la CA o la catena è incompleta. Puoi anche puntare un browser su https://localhost:4443: dopo aver importato ca.pem nello store di fiducia, il lucchetto comparirà senza avvisi. Questo ciclo (genera, firma, avvia, verifica) riproduce in piccolo l’intera vita di un certificato TLS in produzione.

Step 12: Lo script completo del progetto

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:

#!/usr/bin/env bash
set -euo pipefail

DOMINIO="${1:-www.esempio.it}"
GIORNI_CA=3650
GIORNI_CERT=365

echo "==> Creo la directory di lavoro"
mkdir -p pki && cd pki && umask 077

echo "==> 1) Chiave e certificato radice della CA"
openssl genpkey -algorithm EC \
  -pkeyopt ec_paramgen_curve:secp384r1 -out ca.key
openssl req -x509 -new -key ca.key -sha384 -days "$GIORNI_CA" \
  -out ca.pem -subj "/C=IT/O=Esempio CA/CN=Esempio Root CA"

echo "==> 2) Chiave del server (P-256)"
openssl genpkey -algorithm EC \
  -pkeyopt ec_paramgen_curve:prime256v1 -out server.key

echo "==> 3) File di configurazione con i SAN"
cat > san.cnf <<EOF
[req]
distinguished_name = dn
req_extensions = v3_req
prompt = no
[dn]
C = IT
O = Esempio Srl
CN = ${DOMINIO}
[v3_req]
subjectAltName = @alt
[alt]
DNS.1 = ${DOMINIO}
EOF

echo "==> 4) CSR e firma con la CA"
openssl req -new -key server.key -out server.csr -config san.cnf
openssl x509 -req -in server.csr \
  -CA ca.pem -CAkey ca.key -CAcreateserial \
  -out server.pem -days "$GIORNI_CERT" -sha256 \
  -extfile san.cnf -extensions v3_req

echo "==> 5) Verifica della catena"
openssl verify -CAfile ca.pem server.pem

echo "==> Fatto. File generati in $(pwd)"

Rendi lo script eseguibile e lancialo passando il dominio:

chmod +x genera-pki.sh
./genera-pki.sh api.esempio.it

L’istruzione set -euo pipefail ferma lo script al primo errore, e umask 077 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ì generate in un’applicazione, vedi la nostra guida sulla crittografia end-to-end in Node.js.

5 errori comuni da evitare con OpenSSL

Anche gli amministratori esperti cadono in trappole ricorrenti. Ecco le cinque più costose e come prevenirle.

  • Dimenticare i SAN. Un certificato con il solo Common Name viene rifiutato da Chrome e Firefox dal 2017. Usa sempre un file di configurazione con subjectAltName, anche per un singolo dominio.
  • Omettere -pbkdf2 nella cifratura file. Senza questo flag, openssl enc usa una derivazione di chiave debole vulnerabile agli attacchi a dizionario. Aggiungi sempre -pbkdf2 -iter 600000.
  • Permessi troppo aperti sulle chiavi private. Una chiave con permessi 644 è leggibile da qualsiasi utente del sistema. Imposta sempre chmod 600 e usa umask 077 negli script.
  • Riusare i numeri di serie della CA. Cancellare il file .srl e rigenerare certificati con lo stesso serial fa fallire la validazione lato client. Conserva il file di serie.
  • Usare ancora SHA-1 o MD5. Le firme con questi hash sono insicure. Specifica sempre -sha256 o superiore nei comandi di firma.

Un sesto errore merita una menzione: confondere il formato dei file. Un certificato in DER copiato dove serve PEM produce messaggi criptici come unable to load certificate. Quando un comando fallisce in modo incomprensibile, il primo sospetto è quasi sempre il formato o l’encoding del file.

Troubleshooting: 8 problemi frequenti e soluzioni

Quando un comando OpenSSL non si comporta come previsto, questa tabella copre gli scenari più comuni che incontrerai nel 2026.

ProblemaCausa probabileSoluzione
unable to load Private KeyFormato errato o file cifratoVerifica con openssl pkey -in chiave -text
error:0308010C: unsupportedAlgoritmo legacy nella serie 3.xAggiungi -provider legacy
Il browser rifiuta il .p12Cifratura troppo modernaRiesporta con il flag -legacy
unable to get local issuerCatena CA incompletaConcatena i certificati intermedi nel file
CN mismatch nel browserSAN mancantiRigenera con subjectAltName
s_client resta appesoManca input da stdinAggiungi < /dev/null
bad decryptParametri enc diversi tra cifra e decifraUsa gli stessi flag -pbkdf2 -iter
Versione vecchia su macOSOpenSSL di sistema datatoAnteponi il percorso Homebrew al PATH

L’errore 0308010C unsupported è il più frequente dopo l’aggiornamento alla serie 3.x e disorienta molti. Significa che stai chiedendo a OpenSSL un algoritmo spostato nel legacy provider, come RC4 o un vecchio PKCS#12. La soluzione è caricare il provider esplicitamente:

openssl enc -aes-128-cbc -provider legacy -provider default ...

Quando una catena di certificati non viene validata, usa openssl verify -show_chain (disponibile dalla serie 3.x) per vedere esattamente dove si interrompe la fiducia. Mostra ogni anello e indica quale manca, trasformando un errore opaco in una diagnosi precisa.

Tecniche avanzate per utenti esperti

Una volta padroneggiate le basi, OpenSSL offre funzioni che fanno la differenza in produzione. La prima è il controllo OCSP per verificare in tempo reale se un certificato è stato revocato:

openssl ocsp -issuer ca.pem -cert server.pem \
  -url http://ocsp.esempio.it -text

La seconda è il benchmark delle prestazioni crittografiche del tuo hardware, utile per dimensionare un server TLS ad alto traffico:

# Confronta la velocità di firma RSA vs ECDSA
openssl speed rsa3072 ecdsap256

I risultati mostrano in modo chiaro quante firme al secondo regge ciascun algoritmo, e di solito ECDSA stravince su RSA. La terza tecnica riguarda la generazione di parametri Diffie-Hellman personalizzati, anche se con TLS 1.3 e le curve moderne sono ormai meno necessari. Infine, considera l’orizzonte post-quantistico: OpenSSL sta integrando algoritmi resistenti ai computer quantistici come ML-KEM (basato su Kyber). Per capire l’impatto di questa transizione sul web, leggi la nostra analisi della crittografia moderna e delle sue evoluzioni.

Best practice di sicurezza per il 2026

Le scelte crittografiche invecchiano. Quello che era sicuro nel 2015 oggi è debole, e quello che usi oggi andrà rivisto. Queste linee guida riflettono lo stato dell’arte di metà 2026, in linea con le raccomandazioni del NIST nella pubblicazione SP 800-57 e con le indicazioni dell’agenzia europea ENISA.

  • Usa ECDSA P-256 o Ed25519 per le nuove chiavi; riserva RSA 3072 ai casi che richiedono compatibilità universale.
  • Firma sempre con SHA-256 o superiore. SHA-1 e MD5 non vanno mai usati per le firme.
  • Imponi TLS 1.3 dove possibile e disabilita TLS 1.0 e 1.1, ormai obsoleti e vietati dagli standard di settore come PCI DSS.
  • Proteggi le chiavi private con permessi 600 e, dove possibile, con un modulo hardware (HSM) o un secure enclave.
  • Ruota i certificati con anticipo: durate brevi e rinnovo automatico riducono la finestra di rischio.
  • Aggiorna OpenSSL alla serie LTS supportata: dopo il 7 settembre 2026 la serie 3.0 non riceverà più alcuna correzione di sicurezza.

La crittografia non è un’impostazione che configuri una volta e dimentichi. È un processo. La maggior parte delle violazioni legate a TLS non nasce da algoritmi rotti, ma da certificati scaduti, chiavi esposte e versioni non aggiornate. Automatizza il monitoraggio della scadenza, conserva le chiavi con cura e rivedi le tue scelte ogni anno. Per il contesto più ampio sulle minacce e sulla difesa, consulta la nostra guida sulla sicurezza delle password e sulle violazioni di dati.

Domande frequenti su OpenSSL

Qual è la versione di OpenSSL da usare nel 2026?

La serie OpenSSL 3.5 LTS, rilasciata nell’aprile 2025, è la scelta consigliata per la produzione perché supportata fino al 2030. Se usi ancora la serie 3.0 LTS, pianifica l’aggiornamento: il suo supporto di sicurezza termina il 7 settembre 2026. Evita la serie 1.1.1, in fine vita dal settembre 2023.

Meglio RSA o le curve ellittiche per un nuovo certificato?

Per la maggior parte dei nuovi progetti, ECDSA P-256 è la scelta migliore: stessa sicurezza di RSA 3072 con chiavi più piccole e handshake più veloci. Usa RSA solo quando devi supportare sistemi legacy che non gestiscono le curve ellittiche.

Perché il browser mostra un avviso con il mio certificato self-signed?

Un certificato autofirmato non è emesso da una Certificate Authority riconosciuta, quindi il browser non si fida. Per ambienti interni, crea una CA locale (Step 6) e importa il suo certificato radice nello store di fiducia dei dispositivi. Per siti pubblici, usa Let’s Encrypt.

Come risolvo l’errore “unsupported” dopo l’aggiornamento a OpenSSL 3?

Quell’errore (codice 0308010C) indica un algoritmo legacy spostato fuori dal percorso predefinito nella serie 3.x. Carica il provider esplicitamente con -provider legacy -provider default, oppure migra a un algoritmo moderno come AES-256.

OpenSSL è abbastanza sicuro per cifrare file importanti?

Sì, se usi AES-256 con -pbkdf2 -iter 600000. Senza questi parametri la derivazione della chiave è debole. Per esigenze più complete (contenitori cifrati, negabilità) valuta strumenti dedicati come VeraCrypt, ma per script e backup automatizzati OpenSSL è adeguato.

Quanto deve durare un certificato TLS?

Per i certificati pubblici la tendenza del settore va verso durate sempre più brevi, con rinnovo automatico. Per le CA radice interne sono comuni durate di 5-10 anni. Durate brevi riducono la finestra di rischio se una chiave viene compromessa.

OpenSSL supporta la crittografia post-quantistica?

Le versioni recenti stanno integrando algoritmi resistenti ai computer quantistici come ML-KEM (basato su Kyber), standardizzati dal NIST nel 2024. La transizione è in corso e nei prossimi anni questi algoritmi affiancheranno gradualmente RSA ed ECDSA negli handshake TLS.

Fonti autorevoli: OpenSSL Project, documentazione ufficiale OpenSSL, calendario end-of-life OpenSSL, NIST SP 800-57 e RFC 8446 (TLS 1.3).