Guida ai tipi di certificati SSL

Pubblicato il 26 giugno 2026

La scelta del certificato di solito non è il problema. Il problema è abbinarlo al sito, al team e alla quantità di rischio operativo che vuoi sostenere. Questa guida ai tipi di certificati SSL ti aiuterà a tenere sotto controllo questa parte, così non finirai per acquistare una convalida aggiuntiva di cui non hai bisogno o, peggio, per distribuire un certificato che non copre l'hostname effettivamente utilizzato dalla tua applicazione.

SSL è ancora il nome comune che le persone usano, anche se i certificati moderni proteggono il traffico con TLS. I browser mostrano il lucchetto sulla connessione, gli utenti vedono HTTPS e il tuo server dimostra la propria identità tramite un certificato firmato. Il servizio torna tranquillo quando tutto è configurato correttamente. In caso contrario, ottieni avvisi del browser, chiamate API non riuscite, pagine di checkout non funzionanti e una coda di supporto che all'improvviso diventa molto animata.

Cosa copre davvero questa guida ai tipi di certificati SSL

Dentro l'acquisto di un certificato si nascondono due domande diverse. La prima è il livello di convalida: quanto controlla l'autorità di certificazione prima di emettere il certificato. La seconda è la copertura: quanti domini o sottodomini protegge il certificato. Sono aspetti collegati, ma non sono la stessa cosa.

Se separi queste due decisioni, l'intera categoria diventa più semplice. La convalida dice a utenti e sistemi chi sei. La copertura dice alla tua infrastruttura quali nomi sono protetti.

Livelli di convalida: DV, OV ed EV

Domain Validation, o DV

I certificati DV sono l'opzione più rapida e più comune. L'autorità di certificazione verifica solo che tu controlli il dominio. Questo controllo di solito avviene tramite email, record DNS o un file posizionato sul server web.

Per molti siti web, questo è sufficiente. Blog, siti vetrina, landing page, strumenti interni dietro login e molte interfacce front-end SaaS funzionano perfettamente con DV. La crittografia è robusta. La compatibilità con i browser è buona. La configurazione è rapida. Se il tuo requisito principale è un trasporto sicuro e nessun avviso del browser, DV fa il suo lavoro.

Il compromesso riguarda l'identità. Un certificato DV non dice molto ai visitatori sull'entità legale dietro il sito. Per una piccola azienda che ha già fiducia grazie al branding, ai segnali del provider di pagamento o a una base clienti consolidata, questo può essere accettabile. Per un sito in cui la fiducia pubblica è fragile, forse un po' meno.

Organization Validation, o OV

I certificati OV aggiungono la verifica aziendale al controllo del dominio. L'autorità di certificazione controlla l'organizzazione stessa, di solito confrontandola con registri pubblici o documentazione inviata. Questo significa più lavoro amministrativo e un'emissione più lenta, ma il certificato contiene informazioni di identità più solide.

OV tende ad avere senso per siti web aziendali, portali, dashboard clienti e servizi B2B in cui è importante dimostrare che dietro l'endpoint c'è una vera organizzazione. È anche un ragionevole compromesso per le agenzie che gestiscono progetti dei clienti che richiedono più della convalida minima indispensabile senza passare all'opzione con più attrito.

Il limite pratico è che la maggior parte degli utenti medi non controllerà i dettagli del certificato. Non applaudiranno perché hai acquistato OV. Il valore è più operativo e reputazionale che visivo. I team di sicurezza, i team acquisti e i clienti attenti alla conformità potrebbero tenerne conto. Gli acquirenti casuali, di solito no.

Extended Validation, o EV

I certificati EV comportano il processo di convalida più approfondito. L'autorità di certificazione verifica l'esistenza legale, la presenza operativa e il controllo del dominio usando controlli più rigorosi. Storicamente, EV aveva un effetto più marcato sull'interfaccia del browser. Oggi questo è meno evidente rispetto al passato, quindi la decisione di acquisto non dovrebbe basarsi su vecchi ricordi di marketing.

EV è ideale per i casi in cui conta la garanzia formale dell'identità: servizi finanziari, aziende regolamentate, alcune piattaforme rivolte alle imprese e organizzazioni con requisiti espliciti di conformità o fiducia. Se il tuo flusso di lavoro legale o di procurement richiede la massima convalida documentata, EV può ancora essere la risposta corretta.

Ma EV non è uno scudo magico. Non cifra il traffico meglio di DV o OV. Non ferma codice applicativo scadente, password deboli o backup scaduti. Dimostra di più su chi possiede il servizio, non che il servizio stesso sia progettato alla perfezione. Nessun certificato può sistemare un server di origine configurato male che ha una giornata strana.

Tipi di copertura: dominio singolo, wildcard e SAN

Una volta chiarita la convalida, la domanda successiva riguarda la copertura degli hostname.

Certificati per dominio singolo

Un certificato per dominio singolo protegge un solo nome di dominio completo. Se viene emesso per www.example.com, questo non copre automaticamente example.com a meno che entrambi i nomi siano inclusi. Questo coglie le persone impreparate più spesso di quanto dovrebbe.

I certificati per dominio singolo funzionano bene quando l'ambiente è semplice. Un sito, un hostname, uno scopo chiaro. Sono facili da gestire e spesso rappresentano l'opzione più economica. Per il sito web di una piccola azienda o un endpoint applicativo mirato, questa è di solito la strada più pulita.

Certificati wildcard

Un certificato wildcard protegge un livello di sottodomini sotto un dominio, ad esempio anything.example.com. Può coprire app.example.com, shop.example.com e api.example.com con un unico certificato.

