Tipi di certificati SSL e livelli di validazione spiegati

Quando si parla di certificati SSL, il punto non è “avere il lucchetto”, ma capire cosa sta attestando il certificato e quanto puoi fidarti del dominio che lo presenta. Nel mondo reale, la scelta tra DV, OV ed EV non cambia solo il livello di verifica iniziale: incide su gestione operativa, onboarding dei domini, rotazione, copertura dei sottodomini e su come il team interpreta gli avvisi del browser. Se tratti tutti i certificati come equivalenti, prima o poi ti ritrovi con un rinnovo che rompe un host secondario, un SAN dimenticato o un wildcard usato dove serviva un nome esplicito.

Il protocollo corretto da chiamare oggi è TLS, non SSL, ma nella pratica l’espressione “certificato SSL” resta comune. Il certificato serve a legare una chiave pubblica a un’identità. Quello che cambia tra i vari tipi è quale identità viene verificata dall’autorità di certificazione e con quale profondità di controllo. Il browser non vede “più sicurezza” solo perché il certificato è più costoso: vede una catena valida, un nome coerente e una fiducia costruita secondo regole precise.

La distinzione che conta davvero: chi stai validando

I certificati si dividono in tre famiglie principali in base al livello di validazione:

1. DV (Domain Validation): viene verificato il controllo del dominio.
2. OV (Organization Validation): viene verificato il dominio e l’esistenza dell’organizzazione richiedente.
3. EV (Extended Validation): viene verificata l’organizzazione con controlli più stringenti e procedure più rigide.

La differenza operativa non è accademica. Un DV si emette velocemente, spesso con challenge DNS o HTTP. Un OV richiede dati societari coerenti e verificabili. Un EV introduce controlli più severi, ma nel browser moderno l’effetto visivo è molto meno spettacolare rispetto a qualche anno fa. Per questo, scegliere EV solo “per sembrare più sicuri” è un errore di impostazione: la sicurezza reale sta nella gestione delle chiavi, nella copertura dei nomi e nella corretta automazione del rinnovo.

DV: il livello minimo, utile e spesso sufficiente

Il certificato Domain Validation dimostra che controlli il dominio. L’CA non sta certificando la tua azienda, il tuo brand o la tua reputazione: sta solo verificando che chi richiede il certificato abbia dimostrato il possesso del nome DNS. È il formato più usato per siti web, API, pannelli e servizi interni esposti su Internet.

Nel lavoro quotidiano, DV è la scelta naturale quando hai bisogno di automatizzare. Con ACME e challenge DNS puoi rinnovare senza intervento umano, riducendo il rischio di scadenza. Questo è il motivo per cui molti stack moderni, da reverse proxy a cluster containerizzati, usano DV anche in ambienti di produzione. La fiducia del browser non cambia, perché per la cifratura e per l’autenticazione del server basta un certificato valido per il nome giusto.

Il limite del DV non è tecnico, è semantico: chi visita il sito non riceve alcuna informazione sull’organizzazione che c’è dietro. Se gestisci un portale istituzionale, un e-commerce o un servizio che richiede fiducia esplicita, questo dettaglio può contare in termini di percezione e processi di compliance, ma non va confuso con la sicurezza crittografica del canale.

OV: quando serve associare il dominio a un soggetto reale

Un certificato Organization Validation aggiunge la verifica dell’ente che richiede il certificato. L’autorità controlla che l’organizzazione esista, che i dati siano coerenti e che la richiesta sia legittima. In pratica, oltre al dominio, viene attestata una relazione con una ragione sociale verificabile.

Questo livello è utile quando vuoi separare i siti di brand diversi, i portali corporate, i pannelli riservati e i servizi esposti da un’entità aziendale chiara. Anche qui, il certificato non “migliora la cifratura” rispetto a un DV: la crittografia è la stessa. Cambia la qualità dell’identità associata al certificato e, di riflesso, il tipo di documentazione che puoi esibire in audit o in processi interni.

Operativamente, l’OV richiede più disciplina. Devi avere dati aziendali aggiornati, intestazioni coerenti, riferimenti amministrativi raggiungibili e spesso una gestione più attenta dei ruoli. Se il team cambia spesso o se il dominio passa da un fornitore all’altro, l’OV può introdurre attrito nei rinnovi. È un costo organizzativo, non un problema del protocollo.

EV: controllo più rigoroso, vantaggio pratico limitato

I certificati Extended Validation prevedono verifiche aggiuntive sull’identità legale dell’organizzazione e sul diritto a richiedere il certificato. Storicamente erano associati a una maggiore evidenza visiva nel browser, ma quel segnale è stato molto ridimensionato. Oggi il valore dell’EV è più documentale che percettivo.

In alcuni contesti regolati, l’EV può ancora essere richiesto o preferito per policy interne, soprattutto quando la governance vuole un processo di emissione più controllato. Però va detto chiaramente: se il tuo obiettivo è proteggere utenti e sessioni, l’EV non sostituisce MFA, hardening del server, protezione delle chiavi private o monitoraggio dei rinnovi. È un tassello di conformità, non una scorciatoia per la sicurezza end-to-end.

Wildcard, SAN e certificati singoli: scegliere la copertura giusta

La validazione non è l’unico asse di scelta. Devi considerare anche quali nomi DNS il certificato deve coprire.

1. Certificato singolo: copre un solo FQDN, per esempio www.example.com.
2. SAN certificate: copre più nomi nello stesso certificato, per esempio example.com, www.example.com, api.example.com.
3. Wildcard: copre un livello di sottodomini, per esempio *.example.com.

Il wildcard è comodo, ma non è una bacchetta magica. Copre app.example.com, non deep.app.example.com. Inoltre, se la chiave privata del wildcard viene compromessa, il danno potenziale è più ampio perché il certificato vale per molti host. In ambienti con più team o più piattaforme, un SAN ben progettato può essere più ordinato di un wildcard usato come soluzione universale.

