Let’s Encrypt: cos’è, come funziona e quando usare i certificati gratuiti

Let’s Encrypt è una Certification Authority gratuita e automatizzata che emette certificati TLS Domain Validation, o DV. In pratica permette a un sito di utilizzare HTTPS senza pagare il certificato e, soprattutto, consente di automatizzare emissione e rinnovo attraverso il protocollo ACME.

La parte “gratuita” è quella che ha reso Let’s Encrypt popolare, ma non è la caratteristica più importante per capire quando usarlo. Il vero cambio di modello è l’automazione: invece di trattare il certificato come qualcosa da acquistare, installare e ricordarsi di rinnovare una volta ogni tanto, Let’s Encrypt è progettato per far gestire il ciclo di vita del certificato a software e infrastruttura.

Per questo un certificato SSL gratuito non è automaticamente un certificato “meno sicuro” di uno a pagamento. Bisogna separare la qualità della connessione TLS dal livello di verifica dell’identità effettuato dalla Certification Authority. Let’s Encrypt verifica il controllo del dominio; non offre certificati OV o EV, che aggiungono verifiche sull’organizzazione.

Se prima vuoi chiarire la differenza tra certificato, TLS e HTTPS, trovi l’approfondimento sui certificati SSL/TLS. Qui ci concentriamo invece su Let’s Encrypt: come funziona, come viene rinnovato e quando conviene rispetto a un certificato commerciale.

Che cos’è Let’s Encrypt e cosa offre davvero

Per capire quando Let’s Encrypt è la scelta giusta, conviene partire da ciò che offre davvero e dai limiti del suo modello. Un certificato SSL gratuito può fornire una connessione HTTPS correttamente autenticata e cifrata senza diventare, per questo, un certificato con validazione organizzativa: bisogna distinguere il livello DV, la sicurezza del trasporto e l’identità del soggetto che gestisce il sito.

Let’s Encrypt è una CA, non “un certificato”

Una delle imprecisioni più comuni è dire che “Let’s Encrypt è un certificato SSL”. Non è così.

Let’s Encrypt è una Certificate Authority, cioè l’entità che emette certificati digitali. Il certificato è il documento crittografico rilasciato dalla CA dopo che il richiedente ha dimostrato di controllare il dominio o l’identificatore per il quale lo sta richiedendo.

La sequenza concettuale è quindi:

Let’s Encrypt → emette il certificato → il server lo presenta → TLS usa certificato e chiavi durante la connessione → HTTPS trasporta HTTP attraverso TLS.

Queste parti lavorano insieme, ma non sono sinonimi. Se vuoi approfondire handshake, chiavi, cifratura e differenze tra TLS 1.2 e TLS 1.3, l’owner corretto è la guida su come funziona TLS.

La distinzione è utile anche quando devi diagnosticare un problema. Un certificato può essere valido ma il server può avere una configurazione TLS errata; allo stesso modo, HTTPS può funzionare tecnicamente mentre l’applicazione presenta vulnerabilità che il certificato non può correggere.

Cosa significa certificato DV gratuito

Let’s Encrypt emette certificati Domain Validation. La CA verifica che chi richiede il certificato controlli il dominio, ma non verifica che dietro quel dominio esista una determinata società con una specifica identità legale. La documentazione ufficiale chiarisce inoltre che Let’s Encrypt non offre OV o EV.

Questo è sufficiente per il compito fondamentale di un normale certificato TLS pubblico: permettere al browser di stabilire una connessione HTTPS con il server associato al dominio verificato.

“DV”, però, non significa “versione gratuita della sicurezza”. Descrive il livello di validazione eseguito prima dell’emissione.

Un certificato OV aggiunge la verifica dell’organizzazione; un EV applica controlli di identità ancora più estesi. Tutti possono essere usati per cifrare il traffico TLS: la differenza principale è quali informazioni sull’identità vengono convalidate e quali servizi commerciali accompagnano il certificato.

Anche “gratuito” richiede una precisazione. Let’s Encrypt non fa pagare il certificato, ma il tuo hosting può includere la gestione nel prezzo del servizio oppure applicare propri costi amministrativi. Let’s Encrypt stessa segnala questa possibilità nella FAQ ufficiale.