È utile quando crei regolarmente sottodomini o gestisci molti servizi sotto lo stesso dominio padre. Agenzie, operatori SaaS e team di piattaforma interni spesso preferiscono i certificati wildcard perché riducono il lavoro di emissione ripetuto.

Il compromesso riguarda l'ambito. Un wildcard non copre il dominio radice a meno che non sia incluso esplicitamente, e non copre livelli più profondi come test.api.example.com a meno che quella struttura esatta non venga gestita separatamente. Inoltre, poiché un solo certificato può coprire molti servizi, la gestione della chiave privata diventa più sensibile. Se quella chiave viene copiata in giro con troppa generosità, la comodità inizia a diventare una responsabilità.

Certificati SAN o multi-dominio

SAN sta per Subject Alternative Name. Questi certificati possono proteggere più hostname distinti in un unico certificato, anche su domini diversi. Ad esempio, un certificato SAN potrebbe coprire example.com, example.net, shop.example.com e clientportal.org.

Questa è spesso la soluzione più adatta per aziende che gestiscono diverse proprietà con marchi diversi, ambienti Microsoft, infrastruttura condivisa o parchi domini gestiti da agenzie con insiemi di domini prevedibili. È ordinata dal punto di vista della gestione e in alcuni ambienti semplifica i rinnovi.

Ma anche i certificati SAN richiedono pianificazione. Se i domini cambiano spesso, se i clienti arrivano e se ne vanno, o se troppi servizi non correlati dipendono da un unico certificato, la comodità di gestione può diventare accoppiamento operativo. Una modifica per un hostname può obbligare alla riemissione e alla ridistribuzione per tutti. Non è un disastro, solo qualcosa in cui evitare di finire camminando nel sonno.

Quale tipo di certificato SSL si adatta a quale caso d'uso?

Per un sito web di base, un sito vetrina o un piccolo negozio, DV con copertura per dominio singolo è di solito sufficiente. Protegge il traffico, si distribuisce rapidamente e mantiene bassi i costi.

Per un'azienda in crescita con più sottodomini, un wildcard DV è spesso il miglior compromesso pratico. Ottieni un'ampia copertura senza un pesante carico di documentazione per la convalida. Funziona particolarmente bene per stack applicativi con sottodomini separati per web, API, staging e portali clienti.

Per servizi B2B, portali partner e sistemi aziendali rivolti ai clienti, OV spesso merita attenzione. Non perché i browser ne facciano un grande spettacolo, ma perché alcuni acquirenti e stakeholder interni vogliono un'identità organizzativa più chiara.

Per settori regolamentati, istituzioni pubbliche o contratti enterprise con requisiti formali di fiducia, EV può ancora essere la decisione giusta. La convalida aggiuntiva non riguarda solo l'apparenza. A volte è semplicemente ciò che l'ambiente si aspetta.

Per agenzie e team infrastrutturali che gestiscono molti hostname, i certificati SAN possono ridurre il carico amministrativo. Per i team che effettuano spesso il provisioning di sottodomini, wildcard può essere più semplice. Se esistono entrambi i modelli, dipende dal tipo di proliferazione che hai: molti marchi o molti sottodomini.

Errori comuni nella scelta dei tipi di certificato

Il primo errore comune è acquistare in base alla psicologia dei badge invece che ai requisiti reali. Una convalida più forte non significa una crittografia più forte. Significa più controlli sull'identità.

Il secondo è dimenticare la pianificazione degli hostname. I team proteggono il sito principale ma dimenticano www, il sottodominio API o il reindirizzamento del dominio radice. Poi metà dello stack è cifrata e l'altra metà crea problemi.

Il terzo è ignorare il flusso di lavoro di rinnovo e distribuzione. Un certificato non è un acquisto una tantum seguito da una pace permanente. Deve essere rinnovato, installato e a volte riemesso quando l'infrastruttura cambia. Se il team che gestisce il server è già al limite, scegliere un certificato con più carico manuale potrebbe non essere l'idea più gentile.

Il quarto è condividere troppo ampiamente le chiavi private wildcard tra gli ambienti. La comodità è piacevole finché dev, staging e produzione non conservano tutti lo stesso materiale sensibile in luoghi che nessuno traccia completamente. Non è il cugino della situazione DNS più bella del mondo, ma resta sotto controllo se gestito per tempo.

Un modo pratico per decidere

Parti dai requisiti di fiducia. Se nessun cliente, regolatore o processo di procurement richiede la convalida dell'identità aziendale, DV è probabilmente sufficiente. Poi mappa i tuoi hostname. Se hai un solo sito, scegli dominio singolo. Se hai molti sottodomini sotto un unico dominio padre, considera wildcard. Se hai diversi domini non correlati, guarda SAN.

Dopodiché, pensa alle operazioni. Chi rinnova il certificato? Dove viene conservata la chiave privata? Quanti server o container richiedono la distribuzione? La tua architettura cambierà tra sei mesi? Un certificato leggermente più costoso che si adatta in modo pulito al tuo ambiente è spesso più economico di uno a basso costo che causa lavoro manuale ripetuto.

Per le aziende che usano infrastruttura gestita, è qui che un provider come kodu.cloud può togliere un po' di stress. Non facendo sparire la logica dei certificati, ma evitando che distribuzione, rinnovi e gestione lato server diventino un hobby delle 2 di notte. hobby.

Considerazione finale

Il tipo di certificato giusto è quello che copre i tuoi hostname reali, corrisponde alle tue esigenze di fiducia e non crea rumore operativo extra per il tuo team. Se la configurazione del certificato permette ai tuoi utenti di connettersi in sicurezza e a te di dormire un po' meglio, è già ottima ingegneria.

Andres Saar, Ingegnere dell'assistenza clienti