Un errore classico è emettere un certificato per il dominio principale e dimenticare endpoint secondari come mail., cpanel., autodiscover. o host di API. Il problema emerge solo al momento del deploy o, peggio, al rinnovo automatico quando il servizio riparte con il nome sbagliato. La regola pratica è semplice: prima inventari i nomi effettivamente in uso, poi scegli il tipo di copertura. Non il contrario.

Catena di fiducia: il certificato non basta da solo

Un certificato valido deve arrivare con la catena completa fino alla root trusted dal client. Se il server espone solo il leaf e manca l’intermediate, alcuni client riescono a ricostruire la catena, altri no. Il risultato è il classico errore intermittente: funziona sul browser dell’operatore, fallisce su un dispositivo mobile o su un vecchio client Java.

Per verificare la catena esposta da un server, un controllo rapido è questo:

openssl s_client -connect example.com:443 -servername example.com -showcerts

Se vuoi verificare in modo più concreto il certificato servito, controlla soggetto, issuer e date di scadenza. Un esempio utile:

openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Qui cerchi tre cose: il nome corrisponde all’host, l’issuer è quello atteso, la scadenza è lontana abbastanza da lasciare margine di rinnovo. Se il certificato è corretto ma il server non presenta la catena completa, il problema è nella configurazione del web server o del load balancer, non nell’authority.

Come riconoscere i casi d’uso senza farsi ingannare dal marketing

La scelta corretta dipende dal contesto. Un blog, un’API pubblica e una landing page possono stare tranquillamente su DV. Un portale corporate con obblighi documentali può richiedere OV. Un EV ha senso solo se una policy o un processo di governance lo rende utile davvero.

La domanda giusta non è “quale certificato è più sicuro?”, ma “quale livello di validazione serve per questo servizio e con quale complessità operativa?”. Se gestisci decine di host, la semplicità del rinnovo conta più del prestigio del badge. Se hai un perimetro regolato, la tracciabilità del richiedente e la qualità dei dati organizzativi diventano più rilevanti.

Un esempio pratico: per un cluster di reverse proxy che termina TLS su molti nomi, un DV con ACME e SAN ben progettato è spesso la scelta più robusta. Per il sito istituzionale di una società che deve dimostrare la propria identità nei processi di audit, un OV può essere più coerente. L’EV va valutato quando c’è un requisito esplicito, non come decorazione.

Emissione e rinnovo: dove si fanno gli errori veri

La maggior parte dei problemi non nasce dalla crittografia, ma dalla gestione operativa. I punti più fragili sono sempre gli stessi: DNS non aggiornato, challenge ACME che fallisce, hostname mancanti, catena incompleta, chiavi private archiviate male o rinnovi lasciati a una scadenza manuale.

Per un’emissione via ACME, il flusso tipico è questo:

1. Verifica che il nome DNS punti al servizio corretto.
2. Decidi se usare challenge HTTP-01, DNS-01 o TLS-ALPN-01.
3. Conferma che i nomi da coprire siano tutti presenti nel certificato.
4. Automatizza il rinnovo e il reload del servizio.
5. Controlla che il servizio esponga la catena completa dopo il rinnovo.

Per esempio, con Certbot su un server Nginx, il check post-rinnovo deve includere un reload e una verifica effettiva del certificato servito, non solo la riuscita del comando di rinnovo. Un controllo minimale può essere:

sudo certbot renew --dry-run

Il dry-run dice se il processo è ancora valido, ma non sostituisce un test reale sul virtual host e sui nomi DNS pubblici. Se usi wildcard via DNS-01, il rischio operativo si sposta sulla sicurezza delle credenziali DNS API: vanno limitate, ruotate e conservate fuori dal repository.

Che cosa guardare nel certificato, oltre alla scadenza

La data di scadenza è solo un indicatore. I campi davvero utili sono questi:

• Subject: identifica il nome principale del certificato.
• SAN: elenca i nomi coperti realmente.
• Issuer: indica l’autorità che lo ha emesso.
• Not Before / Not After: definiscono la finestra di validità.
• Key Usage e Extended Key Usage: dicono per cosa il certificato è autorizzato.

Se il certificato è stato emesso correttamente ma il servizio continua a presentare un nome errato, spesso stai guardando il file giusto nel posto sbagliato, oppure il reverse proxy sta servendo un’altra configurazione per via di SNI o di un vhost di default. In questi casi la verifica con openssl s_client è più affidabile del solo controllo del file locale, perché ti dice cosa vede davvero il client remoto.

Checklist operativa per non sbagliare scelta

1. Inventaria i nomi DNS esposti pubblicamente e quelli usati dai client.
2. Decidi il livello di validazione in base a requisito reale, non a percezione.
3. Scegli tra certificato singolo, SAN o wildcard in base alla topologia.
4. Automatizza emissione e rinnovo, soprattutto in produzione.
5. Verifica sempre catena, nome, scadenza e comportamento dopo il reload.

Se il contesto è pubblico e standard, DV è spesso la risposta più pulita. Se devi associare il dominio a un soggetto aziendale verificabile, OV è il passaggio naturale. EV serve solo quando c’è un motivo concreto per sostenere quel livello di validazione. Tutto il resto è rumore.

In pratica, i “tipi di certificati SSL” non sono una scala di sicurezza lineare. Sono strumenti diversi per esigenze diverse. La sicurezza del canale la fa TLS con una configurazione corretta; la qualità dell’identità la fa il livello di validazione; la stabilità operativa la fa l’automazione. Se tieni separati questi tre piani, scegli meglio e rompi meno cose al rinnovo.