Cosa protegge HTTPS e cosa non certifica sul sito

Un certificato valido consente di costruire una connessione TLS autenticata e cifrata. Questo protegge i dati durante il trasporto tra client e server e aiuta il browser a verificare che sta parlando con il dominio previsto.

Non dimostra però che:

• il codice del sito sia privo di vulnerabilità;
• WordPress e i plugin siano aggiornati;
• il server non contenga malware;
• il proprietario del dominio sia affidabile;
• un ecommerce sia legittimo;
• ogni risorsa caricata dalla pagina utilizzi correttamente HTTPS.

È un confine importante perché persino un sito di phishing può ottenere un certificato DV se chi lo gestisce controlla il dominio. La stessa FAQ di Let’s Encrypt distingue esplicitamente l’emissione del certificato dalla reputazione o dalla sicurezza del contenuto ospitato.

Quindi il modello corretto non è “vedo HTTPS, quindi il sito è sicuro”. È piuttosto: HTTPS protegge la connessione; la sicurezza del sito richiede controlli ulteriori sull’applicazione, sul server e sull’identità del soggetto con cui stai interagendo.

Come funziona Let’s Encrypt: ACME, validazione ed emissione

Il funzionamento di Let’s Encrypt ruota attorno ad ACME, Automatic Certificate Management Environment. È il protocollo che permette a un software di dimostrare il controllo di un dominio, chiedere il certificato e ripetere il processo quando arriva il momento di rinnovarlo.

La documentazione ufficiale descrive proprio questo obiettivo: rendere possibile l’attivazione di HTTPS con certificati riconosciuti dai browser senza richiedere intervento umano a ogni emissione.

Il flusso dominio → challenge → certificato → rinnovo

A livello concettuale succedono quattro cose.

Prima il client ACME apre o utilizza un account presso Let’s Encrypt. Poi chiede di essere autorizzato a gestire uno o più domini. La CA risponde con una challenge, cioè una prova che solo chi controlla realmente quel dominio dovrebbe poter completare.

Una volta superata la challenge, il client può inviare una Certificate Signing Request, o CSR. Let’s Encrypt verifica la richiesta e, se tutto è corretto, emette il certificato.

Quando il certificato si avvicina al momento previsto per il rinnovo, il client ACME ripete automaticamente il processo necessario per ottenere un nuovo certificato.

La parte interessante è che il rinnovo non consiste nell’“allungare” la data di scadenza del vecchio file. Viene emesso un nuovo certificato. Questo è il motivo per cui l’automazione del ciclo emissione → installazione → reload del servizio è più importante della durata nominale del singolo certificato.

HTTP-01 e DNS-01: cosa cambia

Let’s Encrypt deve poter verificare che controlli davvero il nome richiesto. Due challenge sono particolarmente importanti.

Con HTTP-01, il client ACME pubblica un token in un percorso specifico del sito raggiungibile via HTTP. Let’s Encrypt prova a recuperarlo e, se trova il valore atteso, considera dimostrato il controllo. HTTP-01 opera sulla porta 80 e non può essere usato per emettere certificati wildcard.

Con DNS-01, invece, la prova viene pubblicata come record TXT nel DNS sotto _acme-challenge. Questo metodo richiede una gestione DNS più articolata, ma funziona anche quando il web server non è direttamente esposto e soprattutto consente l’emissione di certificati wildcard.

Per un singolo sito normale HTTP-01 è spesso la strada più semplice. DNS-01 diventa interessante quando devi gestire wildcard, più server oppure infrastrutture in cui la validazione HTTP non è possibile.

C’è però un trade-off: automatizzare DNS-01 significa spesso concedere al client ACME accesso alle API del provider DNS. Le credenziali dovrebbero quindi avere i privilegi minimi necessari; fornire al web server credenziali DNS troppo ampie allarga inutilmente l’impatto di un’eventuale compromissione. La documentazione di Let’s Encrypt raccomanda esplicitamente credenziali API con scope ristretto o la separazione della validazione DNS dal web server.

Il client ACME è il motore dell’automazione

Let’s Encrypt non entra nel tuo server per configurare autonomamente Apache, Nginx o WordPress. Serve un client ACME oppure un’integrazione equivalente gestita dal provider.

