Il 12 aprile 2016 Let’s Encrypt ha chiuso la beta pubblica ed è entrata in disponibilità generale, pubblicando lo stesso giorno la specifica della sua API v1 del protocollo ACME (Automated Certificate Management Environment). La beta era partita il 3 dicembre 2015; nei mesi tra le due date la Certificate Authority dell’Internet Security Research Group (ISRG) ha emesso certificati per qualche milione di domini, su invito e con limiti d’uso. Rispetto alle CA commerciali tradizionali la differenza non è il prezzo — pur essendo gratuita — ma che l’intero ciclo di vita del certificato gira senza un operatore umano.

Contesto

Fino al 2015, mettere HTTPS su un dominio voleva dire generare una Certificate Signing Request, mandarla a una CA commerciale (Comodo, GlobalSign, DigiCert, Symantec), passare una verifica di proprietà via email o via file, scaricare il certificato e installarlo a mano. Il certificato durava uno o più anni e alla scadenza andava ri-emesso con lo stesso giro manuale. Ne uscivano due problemi pratici: per un sito piccolo il costo e l’attrito erano sproporzionati, e i certificati scaduti perché qualcuno se n’era dimenticato erano un disservizio ricorrente. Nel 2014 Google aveva annunciato che HTTPS sarebbe diventato un segnale di ranking, e la spinta verso il trasporto cifrato come default era già partita; mancava un modo per emettere certificati senza tenere un umano nel ciclo.

Architettura

ACME scambia messaggi JSON firmati su HTTPS tra un client (che gira sul server a cui serve il certificato) e il server ACME della CA. Il flusso, nella v1 resa disponibile in questa data, è questo:

  1. Registrazione account — il client genera una coppia di chiavi e registra la chiave pubblica sul server ACME. Le richieste successive le firma con quella chiave (JWS), quindi l’identità dell’account è la chiave stessa, non una credenziale username/password.
  2. Validazione di dominio — per ogni nome richiesto la CA propone delle sfide; il client ne risolve almeno una per dimostrare di avere il controllo del dominio. Nel 2016 le sfide sono http-01 (pubblicare un token in un file sotto http://dominio/.well-known/acme-challenge/), dns-01 (pubblicare un record TXT su _acme-challenge.dominio) e tls-sni-01 (rispondere a un handshake TLS con un certificato auto-firmato derivato dal token e scelto via SNI).
  3. Emissione — passata la validazione, il client manda la CSR e la CA restituisce il certificato firmato dall’intermedio.
  4. Rinnovo — è la ripetizione degli stessi passi; non c’è un’operazione di rinnovo a sé, si ri-emette e basta.

Il certificato che emette Let’s Encrypt è di tipo Domain Validation (DV) e vale 90 giorni. Non emette certificati Organization Validation, Extended Validation né wildcard. La catena di fiducia passa per l’intermedio Let's Encrypt Authority X3, firmato a sua volta dalla root ISRG Root X1; siccome ISRG Root X1 non è ancora nei trust store dei browser, l’intermedio è anche cross-signed dalla root DST Root CA X3 di IdenTrust, già diffusa ovunque, così i certificati vengono validati subito senza aspettare l’inclusione diretta della root ISRG.

Il punto critico

La scelta che condiziona tutto il resto è la durata di 90 giorni. È una decisione difensiva: un certificato che vive poco riduce la finestra di danno di una chiave privata compromessa e abbassa la dipendenza dalla revoca, che nel TLS reale funziona male — CRL e OCSP hanno buchi di copertura e soft-fail lato client. Una vita breve sostituisce in parte il bisogno di revocare: il certificato scade e via.

Il prezzo da pagare è che rinnovare a mano ogni 60-80 giorni è impraticabile. Un certificato annuale lo potevi dimenticare una volta l’anno e cavartela; uno a 90 giorni tenuto a mano è un disservizio che prima o poi arriva. La durata breve, detto altrimenti, costringe ad automatizzare: o automatizzi il rinnovo via ACME, o torni a un certificato commerciale a lunga scadenza. È il modo voluto con cui la CA spinge l’ecosistema verso client che girano in cron.

ACME verifica il controllo del dominio in un certo istante, non la titolarità. Chi controlla il contenuto servito su http://dominio/.well-known/acme-challenge/, o i record DNS del dominio, o l’handshake TLS sulla porta 443, può ottenere un certificato per quel nome. Una parte della superficie di sicurezza si sposta così sulla configurazione di DNS e hosting: il takeover di un sottodominio abbandonato o un record DNS pendente diventano percorsi diretti all’emissione.

Implicazioni

Il protocollo è pubblico e in discussione all’IETF — c’è un working group ACME e una serie di draft in lavorazione — quindi client e server non sono legati a Let’s Encrypt. Già adesso convivono più client: Certbot della EFF (Python, il riferimento ufficiale, con plugin per Apache e Nginx), acme.sh (uno script shell senza dipendenze, comodo sulle macchine minimali), lego (libreria e CLI in Go). Che girino client diversi sullo stesso protocollo conferma che ACME è un’interfaccia aperta, non un dettaglio interno della CA.

Sul piano operativo, l’ordine giusto è automatizzare prima di emettere in produzione: si installa un client, si verifica che il rinnovo automatico funzioni in staging, e solo dopo si punta il traffico sul certificato. L’errore tipico è trattare Let’s Encrypt come una CA tradizionale — emettere a mano una volta sola — e ritrovarsi il sito in errore TLS dopo tre mesi.

Limiti

Al 12 aprile 2016 restano vincoli concreti. Ci sono rate limit per dominio registrato e per indirizzo IP che rendono Let’s Encrypt poco adatta a emissioni di massa non pianificate. Mancano i certificati wildcard: chi ha molti sottodomini deve elencarli come SAN nella stessa richiesta o emettere certificati separati, sempre entro i limiti di tasso. La sfida tls-sni-01 ha implicazioni di sicurezza che dipendono da come l’hosting condiviso instrada l’SNI, e va valutata caso per caso rispetto a http-01. Infine il DV certifica che il trasporto verso quel dominio è autentico e cifrato, non chi c’è dietro al sito. Garantisce il canale, non l’identità del soggetto.

Sul mio sito ho tolto il certificato commerciale annuale e ci ho messo Certbot con un timer di rinnovo; il punto da curare non è stato l’emissione, immediata, ma verificare che il reload del web server dopo il rinnovo avvenga senza che debba intervenire io.

Immagine di copertina: Schermata di terminale del client Let’s Encrypt: messaggio ‘Congratulations! You have successfully enabled https://…’ con la lista… — schermata di Peter Eckersley, CC BY 3.0 — https://commons.wikimedia.org/wiki/File:Letsencrypt_screenshot_4_success.png