Tipi di certificato SSL: scegli quello giusto
Pubblicato il 30 settembre 2026
Il certificato SSL giusto svolge due funzioni contemporaneamente: crittografa il traffico tra un visitatore e il tuo server e presenta l’identità di cui i visitatori hanno bisogno per fidarsi. I tipi di certificato SSL differiscono principalmente per il modo in cui viene convalidata tale identità e per il numero di nomi host che coprono. Per la maggior parte dei siti, scegliere correttamente riguarda meno la crittografia e più l’adattamento della copertura e della convalida del certificato al modo in cui il servizio opera realmente.
Un piccolo sito vetrina, una pagina di pagamento, una piattaforma SaaS multi-tenant e un’agenzia che gestisce 40 domini di clienti possono utilizzare tutti gli stessi standard di crittografia TLS. Non dovrebbero però utilizzare automaticamente lo stesso certificato. Il servizio funziona meglio quando il piano dei certificati corrisponde al piano dell’infrastruttura.
Tipi di certificato SSL in base al livello di convalida
Il livello di convalida determina cosa verifica l’autorità di certificazione prima di emettere il certificato. Ogni certificato valido crittografa la connessione. La differenza sta nella quantità di verifica dell’identità effettuata e, in alcuni casi, nelle informazioni mostrate nei dettagli del certificato.
Certificati con convalida del dominio
Un certificato con convalida del dominio, o DV, conferma il controllo di un nome di dominio. L’autorità di certificazione di solito chiede di inserire un record DNS, caricare un file di verifica o approvare un’e-mail inviata a un indirizzo autorizzato. Una volta superata la verifica, l’emissione può essere molto rapida.
Il DV è la scelta pratica per blog, landing page, ambienti di sviluppo, API, strumenti interni esposti tramite un dominio e molti siti aziendali standard. Mostra ai visitatori il lucchetto HTTPS e crittografa credenziali, moduli, sessioni e altro traffico in transito.
Il compromesso è semplice: il DV non verifica l’azienda legale che sta dietro al sito web. Un visitatore può vedere che la connessione è crittografata e che il sito controlla il dominio, ma il certificato non fornisce un’identità dell’organizzazione verificata separatamente dall’autorità di certificazione. Per molte aziende è perfettamente adeguato.
Certificati con convalida dell’organizzazione
I certificati con convalida dell’organizzazione, o OV, richiedono che l’autorità di certificazione verifichi sia il controllo del dominio sia l’organizzazione che richiede il certificato. Normalmente ciò comporta la verifica dei dati di registrazione dell’azienda, delle informazioni sull’indirizzo e di un metodo di contatto confermato.
I certificati OV sono adatti ad aziende consolidate, portali B2B, siti di agenzie, piattaforme di approvvigionamento e aree clienti in cui l’identità dell’organizzazione è importante. Le informazioni verificate sull’organizzazione sono disponibili nei dettagli del certificato e possono supportare le discussioni di due diligence con clienti aziendali o team di sicurezza.
La crittografia non è più forte rispetto a quella DV solo perché il certificato è OV. La protezione TLS moderna dipende dalla configurazione del server, dalle versioni del protocollo supportate, dalle suite di cifratura e dal tipo di chiave del certificato. L’OV aggiunge un processo di garanzia dell’identità più rigoroso, non una crittografia magica aggiuntiva. È comunque utile, semplicemente non è stregoneria.
Certificati con convalida estesa
I certificati con convalida estesa, o EV, prevedono il processo di convalida più dettagliato. L’autorità di certificazione verifica l’esistenza legale dell’organizzazione, lo stato operativo, l’indirizzo fisico e il richiedente autorizzato secondo regole definite.
L’EV può essere appropriato per organizzazioni soggette a regolamentazione, servizi finanziari, marchi di commercio elettronico di alto valore e aziende con requisiti formali di approvvigionamento o conformità. Può essere richiesto anche da un partner che dispone di una propria checklist di sicurezza dei fornitori.
Per il sito web di una tipica piccola azienda, l’EV non è automaticamente il miglior investimento. I browser moderni non mostrano più l’indicazione altamente visibile nella barra degli indirizzi verde che un tempo distingueva l’EV agli occhi degli utenti comuni. Sceglilo quando il suo processo di convalida soddisfa una reale esigenza di fiducia, contrattuale o normativa, non perché ti aspetti un notevole aumento visivo delle conversioni.
Tipi di certificato SSL in base alla copertura dei domini
Dopo la convalida, la copertura è la decisione successiva. È qui che gli acquisti dei certificati vanno più spesso storti. Un certificato può essere valido e installato correttamente, ma non funzionare comunque per un nome host per il quale non è mai stato emesso per la protezione.
Certificati per un singolo dominio
Un certificato per un singolo dominio protegge un nome di dominio completo, ad esempio `www.example.com` o `app.example.com`. A seconda della configurazione del certificato, il dominio radice e la versione `www` potrebbero richiedere una copertura separata. Non dare mai per scontato che siano inclusi entrambi senza controllare i Subject Alternative Names del certificato, spesso chiamati SAN.
I certificati per un singolo dominio sono semplici e facili da gestire per un unico servizio. Sono adatti quando un’applicazione ha un nome host dedicato e un ciclo di rinnovo indipendente.
Certificati wildcard
Un certificato wildcard protegge un dominio e i suoi sottodomini di primo livello, come `shop.example.com`, `api.example.com` e `status.example.com`, utilizzando un nome come `*.example.com`. È utile per le piattaforme in cui i sottodomini vengono aggiunti regolarmente, comprese le distribuzioni delle agenzie, i portali clienti e gli ambienti SaaS in espansione.
C’è un limite che coglie molti di sorpresa: `*.example.com` non protegge `example.com` a meno che il dominio radice non sia incluso separatamente e non copre `east.api.example.com`. I wildcard coprono un solo livello di sottodominio. Non è la situazione DNS più bella da scoprire durante un lancio, quindi mappa i nomi host prima di ordinare il certificato.
I certificati wildcard richiedono comunemente la convalida basata su DNS perché dimostrare il controllo di un dominio wildcard necessita di una sfida DNS. Di solito è semplice quando l’accesso al DNS è organizzato, ma va considerato prima di selezionare un flusso di lavoro per il rinnovo automatico.
Certificati multidominio o SAN
Un certificato multidominio, chiamato anche certificato SAN, protegge diversi nomi host specifici in un unico certificato. Ad esempio, un certificato può coprire `example.com`, `www.example.com`, `app.example.net` e `customer.example.org`.
È utile per aziende che gestiscono più marchi, agenzie che ospitano servizi correlati per i clienti o team che necessitano di un unico certificato controllato per un gruppo definito di endpoint. Può ridurre la proliferazione dei certificati, ma crea anche una dipendenza condivisa. Se sostituisci o revochi quel certificato, ogni nome host coperto potrebbe essere interessato.
Negli ambienti di grandi dimensioni, separare i certificati per applicazione, unità aziendale o responsabile del rinnovo può essere più sicuro dal punto di vista operativo. Meno certificati non significa sempre meno lavoro quando una modifica ha un raggio d’impatto ampio.
Come scegliere il certificato giusto
Inizia dai nomi host, non dal nome del prodotto. Elenca ogni dominio pubblico, nome `www`, endpoint API, portale di amministrazione, endpoint relativo alla posta e sottodominio previsto che richieda TLS. Poi decidi se questi nomi sono fissi, se cresceranno in modo imprevedibile o se sono gestiti da team diversi.
Un certificato DV per un singolo dominio è di solito sufficiente per un sito web o un endpoint applicativo. Un certificato DV wildcard è spesso la risposta più sensata per un insieme in crescita di sottodomini di primo livello. Un certificato SAN funziona bene per una raccolta fissa di nomi distribuiti tra più domini. La convalida OV o EV rientra nella decisione quando la verifica dell’identità è richiesta dai clienti, dalle policy, dalle prassi del settore o dai termini contrattuali.
Considera anche l’ambiente che si trova dietro il certificato. Se il traffico termina presso un bilanciatore del carico, un proxy inverso, una CDN o un server web gestito, il certificato deve essere installato e rinnovato nel punto in cui termina TLS. Installarlo su un server backend non servirà se i visitatori si connettono prima a un proxy con un certificato scaduto.
Rinnovo, automazione e rischio operativo
Un certificato scaduto può interrompere gli accessi, i flussi di pagamento, le chiamate API e la fiducia del browser con un preavviso minimo per i clienti. Il rinnovo del certificato dovrebbe essere trattato come un’attività operativa, non come un promemoria sul calendario che qualcuno spera di notare durante un venerdì intenso.
Utilizza il rinnovo automatico quando il tipo di certificato e il metodo di convalida lo consentono. La convalida DNS è particolarmente utile per i certificati wildcard, ma l’automazione richiede un accesso sicuro ai record DNS. Limita attentamente tali credenziali e documenta chi ne è responsabile. Per la convalida basata su file, assicurati che reindirizzamenti, regole di caching, firewall per applicazioni web e pipeline di distribuzione non blocchino il percorso di verifica.
Dopo l’installazione o il rinnovo, verifica più del semplice lucchetto. Controlla la catena di certificati, i nomi coperti, la data di scadenza, il comportamento dei reindirizzamenti e l’endpoint TLS che serve effettivamente il traffico pubblico. Il monitoraggio dovrebbe generare avvisi con largo anticipo rispetto alla scadenza e verificare il nome host utilizzato dai clienti, non solo un indirizzo server interno.
Per i team che preferiscono non sostenere da soli questo carico operativo, il supporto per l’hosting gestito può aiutare con l’installazione dei certificati, i controlli dei rinnovi, la convalida DNS e il monitoraggio del servizio. Su kodu.cloud, l’obiettivo pratico non è rendere entusiasmanti i certificati. È mantenere disponibili i servizi crittografati mentre ti occupi del lavoro che paga le bollette.
Scegli l’ambito minimo del certificato che copra in modo affidabile i tuoi servizi reali, automatizza i rinnovi che puoi e lascia sufficiente visibilità perché una persona possa intercettare le eccezioni. La sicurezza funziona meglio quando è noiosa nel miglior modo possibile.
Andres Saar Ingegnere del supporto clienti