Certbot è uno dei client più conosciuti, ma non è sinonimo di Let’s Encrypt. È un software che parla ACME con la CA e può automatizzare emissione, installazione e rinnovo in molti ambienti.

Su un hosting condiviso potresti non vedere mai Certbot: cPanel, Plesk o il pannello proprietario del provider possono occuparsi dell’intero processo dietro le quinte. Su un VPS, invece, sei spesso tu a scegliere e configurare il client.

È una distinzione pratica importante: prima di cercare un comando Certbot, verifica se il tuo provider gestisce già Let’s Encrypt nativamente.

Quanto dura un certificato Let’s Encrypt e cosa cambia dal 2027

La durata è uno dei punti in cui molte guide rischiano di diventare obsolete.

Al 19 ottobre 2026, il profilo predefinito classico di Let’s Encrypt continua a emettere certificati da 90 giorni. Ma questa non sarà più una caratteristica stabile del servizio: è già stata annunciata una riduzione progressiva.

La timeline 90 → 64 → 45 giorni

La roadmap ufficiale è questa:

La staging environment è già passata ai certificati da 64 giorni il 14 ottobre 2026, proprio per consentire agli operatori di provare il nuovo ciclo prima del passaggio in produzione. Let’s Encrypt prevede inoltre che l’ultimo certificato da 90 giorni emesso prima della transizione scada l’11 maggio 2027.

Questo rende fragile qualsiasi tutorial costruito intorno alla regola “rinnova ogni 90 giorni”. La durata è una proprietà che sta cambiando; l’automazione è la parte che deve rimanere stabile.

Let’s Encrypt dispone anche di profili più brevi: nel 2026 i certificati short-lived da circa sei giorni sono generalmente disponibili, ma sono una scelta opt-in e non il default normale di un sito WordPress.

Perché il rinnovo automatico conta più della scadenza nominale

Un rinnovo manuale poteva sembrare gestibile quando la scadenza appariva distante. Con cicli più brevi diventa progressivamente meno sensato.

Per il rinnovo Let’s Encrypt, il criterio corretto è quindi verificare che:

1. il client o il provider controlli periodicamente la necessità di rinnovo;
2. la challenge possa essere completata senza intervento manuale;
3. il nuovo certificato venga installato sul servizio corretto;
4. il web server, proxy o load balancer inizi a utilizzare il nuovo certificato;
5. eventuali errori di rinnovo vengano monitorati prima della scadenza.

I client moderni possono inoltre utilizzare ACME Renewal Info, ARI, attraverso cui la CA comunica una finestra consigliata per il rinnovo. Let’s Encrypt raccomanda ARI quando disponibile; per sistemi con una schedulazione hard-coded suggerisce invece di adattarsi indicativamente a circa due terzi della durata del certificato.

Il punto operativo è semplice: se il tuo processo dipende da una persona che ogni due o tre mesi apre un pannello, scarica file e li carica a mano, non stai sfruttando il modello per cui Let’s Encrypt è stato progettato.

Come ottenere Let’s Encrypt: scegli il metodo in base al tuo hosting

Non esiste una procedura universale migliore. La scelta dipende da chi controlla il server e da quanto dell’infrastruttura gestisci direttamente.

La stessa documentazione di Let’s Encrypt separa innanzitutto i casi con accesso shell da quelli in cui il sito è gestito tramite pannello o provider.

Hosting gestito, cPanel o Plesk: partire dall’integrazione del provider

Se utilizzi un normale servizio di hosting, il primo posto in cui cercare è il pannello del provider.

Molti host integrano direttamente Let’s Encrypt o un altro certificato DV gratuito. In quel caso è quasi sempre preferibile usare l’integrazione nativa: il provider conosce il proprio bilanciatore, web server, proxy e sistema di provisioning e può gestire rinnovo e installazione senza che tu debba esportare chiavi o costruire procedure manuali.

Nel pannello potresti trovare voci come SSL/TLS, Sicurezza, HTTPS o Let’s Encrypt. In altri hosting il certificato viene creato automaticamente non appena il dominio punta correttamente al servizio.

La guida ufficiale per iniziare con Let’s Encrypt raccomanda proprio il supporto integrato del provider quando non disponi di accesso shell.

