Let's Encrypt e certificati SSL: la democrazia dell'HTTPS

Nel 2013, meno del 30% delle pagine web caricate dai browser usava HTTPS. La connessione non cifrata era la norma, non l'eccezione. Ottenere un certificato SSL richiedeva di pagare una Certificate Authority (CA) tra i 50 e i 500 dollari l'anno, di completare un processo manuale di verifica dell'identità che durava giorni, e di possedere competenze tecniche per l'installazione e la configurazione. Per i grandi siti commerciali aveva senso investirlo. Per blog personali, piccole associazioni, strumenti interni aziendali, e la lunga coda di milioni di siti minori, l'HTTPS era semplicemente fuori portata.

Oggi quel numero supera l'80% delle pagine web caricate globalmente. Questa trasformazione ha un nome preciso: Let's Encrypt.

HTTP vs HTTPS: perché la cifratura conta

HTTP (HyperText Transfer Protocol) trasmette i dati in chiaro. Chiunque si trovi sulla stessa rete — il gestore del WiFi del bar, l'ISP, un router compromesso lungo il percorso — può leggere ogni byte scambiato tra il browser e il server: pagine visitate, password inserite, informazioni personali nei form, cookie di sessione. In una connessione HTTP, il cookie di autenticazione di un account email è visibile a chiunque intercetti il traffico.

HTTPS aggiunge un layer crittografico chiamato TLS (Transport Layer Security) tra HTTP e TCP. Con TLS attivo, il traffico è cifrato con cifrari simmetrici moderni (AES-GCM, ChaCha20-Poly1305), autenticato con MAC crittografici, e l'identità del server è verificata attraverso un sistema di certificati digitali. Anche se un aggressore intercetta i pacchetti, vede solo dati cifrati indecifrabili senza la chiave di sessione.

Ma l'HTTPS non garantisce solo la confidenzialità: garantisce anche l'integrità. Senza HTTPS, un ISP o un hotspot WiFi ostile può iniettare nel traffico script JavaScript arbitrari, banner pubblicitari, o redirect a siti di phishing — ed è una pratica documentata. Con HTTPS, qualsiasi modifica al contenuto in transito rende la firma MAC non valida, e il browser rifiuta il contenuto.

Il TLS handshake: come si stabilisce la connessione sicura

Quando il browser apre una connessione HTTPS, avviene un handshake TLS (nella versione 1.3, la più recente) che si conclude in un solo round-trip:

1. Client Hello: Il browser invia le versioni TLS supportate, una lista di cipher suite supportate, e una key_share: la propria metà dello scambio di chiavi ECDH con Curve25519 o X25519.

2. Server Hello: Il server risponde con la cipher suite scelta, la propria metà dello scambio ECDH, il certificato TLS (che include la chiave pubblica del server), e una firma su tutto quanto usando la propria chiave privata.

3. Verifica del certificato: Il browser verifica il certificato del server: controlla che sia firmato da una CA fidata (inclusa nel trust store del sistema operativo o del browser), che il nome di dominio corrisponda, e che il certificato non sia scaduto o revocato.

4. Derivazione delle chiavi di sessione: Entrambe le parti derivano le chiavi simmetriche per cifrare la sessione dall'output dello scambio ECDH. La cifratura inizia immediatamente.

TLS 1.3 ha eliminato le cipher suite deboli e i meccanismi legacy di TLS 1.2 (RSA key exchange, CBC mode, RC4, MD5, SHA1), raggiungendo sia maggiore sicurezza che migliori prestazioni (1 RTT invece di 2).

Certificati X.509 e la catena di fiducia

Un certificato TLS è un documento digitale nel formato X.509 che certifica l'associazione tra un nome di dominio e una chiave pubblica. Il certificato contiene: il nome del dominio (Common Name o Subject Alternative Names), la chiave pubblica del server, il periodo di validità, e la firma digitale della Certificate Authority che lo ha emesso.

La catena di fiducia funziona così: ogni sistema operativo e browser mantiene un root store, un insieme di certificati di CA radice ritenute fidate (tipicamente 100-200 CA). Le CA radice firmano i certificati di CA intermedie, che a loro volta firmano i certificati dei siti web. Quando il browser riceve il certificato di esempio.com, verifica che sia firmato da una CA intermedia, che quest'ultima sia firmata da una CA radice, e che quella CA radice sia nel proprio root store.

