{"id":97,"date":"2026-06-13T16:30:00","date_gmt":"2026-06-13T16:30:00","guid":{"rendered":"https:\/\/shattered.io\/it\/2026\/06\/13\/certbot-lets-encrypt-https\/"},"modified":"2026-06-13T16:31:24","modified_gmt":"2026-06-13T16:31:24","slug":"certbot-lets-encrypt-https","status":"publish","type":"post","link":"https:\/\/shattered.io\/it\/2026\/06\/13\/certbot-lets-encrypt-https\/","title":{"rendered":"Let&#8217;s Encrypt e Certbot: HTTPS Gratis in 10 Step [2026]"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Nel 2026 servire un sito senza HTTPS significa perdere visitatori, posizionamento e fiducia. La buona notizia: un certificato TLS valido non costa pi\u00f9 nulla. <strong>Let&#8217;s Encrypt<\/strong> ha emesso oltre 7 miliardi di certificati dal 2015 e oggi protegge circa 762 milioni di siti web, secondo il rapporto annuale 2025 di ISRG. Lo strumento che rende tutto questo automatico si chiama <strong>Certbot<\/strong>, mantenuto dalla Electronic Frontier Foundation. Questo tutorial ti porta da un server Nginx in chiaro a un sito con HTTPS, redirect forzato, rinnovo automatico e header di sicurezza, in 10 step verificabili.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Il percorso richiede circa 30 minuti su un server pulito. Useremo Ubuntu 24.04 LTS e Nginx, il plugin <code>--nginx<\/code> di Certbot, l&#8217;ambiente di staging per i test e un systemd timer per il rinnovo. Ogni comando include l&#8217;output atteso, e alla fine trovi 6 errori comuni, 8 voci di troubleshooting e una configurazione di produzione completa che puoi copiare. Il 2026 porta novit\u00e0 importanti: certificati a vita breve da 6 giorni, profili ACME nominati e il passaggio del profilo <code>tlsserver<\/code> a 45 giorni di validit\u00e0 dal 13 maggio 2026. Le copriamo tutte.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"perche-lets-encrypt-domina-lhttps-gratuito-nel-2026\">Perch\u00e9 Let&#8217;s Encrypt domina l&#8217;HTTPS gratuito nel 2026<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Let&#8217;s Encrypt \u00e8 oggi la pi\u00f9 grande autorit\u00e0 di certificazione al mondo per volume di emissione. I numeri parlano chiaro: pi\u00f9 di 7 miliardi di certificati emessi dal lancio nel 2015 e una copertura di 762 milioni di siti web nel rapporto 2025. Dietro il progetto c&#8217;\u00e8 ISRG (Internet Security Research Group), un&#8217;organizzazione no-profit la cui missione \u00e8 rendere l&#8217;HTTPS gratuito, automatico e accessibile a chiunque. Questo modello ha cambiato il web: nel 2015 cifrare un sito richiedeva centinaia di euro l&#8217;anno, oggi richiede un comando.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Il 2026 segna una svolta verso i certificati a vita breve. Il modello classico da 90 giorni resta la base nel rapporto 2025, ma ISRG ha gi\u00e0 lanciato nel 2025 un&#8217;opzione di certificati da 6 giorni e introdotto i certificati per indirizzi IP. Dal 13 maggio 2026, il profilo ACME <code>tlsserver<\/code> emette certificati con validit\u00e0 predefinita di 45 giorni. La logica \u00e8 di sicurezza: una validit\u00e0 pi\u00f9 corta riduce la finestra di abuso di una chiave compromessa e costringe all&#8217;automazione. Per te questo significa una sola cosa, il rinnovo automatico non \u00e8 opzionale, \u00e8 il cuore di qualsiasi configurazione seria con <strong>Certbot<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">C&#8217;\u00e8 un&#8217;altra novit\u00e0 operativa che cambia le abitudini: dal giugno 2025 Let&#8217;s Encrypt ha interrotto l&#8217;invio delle email di notifica di scadenza. Per anni quelle email sono state la rete di sicurezza di chi rinnovava a mano. Ora non esistono pi\u00f9. Se il tuo rinnovo automatico si rompe, nessuno ti avvisa via email: il sito smette di funzionare e basta. Questo rende il monitoraggio del rinnovo (lo affrontiamo allo step 8) una parte obbligatoria del lavoro, non un extra. ISRG ha anche annunciato che nel 2026 deprecher\u00e0 l&#8217;EKU di Client Authentication per allinearsi ai nuovi requisiti dei root program, quindi i certificati Let&#8217;s Encrypt vanno usati solo come certificati server, mai come certificati client.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Se vuoi capire cosa accade davvero quando un browser apre una connessione cifrata, il nostro approfondimento su <a href=\"\/it\/https-e-tls\/\">come HTTPS e TLS proteggono una connessione<\/a> spiega l&#8217;handshake passo per passo. Qui ci concentriamo sulla pratica: ottenere e mantenere il certificato.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"come-funziona-il-protocollo-acme-dietro-certbot\">Come funziona il protocollo ACME dietro Certbot<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Prima di lanciare comandi conviene capire cosa fa <strong>Certbot<\/strong> sotto il cofano. Certbot \u00e8 un client del protocollo ACME (Automatic Certificate Management Environment), standardizzato nell&#8217;RFC 8555. ACME automatizza il dialogo tra il tuo server e l&#8217;autorit\u00e0 di certificazione. Quando chiedi un certificato, Certbot crea un account presso Let&#8217;s Encrypt, invia una richiesta per i domini che vuoi proteggere e riceve una o pi\u00f9 sfide (challenge) da risolvere. Risolvendo la sfida dimostri di controllare davvero quel dominio. Solo allora Let&#8217;s Encrypt firma ed emette il certificato.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Esistono tre tipi di sfida, e scegliere quella giusta evita met\u00e0 dei problemi:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>HTTP-01<\/strong>: Certbot crea un file token sotto <code>\/.well-known\/acme-challenge\/<\/code> e Let&#8217;s Encrypt lo legge via HTTP sulla porta 80. \u00c8 la sfida predefinita, perfetta per un singolo dominio o sottodominio.<\/li>\n<li><strong>DNS-01<\/strong>: dimostri il controllo creando un record TXT nel DNS. \u00c8 l&#8217;unica sfida che permette i certificati wildcard (ad esempio <code>*.esempio.it<\/code>) e funziona anche senza esporre la porta 80.<\/li>\n<li><strong>TLS-ALPN-01<\/strong>: la validazione avviene sulla porta 443 tramite l&#8217;estensione ALPN del TLS. Utile dietro reverse proxy o quando la porta 80 \u00e8 occupata.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Nel 2026 ACME introduce anche i profili nominati. La pagina delle catene di certificati di Let&#8217;s Encrypt elenca profili come <code>classic<\/code>, <code>tlsserver<\/code> e <code>tlsclient<\/code>. Il profilo determina la validit\u00e0 e il tipo d&#8217;uso del certificato. Il profilo <code>classic<\/code> mantiene i 90 giorni storici, mentre <code>tlsserver<\/code> passa ai 45 giorni dal 13 maggio 2026. Certbot seleziona un profilo predefinito sensato, ma \u00e8 bene sapere che esistono perch\u00e9 influenzano la frequenza dei rinnovi.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Un&#8217;ultima nota sulle chiavi. Let&#8217;s Encrypt raccomanda chiavi <strong>ECDSA<\/strong> dove possibile, pur continuando a supportare RSA. I certificati subscriber ECDSA vengono emessi da intermediari ECDSA, quelli RSA da intermediari RSA. ECDSA offre la stessa sicurezza con chiavi molto pi\u00f9 corte e handshake pi\u00f9 veloci. Confronteremo le due opzioni pi\u00f9 avanti. Se vuoi un ripasso sui fondamenti, la nostra guida alle <a href=\"\/it\/firme-digitali\/\">firme digitali e al ruolo delle funzioni hash<\/a> chiarisce perch\u00e9 ECDSA \u00e8 cos\u00ec efficiente.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"prerequisiti-e-versioni-richieste\">Prerequisiti e versioni richieste<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Questo tutorial parte da un server Linux pubblico con un dominio puntato sul suo indirizzo IP. Non servono competenze avanzate di sistemista, ma serve accesso root o un utente con <code>sudo<\/code>. La tabella seguente riassume tutto ci\u00f2 che ti occorre prima di iniziare. Dove non posso garantire un numero di versione esatto e attuale, indico &#8220;ultima versione&#8221;: installa sempre il pacchetto pi\u00f9 recente disponibile per la tua distribuzione.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Requisito<\/th><th>Versione consigliata<\/th><th>Note<\/th><\/tr><\/thead><tbody>\n<tr><td>Sistema operativo<\/td><td>Ubuntu 24.04 LTS<\/td><td>Funziona anche su Debian 12, Rocky Linux 9, AlmaLinux 9<\/td><\/tr>\n<tr><td>Web server<\/td><td>Nginx 1.24 o superiore<\/td><td>Apache 2.4 va bene con il plugin <code>--apache<\/code><\/td><\/tr>\n<tr><td>Certbot<\/td><td>Ultima versione (via snap)<\/td><td>Lo snap si aggiorna da solo, evita pacchetti apt obsoleti<\/td><\/tr>\n<tr><td>snapd<\/td><td>Ultima versione<\/td><td>Preinstallato su Ubuntu, da installare su Debian<\/td><\/tr>\n<tr><td>Dominio<\/td><td>Record DNS A o AAAA valido<\/td><td>Deve puntare all&#8217;IP pubblico del server<\/td><\/tr>\n<tr><td>Porte aperte<\/td><td>80 e 443 in ingresso<\/td><td>La 80 serve alla sfida HTTP-01 e al redirect<\/td><\/tr>\n<tr><td>Accesso<\/td><td>root o utente con sudo<\/td><td>Per installare pacchetti e scrivere in \/etc\/nginx<\/td><\/tr>\n<tr><td>OpenSSL<\/td><td>OpenSSL 3.x<\/td><td>Per ispezionare i certificati emessi<\/td><\/tr>\n<\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Verifica due cose prima di proseguire. Primo, che il dominio risolva davvero al tuo server: un record DNS sbagliato \u00e8 la causa numero uno dei fallimenti della sfida HTTP-01. Secondo, che il firewall lasci passare la porta 80, perch\u00e9 Let&#8217;s Encrypt deve raggiungere il tuo server dall&#8217;esterno per validare il dominio. Se gestisci chiavi e certificati anche a livello locale, il nostro tutorial su <a href=\"\/it\/openssl-certificati-chiavi\/\">OpenSSL 3.5 LTS per chiavi e certificati<\/a> copre la generazione manuale, complementare a quanto vedremo qui con Certbot.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"step-1-2-preparare-server-dns-e-firewall\">Step 1-2: Preparare server, DNS e firewall<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Il primo passo \u00e8 assicurarsi che il sistema sia aggiornato e che Nginx serva gi\u00e0 il dominio in HTTP. Senza un server block funzionante, il plugin <code>--nginx<\/code> non sa dove inserire la configurazione TLS. Aggiorna i pacchetti e installa Nginx:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Step 1: aggiornamento del sistema e installazione di Nginx\nsudo apt update &amp;&amp; sudo apt upgrade -y\nsudo apt install -y nginx\n\n# Apri le porte 80 e 443 sul firewall UFW\nsudo ufw allow 'Nginx Full'\nsudo ufw reload\nsudo ufw status<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Ora crea un server block minimo per il tuo dominio. Sostituisci <code>esempio.it<\/code> con il tuo dominio reale ovunque compaia. Questo file dice a Nginx a quale dominio risponde, informazione che Certbot legger\u00e0 per inserire il certificato giusto.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Step 2: server block HTTP in \/etc\/nginx\/sites-available\/esempio.it\nserver {\n    listen 80;\n    listen [::]:80;\n    server_name esempio.it www.esempio.it;\n\n    root \/var\/www\/esempio.it\/html;\n    index index.html;\n\n    location \/ {\n        try_files $uri $uri\/ =404;\n    }\n}<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Attiva il sito, testa la sintassi e ricarica Nginx. Il test di sintassi \u00e8 un&#8217;abitudine che salva: Nginx non si ricarica mai con una configurazione rotta, ma \u00e8 meglio scoprirlo subito.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>sudo ln -s \/etc\/nginx\/sites-available\/esempio.it \/etc\/nginx\/sites-enabled\/\nsudo nginx -t\n# Output atteso:\n# nginx: configuration file \/etc\/nginx\/nginx.conf test is successful\nsudo systemctl reload nginx<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Verifica dal tuo computer che il dominio risponda in HTTP prima di chiedere il certificato. Un semplice <code>curl -I http:\/\/esempio.it<\/code> deve restituire <code>HTTP\/1.1 200 OK<\/code>. Se ricevi un timeout, il problema \u00e8 il DNS o il firewall, non Certbot. Risolvi qui, perch\u00e9 la sfida HTTP-01 fallir\u00e0 esattamente per gli stessi motivi. Controlla la propagazione del DNS con <code>dig esempio.it +short<\/code>: l&#8217;output deve mostrare l&#8217;IP pubblico del tuo server.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"step-3-installare-certbot-con-snap-su-ubuntu\">Step 3: Installare Certbot con snap su Ubuntu<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Per anni la via comune era <code>apt install certbot<\/code>, ma quel pacchetto invecchia in fretta nei repository delle distribuzioni. La documentazione attuale di Certbot raccomanda l&#8217;installazione via <strong>snap<\/strong>, perch\u00e9 lo snap si aggiorna da solo e ti d\u00e0 sempre l&#8217;ultima versione. Questo conta nel 2026, quando i profili ACME e i certificati a vita breve cambiano spesso. Se hai un vecchio Certbot installato via apt, rimuovilo prima per evitare conflitti.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Step 3: rimuovi eventuali installazioni apt obsolete\nsudo apt remove certbot -y\n\n# Assicurati che snapd sia aggiornato\nsudo snap install core\nsudo snap refresh core\n\n# Installa Certbot dallo snap classico\nsudo snap install --classic certbot\n\n# Crea il link simbolico per avere il comando nel PATH\nsudo ln -s \/snap\/bin\/certbot \/usr\/bin\/certbot\n\n# Verifica la versione installata\ncertbot --version\n# Output atteso (esempio):\n# certbot 3.x.x<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Il numero di versione esatto dipende dal momento in cui installi: lo snap ti d\u00e0 sempre l&#8217;ultima release stabile, quindi non fissare una versione nei tuoi script. Se il comando <code>certbot --version<\/code> restituisce un numero, l&#8217;installazione \u00e8 riuscita. Se restituisce &#8220;command not found&#8221;, il link simbolico non \u00e8 stato creato: ripeti la riga <code>ln -s<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Su distribuzioni senza snap preinstallato (Debian, alcune immagini cloud minimali) installa prima <code>snapd<\/code> con <code>sudo apt install snapd<\/code> e riavvia la sessione. In alternativa, su sistemi dove snap non \u00e8 praticabile, esiste l&#8217;installazione via <code>pip<\/code> in un ambiente virtuale, ma perde l&#8217;aggiornamento automatico ed \u00e8 sconsigliata per la produzione. La documentazione ufficiale di <a href=\"https:\/\/certbot.eff.org\/\" target=\"_blank\" rel=\"noopener\">Certbot mantenuta dalla EFF<\/a> elenca le istruzioni per ogni combinazione di sistema e web server.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"step-4-5-testare-in-staging-e-ottenere-il-certificato\">Step 4-5: Testare in staging e ottenere il certificato<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Qui sta la differenza tra un professionista e chi brucia i propri limiti di rate. Let&#8217;s Encrypt offre un ambiente di <strong>staging<\/strong> che emette certificati non fidati dai browser ma identici nel processo. Usalo per provare l&#8217;automazione senza consumare i limiti di produzione. Il flag <code>--dry-run<\/code> esegue tutta la procedura senza salvare nulla, ed \u00e8 il test pi\u00f9 rapido.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Step 4: prova a secco contro l'ambiente di staging\nsudo certbot certonly --nginx --dry-run -d esempio.it -d www.esempio.it\n\n# Output atteso in caso di successo:\n# The dry run was successful.\n# Congratulations, all simulated renewals succeeded<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Se la prova a secco riesce, sei pronto per la produzione. Lancia Certbot con il plugin Nginx: il plugin ottiene il certificato e modifica automaticamente il server block per servire HTTPS. La prima volta Certbot chiede un&#8217;email (per i recuperi account, non pi\u00f9 per le notifiche di scadenza che sono state interrotte) e l&#8217;accettazione dei termini di servizio.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Step 5: emissione del certificato di produzione con plugin Nginx\nsudo certbot --nginx -d esempio.it -d www.esempio.it\n\n# Certbot chiede:\n# 1) un indirizzo email per il ripristino dell'account\n# 2) accettazione dei Terms of Service (A)\n# 3) se vuoi il redirect automatico HTTP -> HTTPS (consigliato: opzione 2)<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Quando Certbot chiede del redirect, scegli l&#8217;opzione che reindirizza tutto il traffico HTTP verso HTTPS. \u00c8 il modo pi\u00f9 semplice per non lasciare buchi in chiaro. Se preferisci controllare la configurazione a mano, scegli &#8220;no redirect&#8221; e lo aggiungiamo manualmente allo step 7. Per chi gestisce dati sensibili e deve rispettare la <a href=\"\/it\/nis2-italia-direttiva-2026\/\">direttiva NIS2 in Italia<\/a>, la cifratura del traffico in transito \u00e8 uno dei controlli di base richiesti.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"step-6-7-verificare-loutput-e-forzare-il-redirect-https\">Step 6-7: Verificare l&#8217;output e forzare il redirect HTTPS<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Dopo l&#8217;emissione, Certbot stampa il percorso dei file e la data di scadenza. Conoscere questi percorsi \u00e8 importante: sono i file che Nginx serve e che gli script di rinnovo aggiornano. Questo \u00e8 l&#8217;output tipico di un&#8217;emissione riuscita.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Step 6: output tipico di un'emissione riuscita\nSuccessfully received certificate.\nCertificate is saved at: \/etc\/letsencrypt\/live\/esempio.it\/fullchain.pem\nKey is saved at:         \/etc\/letsencrypt\/live\/esempio.it\/privkey.pem\nThis certificate expires on 2026-09-11.\nDeploying certificate\nSuccessfully deployed certificate for esempio.it to \/etc\/nginx\/sites-enabled\/esempio.it\nCongratulations! You have successfully enabled HTTPS on https:\/\/esempio.it<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">I due file chiave sono <code>fullchain.pem<\/code> (il tuo certificato pi\u00f9 la catena intermedia) e <code>privkey.pem<\/code> (la chiave privata). Non spostarli e non modificarli a mano: Certbot li gestisce e li sovrascrive al rinnovo. La cartella <code>live<\/code> contiene link simbolici sempre aggiornati, quindi punta sempre l\u00ec nella configurazione di Nginx, mai alle cartelle <code>archive<\/code> numerate.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Se hai scelto di non far gestire il redirect a Certbot, ecco la configurazione manuale. Il primo blocco reindirizza tutto l&#8217;HTTP verso HTTPS, il secondo serve il sito cifrato con TLS 1.3 e TLS 1.2 (le uniche versioni che dovresti supportare nel 2026).<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Step 7: redirect e configurazione TLS in \/etc\/nginx\/sites-available\/esempio.it\nserver {\n    listen 80;\n    listen [::]:80;\n    server_name esempio.it www.esempio.it;\n    # Reindirizza ogni richiesta HTTP a HTTPS con codice 301 permanente\n    return 301 https:\/\/$host$request_uri;\n}\n\nserver {\n    listen 443 ssl;\n    listen [::]:443 ssl;\n    http2 on;\n    server_name esempio.it www.esempio.it;\n\n    ssl_certificate     \/etc\/letsencrypt\/live\/esempio.it\/fullchain.pem;\n    ssl_certificate_key \/etc\/letsencrypt\/live\/esempio.it\/privkey.pem;\n\n    # Limita ai protocolli moderni\n    ssl_protocols TLSv1.2 TLSv1.3;\n    ssl_prefer_server_ciphers off;\n\n    root \/var\/www\/esempio.it\/html;\n    index index.html;\n}<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Dopo ogni modifica esegui sempre <code>sudo nginx -t &amp;&amp; sudo systemctl reload nginx<\/code>. Poi prova il sito su <a href=\"https:\/\/www.ssllabs.com\/ssltest\/\" target=\"_blank\" rel=\"noopener\">SSL Labs SSL Test<\/a>: un punteggio A o A+ conferma che protocolli e catena sono corretti. Apri il sito nel browser e controlla che il lucchetto sia presente e che <code>http:\/\/<\/code> rediriga a <code>https:\/\/<\/code>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"step-8-automatizzare-il-rinnovo-dei-certificati\">Step 8: Automatizzare il rinnovo dei certificati<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Questo \u00e8 lo step pi\u00f9 importante del 2026. Con la fine delle email di scadenza e l&#8217;arrivo di certificati da 45 giorni e perfino da 6 giorni, il rinnovo manuale \u00e8 impraticabile. Per fortuna l&#8217;installazione via snap di Certbot configura gi\u00e0 un systemd timer che tenta il rinnovo due volte al giorno. Il comando <code>certbot renew<\/code> rinnova solo i certificati che scadono entro 30 giorni, quindi puoi eseguirlo spesso senza rischi. Verifica che il timer esista e sia attivo.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Step 8: verifica il systemd timer del rinnovo\nsystemctl list-timers | grep certbot\n# Output atteso (esempio):\n# snap.certbot.renew.timer  ... snap.certbot.renew.service\n\n# Simula un rinnovo senza eseguirlo davvero\nsudo certbot renew --dry-run\n# Output atteso:\n# Congratulations, all simulated renewals succeeded<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Se il tuo sistema non usa systemd, configura un cron job. Aggiungi questa riga con <code>sudo crontab -e<\/code> per tentare il rinnovo ogni giorno e ricaricare Nginx solo quando un certificato cambia davvero:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Alternativa cron: rinnovo giornaliero con reload condizionato di Nginx\n0 3 * * * certbot renew --quiet --deploy-hook \"systemctl reload nginx\"<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Il <code>--deploy-hook<\/code> \u00e8 la parte che molti dimenticano. Senza di esso Nginx continua a servire il vecchio certificato in memoria anche dopo il rinnovo, finch\u00e9 non lo ricarichi. L&#8217;hook ricarica Nginx solo quando un certificato \u00e8 stato effettivamente rinnovato, evitando reload inutili. Dato che nessuno ti avvisa pi\u00f9 via email se il rinnovo fallisce, aggiungi un monitoraggio esterno: un servizio di uptime che controlla la data di scadenza del certificato e ti avvisa con 7 giorni di anticipo \u00e8 la migliore assicurazione.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"step-9-emettere-certificati-wildcard-con-dns-01\">Step 9: Emettere certificati wildcard con DNS-01<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Quando hai molti sottodomini (<code>app.esempio.it<\/code>, <code>api.esempio.it<\/code>, <code>blog.esempio.it<\/code>) un certificato wildcard <code>*.esempio.it<\/code> ti evita di gestirli uno a uno. C&#8217;\u00e8 un solo modo per ottenerlo: la sfida <strong>DNS-01<\/strong>. Let&#8217;s Encrypt non emette wildcard tramite HTTP-01 o TLS-ALPN-01, perch\u00e9 un wildcard copre sottodomini infiniti e l&#8217;unica prova accettabile \u00e8 il controllo del DNS della zona. Devi quindi creare un record TXT, manualmente o tramite un plugin del tuo provider DNS.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Step 9: certificato wildcard con sfida DNS-01 manuale\nsudo certbot certonly --manual --preferred-challenges dns \\\n  -d esempio.it -d \"*.esempio.it\"\n\n# Certbot mostra un valore da inserire come record TXT:\n# _acme-challenge.esempio.it  TXT  \"il-valore-da-copiare-nel-DNS\"\n# Crea il record, attendi la propagazione, poi premi Invio per continuare<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">La modalit\u00e0 <code>--manual<\/code> va bene per un test, ma non si rinnova da sola: ad ogni rinnovo dovresti aggiornare il record TXT a mano. Per la produzione usa un plugin DNS automatizzato. Certbot offre plugin ufficiali per molti provider (Cloudflare, Route 53, Google Cloud DNS, OVH e altri). Con il plugin Cloudflare, ad esempio, salvi un token API in un file protetto e Certbot crea e cancella il record TXT da solo, rendendo anche i wildcard completamente automatici.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Esempio con plugin DNS automatizzato (Cloudflare)\nsudo snap set certbot trust-plugin-with-root=ok\nsudo snap install certbot-dns-cloudflare\n\n# File credenziali con permessi restrittivi (chmod 600)\necho \"dns_cloudflare_api_token = IL_TUO_TOKEN\" | sudo tee \/root\/.cloudflare.ini\nsudo chmod 600 \/root\/.cloudflare.ini\n\nsudo certbot certonly --dns-cloudflare \\\n  --dns-cloudflare-credentials \/root\/.cloudflare.ini \\\n  -d esempio.it -d \"*.esempio.it\"<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Attenzione ai permessi del file delle credenziali: un token API DNS d\u00e0 controllo sulla tua zona, quindi <code>chmod 600<\/code> e propriet\u00e0 root sono obbligatori. Un token esposto equivale a consegnare le chiavi del dominio. I dettagli sui tipi di sfida e sui requisiti dei wildcard sono nella <a href=\"https:\/\/letsencrypt.org\/docs\/challenge-types\/\" target=\"_blank\" rel=\"noopener\">documentazione ufficiale sui tipi di sfida<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"step-10-hsts-e-header-di-sicurezza-in-nginx\">Step 10: HSTS e header di sicurezza in Nginx<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">HTTPS funzionante \u00e8 il minimo, non il traguardo. Un attaccante pu\u00f2 ancora tentare un downgrade verso HTTP se il primo accesso dell&#8217;utente avviene in chiaro. La risposta \u00e8 <strong>HSTS<\/strong> (HTTP Strict Transport Security), un header che dice al browser di usare solo HTTPS per quel dominio per un periodo definito. Aggiungilo solo dopo aver confermato che HTTPS \u00e8 stabile, perch\u00e9 HSTS blocca l&#8217;accesso in chiaro e un errore pu\u00f2 rendere il sito irraggiungibile fino alla scadenza dell&#8217;header.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Step 10: header di sicurezza nel blocco server 443 di Nginx\n# HSTS: forza HTTPS per 1 anno, inclusi i sottodomini\nadd_header Strict-Transport-Security \"max-age=31536000; includeSubDomains\" always;\n\n# Impedisce il caricamento del sito in iframe di terzi (anti-clickjacking)\nadd_header X-Frame-Options \"SAMEORIGIN\" always;\n\n# Blocca lo sniffing del MIME type\nadd_header X-Content-Type-Options \"nosniff\" always;\n\n# Controlla quali informazioni di referrer vengono inviate\nadd_header Referrer-Policy \"strict-origin-when-cross-origin\" always;<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Dopo aver inserito gli header, esegui di nuovo <code>sudo nginx -t &amp;&amp; sudo systemctl reload nginx<\/code> e ricontrolla con SSL Labs e con gli strumenti per sviluppatori del browser (scheda Network, intestazioni di risposta). Quando sei sicuro che tutto sia stabile da settimane, puoi valutare l&#8217;inserimento del dominio nella lista di preload HSTS, una decisione difficile da annullare. La parola <code>always<\/code> garantisce che gli header siano presenti anche nelle risposte di errore, non solo nelle 200. A questo punto hai un progetto completo e funzionante: HTTPS gratuito, redirect forzato, rinnovo automatico, supporto wildcard e header di sicurezza moderni.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"i-limiti-di-rate-di-lets-encrypt-da-conoscere\">I limiti di rate di Let&#8217;s Encrypt da conoscere<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Let&#8217;s Encrypt \u00e8 gratuito ma non illimitato. I limiti di rate proteggono il servizio dagli abusi e penalizzano chi sbaglia in produzione invece di testare in staging. Superare un limite significa attendere ore o giorni prima di poter emettere di nuovo, e durante l&#8217;attesa il sito resta senza certificato. Ecco i limiti principali che ogni configurazione deve rispettare, secondo la documentazione ufficiale.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Limite<\/th><th>Valore<\/th><th>Reintegro<\/th><\/tr><\/thead><tbody>\n<tr><td>Certificati per dominio registrato<\/td><td>50 ogni 7 giorni<\/td><td>1 ogni 202 minuti<\/td><\/tr>\n<tr><td>Certificati duplicati (stesso set di identificatori)<\/td><td>5 ogni 7 giorni<\/td><td>1 ogni 34 ore<\/td><\/tr>\n<tr><td>Ambiente di staging<\/td><td>Limiti molto pi\u00f9 alti<\/td><td>Per i test prima della produzione<\/td><\/tr>\n<tr><td>Domini per certificato (SAN)<\/td><td>Fino a 100 nomi<\/td><td>Per richiesta<\/td><\/tr>\n<\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">La trappola pi\u00f9 comune \u00e8 il limite dei certificati duplicati: 5 emissioni per lo stesso identico set di domini ogni 7 giorni. Se lanci Certbot in produzione cinque volte di fila per provare qualcosa, hai esaurito il limite e devi aspettare. \u00c8 esattamente per questo che lo step 4 insiste sul <code>--dry-run<\/code> e sullo staging. Il limite di 50 certificati per dominio registrato a settimana raramente disturba un singolo sito, ma pu\u00f2 bloccare chi gestisce molti sottodomini con certificati separati: in quel caso un singolo certificato wildcard risolve il problema. La documentazione completa \u00e8 su <a href=\"https:\/\/letsencrypt.org\/docs\/rate-limits\/\" target=\"_blank\" rel=\"noopener\">letsencrypt.org\/docs\/rate-limits<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"ecdsa-o-rsa-quale-chiave-scegliere\">ECDSA o RSA: quale chiave scegliere<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Quando Certbot emette un certificato genera una coppia di chiavi. Il tipo di chiave influenza prestazioni e compatibilit\u00e0. Let&#8217;s Encrypt raccomanda <strong>ECDSA<\/strong> dove possibile, e nel 2026 questa \u00e8 la scelta giusta per la quasi totalit\u00e0 dei siti. ECDSA offre la stessa robustezza crittografica di RSA con chiavi molto pi\u00f9 corte: una chiave ECDSA P-256 equivale grosso modo a una RSA da 3072 bit, ma con handshake pi\u00f9 rapidi e meno carico sulla CPU del server.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Caratteristica<\/th><th>ECDSA (P-256)<\/th><th>RSA (2048\/3072)<\/th><\/tr><\/thead><tbody>\n<tr><td>Dimensione chiave<\/td><td>256 bit<\/td><td>2048 o 3072 bit<\/td><\/tr>\n<tr><td>Velocit\u00e0 handshake<\/td><td>Pi\u00f9 veloce<\/td><td>Pi\u00f9 lenta<\/td><\/tr>\n<tr><td>Carico CPU server<\/td><td>Basso<\/td><td>Pi\u00f9 alto<\/td><\/tr>\n<tr><td>Compatibilit\u00e0 client molto vecchi<\/td><td>Buona (client moderni)<\/td><td>Massima<\/td><\/tr>\n<tr><td>Raccomandazione Let&#8217;s Encrypt<\/td><td>Preferita<\/td><td>Supportata<\/td><\/tr>\n<\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Per forzare una chiave ECDSA aggiungi <code>--key-type ecdsa<\/code> al comando Certbot. Scegli RSA solo se devi servire client molto datati che non supportano le curve ellittiche, una casistica ormai marginale. Se vuoi capire perch\u00e9 le curve ellittiche permettono chiavi cos\u00ec corte, la nostra spiegazione delle <a href=\"\/it\/funzioni-hash\/\">funzioni hash crittografiche<\/a> e dei fondamenti matematici della crittografia moderna fornisce il contesto. La direzione del settore \u00e8 chiara: ECDSA oggi, e algoritmi resistenti ai computer quantistici nei prossimi anni.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"6-errori-comuni-da-evitare-con-certbot\">6 errori comuni da evitare con Certbot<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">La maggior parte dei fallimenti con <strong>Certbot<\/strong> nasce da pochi errori ricorrenti. Conoscerli in anticipo ti fa risparmiare ore.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Saltare lo staging e bruciare i limiti.<\/strong> Lanciare Certbot in produzione per &#8220;provare&#8221; esaurisce il limite di 5 certificati duplicati a settimana. Usa sempre <code>--dry-run<\/code> prima.<\/li>\n<li><strong>Porta 80 chiusa.<\/strong> La sfida HTTP-01 richiede che Let&#8217;s Encrypt raggiunga il server sulla porta 80. Un firewall cloud o UFW che la blocca fa fallire la validazione con un errore di connessione.<\/li>\n<li><strong>DNS non propagato.<\/strong> Chiedere un certificato subito dopo aver creato il record A, prima che il DNS si propaghi, produce un fallimento della sfida. Verifica con <code>dig<\/code> prima di lanciare Certbot.<\/li>\n<li><strong>Puntare ai file in archive invece che in live.<\/strong> Nginx deve puntare a <code>\/etc\/letsencrypt\/live\/dominio\/<\/code>. Le cartelle <code>archive<\/code> numerate cambiano ad ogni rinnovo e rompono la configurazione.<\/li>\n<li><strong>Dimenticare il deploy-hook.<\/strong> Senza ricaricare Nginx dopo il rinnovo, il server continua a servire il vecchio certificato finch\u00e9 non lo riavvii a mano.<\/li>\n<li><strong>Attivare HSTS troppo presto.<\/strong> Inserire HSTS con <code>max-age<\/code> lungo prima che HTTPS sia stabile pu\u00f2 rendere il sito irraggiungibile per i visitatori per mesi.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">C&#8217;\u00e8 un settimo errore che merita una menzione: affidarsi alle email di scadenza. Non esistono pi\u00f9 dal giugno 2025. Se la tua procedura mentale era &#8220;rinnovo quando arriva l&#8217;email&#8221;, aggiornala subito con un monitoraggio attivo.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"troubleshooting-8-problemi-risolti\">Troubleshooting: 8 problemi risolti<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Quando qualcosa va storto, l&#8217;errore di Certbot di solito indica la causa. Questa tabella raccoglie i problemi pi\u00f9 frequenti e la soluzione diretta.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Problema \/ errore<\/th><th>Causa probabile<\/th><th>Soluzione<\/th><\/tr><\/thead><tbody>\n<tr><td>&#8220;Timeout during connect&#8221; nella sfida HTTP-01<\/td><td>Porta 80 chiusa o firewall cloud<\/td><td>Apri la porta 80 in ingresso su UFW e sul pannello del provider<\/td><\/tr>\n<tr><td>&#8220;DNS problem: NXDOMAIN&#8221;<\/td><td>Record DNS assente o non propagato<\/td><td>Crea il record A e verifica con <code>dig dominio +short<\/code><\/td><\/tr>\n<tr><td>&#8220;Too many certificates already issued&#8221;<\/td><td>Limite di rate superato<\/td><td>Attendi il reintegro o passa allo staging per i test<\/td><\/tr>\n<tr><td>&#8220;command not found: certbot&#8221;<\/td><td>Link simbolico snap mancante<\/td><td>Esegui <code>sudo ln -s \/snap\/bin\/certbot \/usr\/bin\/certbot<\/code><\/td><\/tr>\n<tr><td>Nginx serve ancora il vecchio certificato<\/td><td>Manca il reload dopo il rinnovo<\/td><td>Aggiungi <code>--deploy-hook \"systemctl reload nginx\"<\/code><\/td><\/tr>\n<tr><td>&#8220;Could not automatically find a matching server block&#8221;<\/td><td>Manca <code>server_name<\/code> nel blocco Nginx<\/td><td>Aggiungi la direttiva <code>server_name dominio<\/code> e ricarica<\/td><\/tr>\n<tr><td>Wildcard rifiutato con HTTP-01<\/td><td>I wildcard richiedono DNS-01<\/td><td>Usa <code>--preferred-challenges dns<\/code> o un plugin DNS<\/td><\/tr>\n<tr><td>Errore &#8220;unauthorized&#8221; durante la validazione<\/td><td>File challenge servito da un altro virtual host<\/td><td>Verifica che il dominio risponda al server block corretto<\/td><\/tr>\n<\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Per qualsiasi errore non elencato, esegui Certbot con il flag <code>-v<\/code> per l&#8217;output verboso e controlla il log in <code>\/var\/log\/letsencrypt\/letsencrypt.log<\/code>. Quel file contiene quasi sempre la risposta esatta del server ACME, che \u00e8 la fonte pi\u00f9 affidabile sulla causa del fallimento.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"consigli-avanzati-per-la-produzione\">Consigli avanzati per la produzione<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Una volta che HTTPS funziona, alcune scelte separano un setup amatoriale da uno pronto per la produzione. Prima: testa il rinnovo in modo aggressivo. Esegui <code>certbot renew --dry-run<\/code> dopo ogni modifica importante a Nginx, perch\u00e9 un cambiamento alla configurazione pu\u00f2 rompere silenziosamente il rinnovo automatico, e con i certificati a vita breve del 2026 il margine d&#8217;errore \u00e8 minimo.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Seconda: valuta la stapling OCSP per ridurre la latenza dell&#8217;handshake, attivabile in Nginx con <code>ssl_stapling on<\/code> e <code>ssl_stapling_verify on<\/code>. Terza: per pi\u00f9 server dietro un load balancer, centralizza l&#8217;emissione su un nodo e distribuisci i certificati, oppure usa la sfida DNS-01 che non dipende dal nodo che riceve il traffico. Quarta: tieni d&#8217;occhio i profili ACME. Con il passaggio del profilo <code>tlsserver<\/code> a 45 giorni dal 13 maggio 2026, verifica quale profilo usa la tua versione di Certbot e regola il monitoraggio di conseguenza. La <a href=\"https:\/\/nginx.org\/en\/docs\/http\/configuring_https_servers.html\" target=\"_blank\" rel=\"noopener\">documentazione HTTPS di Nginx<\/a> e l&#8217;<a href=\"https:\/\/datatracker.ietf.org\/doc\/html\/rfc8555\" target=\"_blank\" rel=\"noopener\">RFC 8555 che definisce ACME<\/a> restano i riferimenti tecnici da tenere a portata di mano.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Quinta, sul fronte sicurezza: combina HTTPS con altre difese. Un certificato valido protegge i dati in transito ma non sostituisce password robuste e secondo fattore. La nostra guida alla <a href=\"\/it\/sicurezza-delle-password\/\">sicurezza delle password, hashing e secondo fattore<\/a> copre il livello applicativo. Per il quadro completo delle minacce e delle contromisure, parti dal nostro <a href=\"\/it\/security-hub\/\">hub sulla sicurezza online<\/a>. HTTPS \u00e8 la base, non l&#8217;intera fortezza.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"domande-frequenti-su-lets-encrypt-e-certbot\">Domande frequenti su Let&#8217;s Encrypt e Certbot<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"lets-encrypt-e-davvero-gratuito-anche-per-uso-commerciale\">Let&#8217;s Encrypt \u00e8 davvero gratuito anche per uso commerciale?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">S\u00ec. I certificati di Let&#8217;s Encrypt sono gratuiti per qualsiasi uso, incluso quello commerciale, senza limiti sul numero di siti oltre ai normali limiti di rate. Il progetto \u00e8 finanziato da ISRG, organizzazione no-profit, e dai suoi sponsor. Non c&#8217;\u00e8 un piano a pagamento e non c&#8217;\u00e8 un upsell.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"cosa-succede-se-dimentico-di-rinnovare-il-certificato\">Cosa succede se dimentico di rinnovare il certificato?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Il certificato scade e i browser mostrano un avviso di sicurezza che blocca l&#8217;accesso al sito. Dal giugno 2025 Let&#8217;s Encrypt non invia pi\u00f9 email di scadenza, quindi nessuno ti avvisa. Con il rinnovo automatico via systemd timer o cron e un monitoraggio esterno della scadenza, questo scenario non dovrebbe verificarsi.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"quanto-durano-i-certificati-di-lets-encrypt-nel-2026\">Quanto durano i certificati di Let&#8217;s Encrypt nel 2026?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Il certificato classico dura 90 giorni. Nel 2025 \u00e8 stata introdotta un&#8217;opzione a vita breve da 6 giorni, e dal 13 maggio 2026 il profilo <code>tlsserver<\/code> emette certificati con validit\u00e0 predefinita di 45 giorni. In tutti i casi il rinnovo automatico gestisce la durata senza che tu debba intervenire.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"posso-ottenere-un-certificato-wildcard-con-certbot\">Posso ottenere un certificato wildcard con Certbot?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">S\u00ec, ma solo tramite la sfida DNS-01. Let&#8217;s Encrypt non emette certificati wildcard tramite HTTP-01 o TLS-ALPN-01. Per un rinnovo automatico dei wildcard serve un plugin DNS del tuo provider (Cloudflare, Route 53 e altri) che crei e cancelli il record TXT in automatico.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"certbot-funziona-anche-con-apache-o-solo-con-nginx\">Certbot funziona anche con Apache o solo con Nginx?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Funziona con entrambi. Per Nginx si usa il flag <code>--nginx<\/code>, per Apache il flag <code>--apache<\/code>. Esiste anche la modalit\u00e0 <code>certonly<\/code> che ottiene solo il certificato senza toccare la configurazione del web server, utile dietro reverse proxy o con web server non supportati direttamente dai plugin.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"devo-usare-ecdsa-o-rsa-per-il-certificato\">Devo usare ECDSA o RSA per il certificato?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Usa ECDSA, raccomandata da Let&#8217;s Encrypt e ideale per la quasi totalit\u00e0 dei siti nel 2026. Offre handshake pi\u00f9 veloci e minor carico CPU rispetto a RSA, con la stessa sicurezza. Scegli RSA solo se devi servire client molto datati senza supporto per le curve ellittiche.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"lo-staging-serve-davvero-o-posso-saltarlo\">Lo staging serve davvero o posso saltarlo?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Serve, soprattutto durante i test. L&#8217;ambiente di staging ha limiti di rate molto pi\u00f9 alti e ti permette di provare l&#8217;automazione senza consumare i 5 certificati duplicati a settimana della produzione. Il modo pi\u00f9 rapido \u00e8 il flag <code>--dry-run<\/code>, che simula tutto il processo senza salvare nulla.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"quanti-certificati-ha-emesso-lets-encrypt-finora\">Quanti certificati ha emesso Let&#8217;s Encrypt finora?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Oltre 7 miliardi dal lancio nel 2015, secondo il rapporto annuale 2025 di ISRG, con una copertura di circa 762 milioni di siti web. Questo rende Let&#8217;s Encrypt la pi\u00f9 grande autorit\u00e0 di certificazione al mondo per volume di emissione.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"related-coverage\">Related Coverage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"\/it\/https-e-tls\/\">HTTPS e TLS: come viene protetta una connessione web<\/a><\/li>\n<li><a href=\"\/it\/openssl-certificati-chiavi\/\">OpenSSL 3.5 LTS: Chiavi e Certificati in 12 Step [2026]<\/a><\/li>\n<li><a href=\"\/it\/crittografia-end-to-end-nodejs\/\">Crittografia End-to-End in Node.js: 12 Step [2026]<\/a><\/li>\n<li><a href=\"\/it\/nis2-italia-direttiva-2026\/\">NIS2 Italia: Multe \u20ac10M e Solo 3,9% Pronto [2026]<\/a><\/li>\n<li><a href=\"\/it\/sicurezza-delle-password\/\">Sicurezza delle password: lunghezza, hashing e secondo fattore<\/a><\/li>\n<li><a href=\"\/it\/security-hub\/\">Sicurezza online: violazioni, password, HTTPS e phishing<\/a><\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><em>Fonti esterne: <a href=\"https:\/\/letsencrypt.org\/\" target=\"_blank\" rel=\"noopener\">Let&#8217;s Encrypt<\/a>, <a href=\"https:\/\/certbot.eff.org\/\" target=\"_blank\" rel=\"noopener\">Certbot (EFF)<\/a>, <a href=\"https:\/\/letsencrypt.org\/docs\/challenge-types\/\" target=\"_blank\" rel=\"noopener\">tipi di sfida ACME<\/a>, <a href=\"https:\/\/datatracker.ietf.org\/doc\/html\/rfc8555\" target=\"_blank\" rel=\"noopener\">RFC 8555 (ACME)<\/a>, <a href=\"https:\/\/nginx.org\/en\/docs\/http\/configuring_https_servers.html\" target=\"_blank\" rel=\"noopener\">documentazione HTTPS di Nginx<\/a>, <a href=\"https:\/\/letsencrypt.org\/2025\/01\/16\/6-day-and-ip-certs\/\" target=\"_blank\" rel=\"noopener\">annuncio certificati a 6 giorni e IP<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Nel 2026 servire un sito senza HTTPS significa perdere visitatori, posizionamento e fiducia. La buona notizia: un certificato TLS valido non costa pi\u00f9 nulla. Let&#8217;s Encrypt ha emesso oltre 7\u2026<\/p>\n","protected":false},"author":3,"featured_media":98,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-97","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security"],"_links":{"self":[{"href":"https:\/\/shattered.io\/it\/wp-json\/wp\/v2\/posts\/97","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/shattered.io\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/shattered.io\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/shattered.io\/it\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/shattered.io\/it\/wp-json\/wp\/v2\/comments?post=97"}],"version-history":[{"count":1,"href":"https:\/\/shattered.io\/it\/wp-json\/wp\/v2\/posts\/97\/revisions"}],"predecessor-version":[{"id":99,"href":"https:\/\/shattered.io\/it\/wp-json\/wp\/v2\/posts\/97\/revisions\/99"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/shattered.io\/it\/wp-json\/wp\/v2\/media\/98"}],"wp:attachment":[{"href":"https:\/\/shattered.io\/it\/wp-json\/wp\/v2\/media?parent=97"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/shattered.io\/it\/wp-json\/wp\/v2\/categories?post=97"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/shattered.io\/it\/wp-json\/wp\/v2\/tags?post=97"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}