Se l’hosting offre un certificato gratuito diverso da Let’s Encrypt, non c’è motivo di sostituirlo automaticamente solo per il brand della CA. Conta che il certificato sia pubblicamente trusted, copra i nomi necessari e venga rinnovato correttamente.

VPS e server con accesso shell: quando usare Certbot

Su un VPS o un server che gestisci direttamente la situazione cambia. Qui un client ACME come Certbot ha molto più senso perché può controllare la validazione e il ciclo di vita del certificato.

La configurazione esatta dipende però dal sistema operativo, dal web server, dalla presenza di container, reverse proxy, CDN e dal tipo di challenge. Per questo non è utile copiare un singolo comando “universale” in una guida sull’entità Let’s Encrypt: un comando corretto per Nginx su una distribuzione può essere sbagliato in un’altra architettura.

Il criterio è invece questo:

server gestito direttamente → scegli client ACME compatibile → scegli challenge coerente con l’architettura → automatizza emissione e rinnovo → verifica periodicamente il risultato.

Certbot è il punto di partenza raccomandato dalla documentazione ufficiale per molti utenti con accesso shell, ma non è l’unico client ACME disponibile.

Se stai sperimentando configurazioni o ripetendo molte prove, usa l’ambiente staging della CA prima della produzione: evita di consumare inutilmente i rate limit durante i test.

Let’s Encrypt su WordPress

Se cerchi Let’s Encrypt su WordPress, c’è una distinzione che evita parecchia confusione: WordPress normalmente non emette il certificato.

Il certificato viene installato e gestito dal livello hosting/server, oppure da un proxy/CDN davanti al sito. Solo dopo devi assicurarti che WordPress utilizzi correttamente HTTPS.

La sequenza è quindi:

certificato valido sul server → HTTPS raggiungibile → WordPress configurato sugli URL HTTPS → redirect HTTP→HTTPS → verifica di risorse e link.

La procedura applicativa è già trattata nella guida su come installare SSL e migrare WordPress a HTTPS, quindi non serve duplicarla qui.

Questo confine conta anche in diagnosi: installare un plugin WordPress non può correggere un certificato scaduto sul load balancer, una challenge DNS fallita o un virtual host configurato sul nome sbagliato.

Wildcard, sottodomini e certificati per indirizzi IP

Let’s Encrypt non è limitato al classico certificato per www e dominio principale. Può coprire più nomi, wildcard e, dal 2026, anche indirizzi IP. Cambia però il modo in cui questi identificatori vengono validati.

Certificati wildcard e validazione DNS-01

Un wildcard come *.example.com è utile quando vuoi coprire molti sottodomini dello stesso livello senza elencarli singolarmente.

Per ottenere un wildcard con Let’s Encrypt devi utilizzare DNS-01. HTTP-01 non è ammesso per questo tipo di certificato.

Qui l’automazione DNS diventa quindi parte dell’architettura. Se il provider DNS offre un’API supportata dal client ACME, il rinnovo può essere completamente automatico. Se devi modificare manualmente il record TXT a ogni rinnovo, invece, perdi una parte importante del vantaggio operativo.

Ricorda inoltre che un wildcard non sostituisce sempre tutti gli altri nomi che utilizzi. Ad esempio, se ti serve anche il dominio apex, è normale includerlo esplicitamente insieme al wildcard.

SAN e più nomi nello stesso certificato

Un certificato può contenere più nomi tramite il campo Subject Alternative Name, SAN.

Questo permette, per esempio, di usare lo stesso certificato per più hostname senza ricorrere necessariamente a una wildcard. Let’s Encrypt conferma esplicitamente il supporto ai certificati con più nomi.

La scelta tra SAN e wildcard non è solo estetica.

Un SAN esplicito rende chiaro quali nomi devono essere coperti. Il wildcard è comodo quando l’insieme dei sottodomini è ampio o variabile, ma richiede DNS-01 e rende ancora più importante proteggere l’automazione DNS.

Se hai pochi hostname stabili, elencarli esplicitamente può essere più semplice. Se devi gestire continuamente sottodomini dinamici, il wildcard può ridurre il lavoro operativo.

Certificati IP e short-lived: cosa è cambiato nel 2026