Le CA radice sono organizzazioni rigorosamente certificate e auditate: DigiCert, Comodo/Sectigo, GlobalSign, Entrust, e ora anche ISRG (la società dietro Let's Encrypt). L'inserimento nel root store dei browser e dei sistemi operativi è un processo lungo e vincolante: richiede anni di audit indipendenti, conformità ai requisiti del CA/Browser Forum, e approvazione da parte di Apple, Google, Mozilla e Microsoft.

Il problema storico dei certificati SSL: costi e complessità

Prima di Let's Encrypt, il mercato dei certificati SSL era dominato da poche grandi CA che lo usavano come fonte di profitto. I prezzi variavano enormemente:

Il processo di verifica per i certificati OV/EV richiedeva documenti legali, telefonate di verifica, e poteva durare settimane. La gestione del rinnovo era manuale e spesso trascurata, portando a certificati scaduti e siti irraggiungibili. Esistevano certificati gratuiti (StartSSL, CACert) ma con processi complicati e supporto limitato.

Il risultato era un Internet a due velocità: i siti importanti e le aziende con budget avevano l'HTTPS, tutti gli altri no.

La nascita di Let's Encrypt: ISRG e la missione

Nel 2012, due ingegneri di Mozilla — Josh Aas e Eric Rescorla — iniziarono a ragionare su come risolvere il problema alla radice. L'idea era semplice ma rivoluzionaria: creare una CA pubblica, senza scopo di lucro, che emettesse certificati DV gratuitamente e in modo completamente automatizzato.

Nel 2013, insieme a EFF, Cisco, Akamai e altri, fondarono la Internet Security Research Group (ISRG), un'organizzazione no-profit con la missione esplicita di portare HTTPS a tutto l'Internet. Let's Encrypt venne annunciato pubblicamente nel novembre 2014 e aprì la beta pubblica nel dicembre 2015. Nel 2016 uscì dalla beta: chiunque poteva ottenere un certificato SSL gratuito e automatico in pochi secondi.

Il finanziamento arriva da donazioni di grandi aziende tecnologiche (Google, Mozilla, Cisco, Facebook/Meta, AWS, OVH, e centinaia di altri) che riconoscono il valore pubblico dell'infrastruttura che Let's Encrypt fornisce.

Il protocollo ACME: l'automazione della verifica

Il cuore tecnico di Let's Encrypt è il protocollo ACME (Automatic Certificate Management Environment), standardizzato come RFC 8555 nel 2019. ACME permette a un client software di richiedere, verificare e ricevere un certificato SSL in modo completamente automatizzato, senza intervento umano.

La verifica del controllo del dominio avviene attraverso due modalità principali:

HTTP-01 challenge: ACME genera un token casuale e chiede al client di renderlo disponibile all'URL http://[dominio]/.well-known/acme-challenge/[token]. I server Let's Encrypt tentano di accedere a quell'URL via HTTP: se trovano il token corretto, la proprietà del dominio è confermata. Questo metodo richiede che il server sia raggiungibile su porta 80 dall'esterno.

DNS-01 challenge: Il client crea un record TXT nel DNS del dominio con un valore specifico generato da ACME. Let's Encrypt verifica il record DNS. Questo metodo è più flessibile: funziona anche per domini non raggiungibili via HTTP (server interni, indirizzi IP privati), ed è l'unico modo per ottenere certificati wildcard (*.miodominio.com). Richiede però che il client possa modificare automaticamente i record DNS, il che richiede accesso all'API del provider DNS.

Esiste anche il metodo TLS-ALPN-01, che usa la porta 443 con un'estensione TLS speciale, utile quando la porta 80 è bloccata.

Certbot: il client ufficiale

Certbot, sviluppato da EFF, è il client ACME di riferimento. È disponibile per tutte le principali distribuzioni Linux e si integra automaticamente con Apache e Nginx:

apt install certbot python3-certbot-nginx
certbot --nginx -d miodominio.com -d www.miodominio.com

Certbot modifica automaticamente la configurazione di Nginx, ottiene il certificato, configura il redirect HTTP→HTTPS, e installa un cron job o un timer systemd per il rinnovo automatico. Il rinnovo avviene automaticamente quando il certificato ha meno di 30 giorni di validità residua.

Per i siti statici o configurazioni personalizzate, si può usare la modalità standalone:

certbot certonly --standalone -d miodominio.com

O la modalità webroot, che scrive i file di challenge nella document root di un web server già in esecuzione.

Alternative: acme.sh e Caddy

acme.sh è un client ACME scritto interamente in bash, senza dipendenze esterne. Supporta decine di provider DNS per il challenge DNS-01 e moltissime CA ACME (Let's Encrypt, ZeroSSL, Buypass Go SSL). È spesso preferito dagli amministratori che voglio il massimo controllo senza dipendenze Python.

Caddy integra il supporto ACME nativamente nel web server: configurando un dominio nel Caddyfile, Caddy ottiene e rinnova automaticamente il certificato Let's Encrypt senza nessuna configurazione aggiuntiva. È la soluzione più semplice esistente per HTTPS automatico.

Librerie ACME sono disponibili per praticamente tutti i linguaggi: acme-client per Go, acme per Rust, certifi per Python, node-acme-client per Node.js. Questo ha permesso l'integrazione nativa in tool come Traefik, HAProxy, e molti altri.

Tipi di certificati: DV, OV, EV

Let's Encrypt emette solo certificati DV (Domain Validation): certificati che provano il controllo tecnico del dominio, non l'identità legale dell'organizzazione. Per la maggior parte dei siti web, il DV è sufficiente: garantisce la cifratura e che si stia comunicando con chi controlla quel dominio.

I certificati OV (Organization Validation) includono informazioni verificate sull'organizzazione (nome legale, paese, provincia). Richiedono ancora una CA commerciale, un processo manuale di verifica, e costano da 50 a 300 euro/anno. Rimangono rilevanti per siti istituzionali e aziende che vogliono mostrare la propria identità nei dettagli del certificato.

I certificati EV (Extended Validation) richiedevano la verifica più approfondita e mostravano il nome dell'azienda nella barra degli indirizzi del browser con sfondo verde. Tuttavia, nel 2019 Chrome e Firefox hanno rimosso questo indicatore visivo (ricerche UX dimostravano che gli utenti non lo notavano e non portava benefici di sicurezza misurabili). Gli EV esistono ancora ma il loro vantaggio pratico è oggi molto limitato.

Certificati wildcard e rinnovo automatico

Un certificato wildcard (*.miodominio.com) copre tutti i sottodomini di primo livello di un dominio. Con un singolo certificato si copre www.miodominio.com, app.miodominio.com, api.miodominio.com, ecc. Let's Encrypt supporta i wildcard dal 2018, ottenibili solo tramite challenge DNS-01.

La validità dei certificati Let's Encrypt è di 90 giorni, molto più breve dei 1-2 anni dei certificati commerciali tradizionali. Questa scelta è deliberata: incentiva l'automazione del rinnovo (impossibile ignorare un certificato che scade ogni 3 mesi), limita la finestra di esposizione in caso di compromissione di una chiave privata, e permette una revoca implicita più rapida.

Recentemente Let's Encrypt ha annunciato l'intenzione di offrire certificati con validità di soli 6 giorni per chi vuole la rotazione più frequente possibile, ulteriormente riducendo la finestra di rischio.

I numeri: l'impatto di Let's Encrypt

I dati parlano da soli. Let's Encrypt aveva emesso 1 miliardo di certificati nel febbraio 2020 (in soli 4 anni di operatività). Al 2024, gestisce oltre 300 milioni di domini attivi con certificati validi. Secondo le statistiche di Firefox Telemetry, la percentuale di pagine web caricate con HTTPS è passata dal 38% nel 2015 (prima del lancio pubblico) all'attuale 88%+.

Let's Encrypt detiene circa il 63.9% del mercato dei certificati SSL attivi su Internet, superando di gran lunga qualsiasi CA commerciale. Questa concentrazione è spesso discussa: affidarsi a una singola organizzazione per la metà dell'infrastruttura di fiducia di Internet crea un singolo punto di fallimento. ISRG gestisce questo rischio con alta disponibilità geografica, audit regolari, e un'architettura tecnica rigorosa.

HSTS: forzare sempre HTTPS

HSTS (HTTP Strict Transport Security) è un header HTTP che i siti possono inviare per istruire il browser a usare sempre HTTPS per quel dominio, anche se l'utente digita manualmente http://. Una volta ricevuto l'header HSTS, il browser memorizza l'istruzione per il periodo specificato (max-age) e non effettuerà mai più connessioni HTTP non cifrate a quel dominio.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Il parametro preload permette di sottomettere il dominio alla HSTS Preload List, mantenuta da Chrome e adottata da tutti i browser principali: il dominio viene hardcodato come HTTPS-only nel browser stesso, prima ancora della prima connessione. Questo elimina la vulnerabilità del "first visit": una connessione HTTP iniziale che potrebbe essere intercettata prima che il browser riceva l'header HSTS.

Errori comuni e come risolverli

I problemi più frequenti con Let's Encrypt e HTTPS in generale:

Let's Encrypt ha dimostrato che l'infrastruttura di sicurezza di base di Internet non deve essere un business: può essere un bene comune, finanziato collettivamente, disponibile gratuitamente per chiunque. È uno dei pochi progetti nella storia di Internet che ha migliorato la sicurezza di tutti gli utenti senza che questi dovessero fare nulla di diverso da accedere ai siti che già usavano.