Un certificato SSL è un certificato digitale che permette al browser di verificare l’identità crittografica del server a cui si sta collegando e di stabilire una connessione HTTPS protetta. Il nome “SSL” è rimasto nel linguaggio comune, ma sul Web moderno il protocollo utilizzato è TLS (Transport Layer Security): SSL è ormai una tecnologia legacy.
Questa distinzione non è solo terminologica. Il certificato, TLS e HTTPS svolgono ruoli diversi: il certificato collega un dominio a una chiave pubblica e a una catena di fiducia; TLS negozia e protegge la sessione; HTTPS è HTTP trasportato dentro quel canale cifrato. Per chi gestisce il sito, significa che installare il certificato è solo il primo passaggio: l’intera configurazione deve poi usare HTTPS in modo coerente.
Per chi gestisce un sito, il punto pratico è semplice: HTTPS deve essere lo stato normale dell’intero sito, non soltanto delle pagine di login o checkout. Ma avere un certificato valido non significa automaticamente che il sito sia affidabile, privo di malware o ben configurato. Per capire davvero cosa protegge, conviene separare questi concetti.
Cos’è SSL e cosa significa oggi “certificato SSL”
SSL significa Secure Sockets Layer ed è il predecessore di TLS. Per anni “SSL” è diventato il termine commerciale e colloquiale usato per indicare la protezione crittografica delle connessioni web; per questo si parla ancora di “certificato SSL”, “SSL del sito” o “attivare SSL”, anche quando tecnicamente il server sta usando TLS.
Le raccomandazioni IETF per l’uso sicuro di TLS vietano la negoziazione di SSLv2, SSLv3, TLS 1.0 e TLS 1.1. TLS 1.2 resta supportato, mentre TLS 1.3 è la versione preferita quando disponibile. Quindi, se un pannello hosting ti mostra la voce “SSL”, nella maggior parte dei casi sta usando un’etichetta storica per una configurazione TLS moderna.
SSL vs TLS: perché continuiamo a chiamarlo certificato SSL
SSL e TLS non sono due certificati diversi. Il certificato è un oggetto X.509; SSL e TLS sono protocolli di comunicazione.
La confusione nasce perché l’espressione “certificato SSL” si è affermata quando SSL era ancora il nome più conosciuto della tecnologia. Oggi “certificato TLS” sarebbe tecnicamente più preciso, ma “certificato SSL” resta perfettamente comprensibile e molto più diffuso nel linguaggio di hosting, browser, CMS e ricerche online.
In questa guida userò quindi “certificato SSL” quando mi riferisco al termine comune e “TLS” quando parlo del protocollo effettivamente utilizzato dalla connessione.
Cosa contiene un certificato TLS
Un certificato digitale non contiene la chiave privata del server. Contiene invece le informazioni necessarie per associare una chiave pubblica a uno o più nomi e per permettere al browser di verificare la firma e la catena di certificazione.
In una normale connessione HTTPS, tra i dati rilevanti puoi trovare:
- il dominio o i domini coperti dal certificato, normalmente indicati nei Subject Alternative Names (SAN);
- la chiave pubblica;
- l’autorità di certificazione che ha emesso il certificato;
- il periodo di validità;
- l’algoritmo e la firma digitale dell’emittente;
- estensioni e policy che descrivono come il certificato può essere utilizzato.
Lo standard di riferimento per il profilo dei certificati X.509 su Internet è RFC 5280. In pratica, il browser usa queste informazioni per verificare che il certificato presentato dal server sia adatto al dominio richiesto, non sia fuori dal periodo di validità e possa essere ricondotto a una Certification Authority considerata attendibile.
Come funziona un certificato SSL/TLS
Il certificato entra in gioco all’inizio della connessione, durante il TLS handshake. È il momento in cui browser e server si riconoscono, concordano i parametri crittografici e costruiscono le chiavi che verranno usate per proteggere la sessione.
Una precisazione è importante: nei protocolli moderni il browser non usa semplicemente la chiave pubblica del certificato per cifrare tutti i dati della navigazione. TLS combina meccanismi crittografici per autenticazione e key exchange con crittografia simmetrica per proteggere il traffico della sessione.
Il TLS handshake: cosa succede quando apri un sito HTTPS
Semplificando un handshake TLS moderno, la sequenza è questa:
- il browser contatta il server e comunica le versioni TLS, gli algoritmi e i parametri crittografici che supporta;
- il server sceglie una configurazione compatibile e presenta il proprio certificato;
- il browser controlla il dominio, la validità temporale e la catena di certificazione;
- client e server completano lo scambio crittografico e derivano chiavi di sessione condivise;
- una volta concluso l’handshake, il traffico applicativo viene protetto con quelle chiavi.
La specifica TLS 1.3 separa autenticazione, negoziazione dei parametri, derivazione delle chiavi e protezione dei record. Questo è il motivo per cui descrivere SSL come “la chiave pubblica cifra tutto e la chiave privata decifra tutto” porta a un modello mentale sbagliato.
Crittografia, autenticazione e integrità: tre funzioni diverse
TLS protegge una connessione su tre piani che spesso vengono confusi.
Confidenzialità. Il contenuto scambiato dopo l’instaurazione della sessione non deve essere leggibile da un osservatore che intercetta il traffico.
Autenticazione. Il browser deve poter verificare che il server dimostri il possesso della chiave privata associata al certificato e che il certificato sia valido per il nome richiesto. Nella normale navigazione web viene autenticato il server; l’autenticazione del client tramite certificato è possibile, ma non è il caso tipico di un sito pubblico.
Integrità. Un attaccante che modifica i dati durante il transito non dovrebbe poterlo fare senza che l’alterazione venga rilevata.
Questi tre livelli spiegano meglio il valore di HTTPS rispetto alla sola idea di “nascondere le password”. TLS protegge pagine, cookie, richieste, risposte e altri dati mentre viaggiano tra browser e server.
Cosa garantisce un certificato SSL e cosa non garantisce
Un certificato valido permette di instaurare un canale HTTPS autenticato e cifrato verso il dominio indicato. Non è però un bollino generale di qualità o affidabilità del sito.
È una distinzione importante perché un sito di phishing può ottenere un certificato valido per il proprio dominio. In quel caso la connessione tra il tuo browser e il dominio di phishing può essere perfettamente cifrata: semplicemente stai comunicando in modo sicuro con il sito sbagliato.
HTTPS protegge la connessione, non certifica che un sito sia affidabile
Quando il browser accetta un certificato, sta verificando principalmente che la connessione soddisfi i requisiti tecnici di autenticazione e trust previsti per quel dominio. Non sta certificando che:
- il proprietario del sito sia onesto;
- i prodotti venduti verranno consegnati;
- il sito non contenga malware;
- il software lato server sia privo di vulnerabilità;
- l’account utente sia protetto da password deboli;
- il sito rispetti automaticamente GDPR, PCI DSS o altre normative e standard.
HTTPS è quindi necessario, ma non sufficiente per la sicurezza complessiva di un sito.
Perché il lucchetto non è più il segnale da cercare in Chrome
Per molti anni il modo più semplice per riconoscere HTTPS era cercare il lucchetto nella barra degli indirizzi. Quel modello oggi è superato.
Chrome ha sostituito il lucchetto con un’icona più neutrale proprio perché molti utenti interpretavano il simbolo come prova che il sito fosse affidabile. Nel post del Chromium team sul cambiamento dell’icona viene spiegato che HTTPS indica un canale sicuro verso il sito, non la bontà del sito stesso.
Per una verifica pratica conviene quindi controllare l’URL https://, eventuali avvisi del browser e, se necessario, aprire le informazioni sulla connessione e sul certificato. Se il browser mostra un errore di certificato, non ignorarlo alla cieca: dominio errato, certificato scaduto o catena non valida possono impedire la corretta autenticazione del server.
Tipi di certificati SSL: DV, OV, EV, Wildcard e multi-dominio
Quando si confrontano i certificati SSL è utile separare due criteri diversi: come viene verificato il richiedente e quali nomi può coprire il certificato.
DV, OV ed EV descrivono il livello e il tipo di validazione dell’identità. Single Domain, Wildcard e multi-dominio descrivono invece l’insieme dei nomi host coperti. Mescolare le due classificazioni porta facilmente a confronti sbagliati.
DV, OV ed EV: cambia la validazione, non la forza della cifratura
Un certificato DV (Domain Validation) dimostra che il richiedente controlla il dominio. Non afferma un’identità organizzativa. È il modello usato, per esempio, dai certificati gratuiti di Let’s Encrypt.
Un certificato OV (Organization Validation) aggiunge informazioni sull’organizzazione dopo verifiche dell’identità del soggetto richiedente.
Un certificato EV (Extended Validation) applica requisiti di verifica dell’entità più estesi rispetto a OV.
Il registro delle policy del CA/Browser Forum distingue esplicitamente DV come certificato senza identità dell’entità dichiarata e OV come certificato in cui l’identità dell’organizzazione è dichiarata. Questa differenza riguarda ciò che la CA verifica prima dell’emissione, non un presunto “HTTPS più cifrato”.
Un DV e un OV possono utilizzare gli stessi protocolli e algoritmi TLS. Per un normale sito informativo o WordPress, quindi, pagare un certificato OV o EV non rende automaticamente più forte la cifratura della connessione. La scelta ha senso quando serve un livello diverso di verifica dell’identità organizzativa o quando esistono requisiti specifici del progetto.
Single Domain, Wildcard e SAN: cosa può coprire il certificato
Un certificato Single Domain è pensato per uno specifico insieme limitato di nomi indicati nel certificato. La copertura reale va sempre verificata nei SAN, senza presumere che example.com e www.example.com siano automaticamente equivalenti se non sono entrambi presenti.
Un certificato Wildcard può coprire più host di primo livello sotto lo stesso dominio, per esempio blog.example.com, shop.example.com e app.example.com, tramite un nome come *.example.com. Non è però un jolly infinito: secondo RFC 9525, il wildcard può occupare solo l’etichetta più a sinistra e corrisponde a un solo livello, quindi non copre automaticamente a.b.example.com.
Un certificato multi-dominio, spesso indicato come SAN certificate, può includere più nomi distinti nello stesso certificato. È utile quando una stessa infrastruttura deve servire domini o host differenti e si vuole gestirli con un unico certificato.
La scelta dipende quindi dall’architettura reale: per un singolo sito non serve complicare la gestione; per molte sottosezioni o servizi, invece, il modo in cui vengono organizzati i SAN può incidere parecchio sulla manutenzione.
SSL, HTTPS e SEO: cosa conferma davvero Google
HTTPS è importante anche nel contesto SEO, ma va evitata una semplificazione molto comune: installare un certificato non è una scorciatoia per migliorare il ranking.
Google annunciò HTTPS come segnale di ranking già nel 2014, definendolo allora un segnale leggero. La documentazione corrente sulla page experience in Google Search include la pubblicazione sicura delle pagine tra gli aspetti da controllare, ma chiarisce anche che non esiste un singolo “page experience signal” capace da solo di determinare il ranking.
La conclusione pratica è meno spettacolare ma più utile: usa HTTPS perché è lo standard corretto per proteggere la navigazione e perché una buona esperienza web deve partire da una connessione sicura. Non aspettarti che il semplice passaggio da HTTP a HTTPS compensi contenuti deboli, intent non soddisfatto, problemi tecnici o scarsa autorevolezza.
HTTPS e ranking: cosa sappiamo e cosa non significa
Possiamo separare i claim in modo pulito:
- GOOGLE_CONFIRMED: HTTPS è stato introdotto storicamente come segnale di ranking leggero;
- GOOGLE_CONFIRMED: Google raccomanda che le pagine siano servite in modo sicuro;
- GOOGLE_CONFIRMED: la page experience viene valutata attraverso più aspetti;
- NON SUPPORTATO: “installare SSL migliora automaticamente la SEO”;
- NON SUPPORTATO: “un sito con HTTPS è considerato affidabile da Google in senso generale”.
Questa distinzione è utile anche quando fai un audit: se il sito è ancora in HTTP, la migrazione va fatta. Ma una volta raggiunta una configurazione HTTPS corretta, il lavoro SEO si sposta altrove.
Passare da HTTP a HTTPS senza creare problemi SEO
La migrazione non consiste soltanto nell’installare il certificato. Devi assicurarti che la versione HTTPS diventi la versione coerente e raggiungibile del sito. Google tratta esplicitamente il passaggio da HTTP a HTTPS come un site move con cambio di URL, quindi redirect e segnali di canonicalizzazione vanno gestiti con attenzione.
In particolare, controlla redirect da HTTP a HTTPS, URL canonici, link interni, sitemap, risorse statiche e varianti www/non-www. La guida dedicata a HTTP vs HTTPS approfondisce le differenze fra i due protocolli; su WordPress, invece, conviene seguire una procedura specifica per evitare redirect incoerenti e risorse ancora caricate in HTTP.
Come verificare se un certificato SSL/TLS è valido
Vedere https:// nell’URL è un primo controllo, ma non basta per diagnosticare la qualità della configurazione TLS.
Dal browser puoi aprire le informazioni sulla connessione e verificare almeno il dominio del certificato, l’autorità emittente e le date di validità. Per un controllo tecnico più completo conviene analizzare anche catena di certificazione, protocolli supportati, cipher suite e configurazione del server.
Dominio, autorità di certificazione, validità e catena di trust
Un certificato può essere presente e comunque generare errori. Le cause tipiche includono:
- certificato scaduto o non ancora valido;
- dominio richiesto non presente tra i nomi coperti;
- certificato intermedio mancante;
- Certification Authority non considerata attendibile dal client;
- server configurato con una catena incompleta;
- orologio del dispositivo molto fuori sincronia;
- incompatibilità nella negoziazione TLS.
Il browser ricostruisce una catena di fiducia dal certificato del sito verso una CA radice presente nel proprio trust store. Se il percorso non può essere verificato correttamente, il certificato può risultare non attendibile anche se il file è tecnicamente installato sul server.
Controllare la configurazione TLS con SSL Labs
Per un sito pubblico, SSL Labs Server Test è uno degli strumenti più utili per analizzare la configurazione esposta dal server. Controlla il certificato, la catena, i protocolli, diverse classi di client e numerosi aspetti della configurazione TLS.
Il voto sintetico è utile per orientarsi, ma non va trattato come un obiettivo isolato. Il risultato importante è capire perché una configurazione fallisce: protocollo obsoleto, catena incompleta, certificato non valido, compatibilità o altra impostazione del server.
Come ottenere e rinnovare un certificato SSL
Oggi molti hosting gestiti includono l’emissione e il rinnovo del certificato direttamente dal pannello. In altri ambienti puoi usare una Certification Authority e un client ACME per automatizzare il processo.
Per un sito standard, l’obiettivo non è “comprare il certificato più costoso”, ma ottenere un certificato appropriato, riconosciuto dai client che ti interessano e soprattutto rinnovato in modo affidabile prima della scadenza.
Certificati gratuiti e a pagamento: cosa cambia davvero
Un certificato gratuito non significa cifratura debole. Let’s Encrypt, per esempio, è una Certification Authority pubblicamente attendibile che emette certificati DV. Nelle sue FAQ ufficiali specifica di offrire Domain Validation e non OV o EV.
La differenza di prezzo può dipendere da validazione dell’organizzazione, supporto commerciale, strumenti di gestione, garanzie contrattuali, workflow enterprise o servizi accessori. Non va invece presentata come una semplice scala “gratis = poco sicuro, costoso = molto sicuro”.
Per un sito WordPress tradizionale, dal punto di vista della connessione HTTPS, un DV correttamente emesso e gestito è normalmente sufficiente. Se il progetto richiede attestazione dell’identità dell’organizzazione o procedure aziendali specifiche, OV o EV possono avere un ruolo diverso.
Let’s Encrypt, Certbot e rinnovo automatico
Let’s Encrypt usa ACME per automatizzare la verifica del controllo del dominio e l’emissione dei certificati. I suoi certificati standard hanno una durata di 90 giorni, quindi l’automazione del rinnovo fa parte del modello operativo, non è un dettaglio opzionale. La documentazione corrente di Let’s Encrypt conferma che 90 giorni restano la durata predefinita, con certificati short-lived da sei giorni disponibili come opzione.
Certbot è uno dei client ACME più conosciuti. Può ottenere e installare certificati in diversi ambienti e, sulle installazioni supportate, predisporre il rinnovo automatico. Prima di considerare conclusa la configurazione conviene verificare che il job di rinnovo esista davvero e che possa completarsi senza intervento manuale.
Questo principio vale indipendentemente dal provider: un certificato che si rinnova automaticamente ma il cui rinnovo non viene mai verificato resta un possibile punto di rottura.
Perché la durata dei certificati TLS pubblici si sta riducendo
La gestione dei certificati sta diventando sempre più orientata all’automazione. I Baseline Requirements del CA/Browser Forum stabiliscono, per i certificati pubblici emessi dal 15 marzo 2026, un periodo massimo di validità di 200 giorni. Il limite passerà a 100 giorni dal 15 marzo 2027 e a 47 giorni dal 15 marzo 2029.
Questo non significa che tutti i certificati durino 200 giorni: è un massimo. Let’s Encrypt, per esempio, continua a usare certificati standard da 90 giorni. La conseguenza pratica è che affidarsi a rinnovi manuali diventa sempre meno sensato: monitoring e automazione sono parte della gestione TLS moderna.
Certificato SSL su WordPress: installazione e problemi più comuni
Su WordPress il certificato è soltanto il primo pezzo. Dopo l’emissione devi fare in modo che il sito usi davvero HTTPS in modo coerente: URL del sito, redirect, link interni, immagini, script, fogli di stile, API e risorse esterne devono smettere di dipendere da richieste HTTP non necessarie.
Per la procedura operativa completa puoi seguire la guida su come installare un certificato SSL e HTTPS su WordPress. Qui è più utile capire i due problemi che spesso compaiono dopo l’attivazione.
Attivare HTTPS senza duplicare la guida di installazione
La sequenza corretta dipende dal provider e dall’architettura, ma in generale devi:
- emettere e installare un certificato valido per tutti i nomi realmente usati;
- verificare che HTTPS risponda correttamente prima di forzare i redirect;
- aggiornare WordPress e le configurazioni applicative affinché usino gli URL HTTPS;
- reindirizzare le richieste HTTP verso la versione HTTPS corretta;
- correggere eventuali risorse ancora richiamate con URL HTTP;
- controllare sitemap, canonical e servizi esterni dopo la migrazione;
- verificare il rinnovo automatico del certificato.
Se salti il secondo passaggio e forzi HTTPS prima che il certificato e il virtual host siano correttamente funzionanti, puoi trasformare una migrazione semplice in un sito irraggiungibile.
Mixed content e SSL Handshake Failed: quando il certificato non basta
Il mixed content si verifica quando una pagina caricata in HTTPS continua a richiamare alcune risorse tramite HTTP. Il certificato della pagina può essere perfettamente valido, ma il browser vede comunque contenuti che non vengono caricati attraverso lo stesso canale protetto. In WordPress puoi seguire la procedura dedicata per correggere il contenuto misto.
Lo SSL Handshake Failed, invece, riguarda l’impossibilità di completare correttamente la negoziazione TLS. Le cause possono essere diverse: certificato scaduto, mismatch del dominio, problemi di catena, configurazioni incompatibili o errori lato client/server. Se incontri questo caso, la guida sull’errore SSL Handshake Failed entra nel troubleshooting specifico senza sovraccaricare questa pagina generale.
Se stai migrando un sito WordPress importante e non puoi permetterti errori su redirect, certificati o risorse miste, può essere più efficiente intervenire prima in staging o all’interno di una procedura di assistenza WordPress che consenta di verificare l’intera catena prima del passaggio definitivo.
Conclusione
Il termine SSL è ancora quello che trovi nei pannelli hosting e nelle ricerche, ma il modello corretto oggi è: certificato X.509 + TLS + HTTPS.
Il certificato collega il dominio a una chiave pubblica e a una catena di fiducia; TLS autentica il server, negozia le chiavi e protegge la sessione; HTTPS porta il traffico HTTP all’interno di quel canale sicuro. Questo protegge confidenzialità e integrità dei dati in transito, ma non trasforma automaticamente il sito in una fonte affidabile né sostituisce hardening, aggiornamenti, controllo degli accessi e sicurezza applicativa.
Per chi gestisce un sito, le priorità sono concrete: usare TLS moderno, coprire tutti i nomi necessari, mantenere una catena valida, automatizzare il rinnovo e controllare che l’intero sito utilizzi HTTPS senza mixed content o errori di handshake. Il certificato è un componente della sicurezza del sito, non la sicurezza del sito intero.