Dal 15 gennaio 2026 Let’s Encrypt rende generalmente disponibili anche i certificati per indirizzi IP e il profilo short-lived. I certificati di questo profilo hanno una validità di 160 ore, poco più di sei giorni.

È una novità significativa per infrastrutture che hanno necessità specifiche, ma non cambia la scelta tipica del proprietario di un sito WordPress.

I certificati short-lived hanno senso soprattutto dove l’automazione è già molto affidabile: riducono la finestra temporale in cui un certificato compromesso resta utilizzabile e riducono la dipendenza dai meccanismi tradizionali di revoca, ma richiedono un ciclo di rinnovo molto più frequente.

Anche gli indirizzi IP hanno vincoli propri nelle challenge. La documentazione corrente indica che HTTP-01 e TLS-ALPN-01 possono essere usate per validare IP, mentre DNS-01 no.

Per un normale dominio pubblico, comunque, non c’è alcun vantaggio nel scegliere un profilo di sei giorni solo perché è disponibile.

Let’s Encrypt vs certificato SSL a pagamento: cosa cambia davvero

Il confronto più utile non è “gratis contro sicuro”. È DV automatizzato contro ciò che un prodotto commerciale aggiunge realmente al DV.

Esistono anche certificati DV a pagamento. E un certificato commerciale non diventa automaticamente più forte dal punto di vista della cifratura solo perché costa di più.

Gratis non significa cifratura più debole

La cifratura della sessione viene negoziata da TLS in base alla configurazione del client e del server, ai protocolli e agli algoritmi supportati. Il prezzo pagato alla CA non è ciò che rende matematicamente “più forte” quella sessione.

Un certificato Let’s Encrypt può quindi essere perfettamente adatto a stabilire una connessione HTTPS moderna e robusta.

La qualità effettiva dell’HTTPS dipende anche da fattori che stanno altrove: configurazione TLS, protocolli consentiti, gestione delle chiavi private, catena del certificato, patch del server e configurazione dell’applicazione.

Per questo non sceglierei un certificato commerciale con l’obiettivo generico di “avere una cifratura migliore”. Sceglierei un prodotto commerciale quando offre una proprietà ulteriore di cui ho concretamente bisogno.

DV, OV ed EV: la differenza è nella validazione dell’identità

La distinzione può essere sintetizzata così:

Let’s Encrypt offre DV, non OV o EV.

Un provider commerciale può poi aggiungere altri elementi: assistenza diretta, portali centralizzati, gestione enterprise, SLA, procedure di validazione aziendale, integrazioni specifiche o servizi collegati.

Questi possono avere valore. Ma sono servizi e livelli di assurance diversi, non una prova che il certificato gratuito cifri “peggio”.

Quando un certificato commerciale può avere senso

Pagare può essere razionale quando il requisito non è semplicemente “voglio HTTPS”.

Per esempio, può servire un certificato OV/EV perché l’organizzazione o una policy interna richiede un’identità aziendale verificata nel certificato. Oppure puoi avere bisogno di supporto contrattuale, gestione centralizzata di grandi quantità di certificati, integrazioni enterprise o procedure che una CA automatizzata gratuita non offre.

Anche il supporto è una differenza reale: Let’s Encrypt non fornisce assistenza diretta individuale ai subscriber e indirizza principalmente alla documentazione e alla community.

Viceversa, per un sito informativo, un blog, un normale sito aziendale o molti ecommerce, pagare soltanto per sostituire un DV Let’s Encrypt perfettamente funzionante può non produrre alcun vantaggio tecnico concreto.

WordPress ed ecommerce: come decidere senza falsi miti

Un sito ecommerce non richiede automaticamente un certificato TLS a pagamento.

La prima esigenza è che la connessione sia HTTPS, il certificato sia valido e trusted, la chiave sia gestita correttamente e l’infrastruttura sia configurata in modo sicuro. Se un requisito aziendale, contrattuale o di identity assurance impone OV/EV, allora il discorso cambia.

Per un normale WooCommerce, invece, il prezzo del certificato non è una scorciatoia per valutare la sicurezza complessiva del negozio. Aggiornamenti, hardening, autenticazione, gestione dei plugin, backup, protezione dei dati e sicurezza del pagamento restano problemi separati.

Anche dal punto di vista SEO non c’è un motivo per acquistare un certificato al posto di Let’s Encrypt sperando in un ranking superiore. Google raccomanda che le pagine vengano servite in modo sicuro, ma la documentazione corrente chiarisce che non esiste un singolo “page experience signal” e che, oltre ai Core Web Vitals, gli altri aspetti di page experience non fanno direttamente salire una pagina solo perché soddisfatti.

In altre parole: HTTPS sì; “certificato più costoso = più SEO” no.

Problemi più comuni con Let’s Encrypt

L’automazione riduce parecchio il lavoro manuale, ma non elimina gli errori. Conviene capire in quale fase si trova il problema prima di cambiare configurazioni a caso.

Il dominio non supera la challenge

Se HTTP-01 fallisce, controlla prima di tutto che il nome DNS risolva verso l’infrastruttura corretta e che la porta 80 sia raggiungibile. Let’s Encrypt deve poter recuperare il token dalla posizione prevista.

Reverse proxy, CDN, regole di redirect o cluster con più server possono complicare la situazione: tutti i nodi coinvolti devono rendere disponibile la risposta attesa dalla validazione.

Con DNS-01 il problema si sposta sul DNS. Il record TXT deve essere pubblicato sotto il nome corretto e deve essersi propagato fino ai resolver interrogati da Let’s Encrypt. La propagazione non è istantanea per tutti i provider.

Ripetere decine di richieste senza capire il problema non è una strategia di diagnosi: rischia soltanto di incontrare i rate limit. Prima correggi la causa, poi ripeti l’emissione.

Il rinnovo automatico non funziona

Un rinnovo fallito può derivare da un client non più in esecuzione, credenziali DNS cambiate, configurazione del dominio modificata, porta non raggiungibile, plugin/API del provider obsoleti oppure dal fatto che il nuovo certificato viene emesso ma non caricato realmente sul servizio.

La verifica non dovrebbe quindi fermarsi a “il comando di rinnovo è partito”.

Controlla:

scheduler → challenge → nuova emissione → installazione → reload del servizio → certificato realmente presentato al client.

Con la riduzione delle lifetime annunciata per 2027 e 2028, monitorare questo percorso diventa ancora più importante. Un processo che funziona solo perché qualcuno interviene quando mancano pochi giorni alla scadenza non è robusto.

Il certificato è valido ma HTTPS mostra ancora errori

Se il browser presenta un certificato valido ma la pagina non è completamente sicura, potresti non avere un problema di Let’s Encrypt.

Un caso frequente è il mixed content: la pagina viene aperta in HTTPS ma prova ancora a caricare immagini, script, CSS o altre risorse via HTTP. In WordPress puoi seguire la guida per correggere il contenuto misto.

Se invece il problema riguarda direttamente la negoziazione TLS — per esempio nome del certificato, catena, protocollo, proxy o configurazione server — il troubleshooting corretto è quello dell’errore SSL handshake failed.

Separare questi casi evita un errore comune: rigenerare continuamente il certificato quando il certificato non è la causa del problema.

Conclusione

Per la maggior parte dei normali siti web, Let’s Encrypt è una scelta perfettamente sensata: emette certificati DV trusted, non richiede il pagamento del certificato ed è progettato intorno a un ciclo di vita automatizzato.

Se utilizzi un hosting gestito, partirei dall’integrazione fornita dal provider. Se amministri direttamente un server, userei un client ACME come Certbot o un’alternativa adatta alla tua architettura. Se ti serve un wildcard, la questione centrale diventa l’automazione DNS. Se hai invece bisogno di identità organizzativa verificata, supporto contrattuale o requisiti enterprise specifici, allora ha senso valutare un certificato commerciale OV/EV o un servizio PKI diverso.

La decisione, quindi, non dovrebbe essere gratis contro sicuro. Dovrebbe essere:

quale livello di validazione mi serve, chi gestirà il rinnovo e quali requisiti deve soddisfare realmente la mia infrastruttura?

Nel 2026 questo criterio è ancora più importante perché Let’s Encrypt sta già preparando il passaggio dai 90 giorni ai 64 giorni nel 2027 e ai 45 giorni nel 2028. Un certificato ben automatizzato può adattarsi al cambiamento quasi senza intervento; un processo manuale diventerà invece sempre più fragile.