Rinnovo Let's Encrypt: i tre guasti classici

Il rinnovo automatico di certificato ha una personalità tutta sua: funziona impeccabilmente per mesi, poi si ferma, e non lo dice a nessuno. Il comando gira sempre alla sua ora. Esce semplicemente in errore, in un file di log che nessuno apre. Ecco i tre modi in cui si rompe davvero, e l'unica verifica che li acchiappa tutti e tre.

I tre guasti, in una tabella

La terza riga è quella che costa di più, proprio perché il registro sembra perfetto. Una supervisione che legge il registro di rinnovo dichiara dunque che va tutto bene mentre i vostri visitatori vedono uno schermo rosso.

1. La sfida di validazione non raggiunge più il vostro server

Per confermare che controllate il dominio, l'autorità di certificazione chiede un file sotto /.well-known/acme-challenge/… sul vostro sito. Il vostro server deve servirlo, in HTTP semplice, senza interferenze.

Ciò che rompe questo, mesi dopo la messa in opera:

• Una redirezione globale verso HTTPS o verso un nuovo dominio, aggiunta per ottime ragioni, e che acchiappa anche il percorso della sfida.
• Una regola di firewall o di WAF che si mette a filtrare i percorsi sconosciuti, o che blocca gli indirizzi da cui arriva la validazione.
• Una rotta acchiappatutto del framework che trasforma ogni URL sconosciuto in pagina 404, compreso il file della sfida, che ora restituisce un 404 in una bella impaginazione.
• Una protezione antirobot installata davanti al sito, che presenta una pagina di attesa a ogni client che non esegue JavaScript.

Il comando di rinnovo non è cambiato. Il suo ambiente sì. È ciò che rende difficile imputare questo guasto: nessuno ha toccato il certificato, eppure non si rinnova più.

Il test sta in una riga, da qualsiasi macchina:

mkdir -p /var/www/html/.well-known/acme-challenge && echo ok > /var/www/html/.well-known/acme-challenge/test
curl -sI http://esempio.it/.well-known/acme-challenge/test | head -n 1

La risposta attesa è 200. Un 301 verso HTTPS è già un problema in certe configurazioni, e un 403 o un 404 lo è sempre.

2. Il DNS si è mosso

Se rinnovate un certificato jolly, la validazione passa da un record DNS invece che da un file. Questo presuppone un token API presso il vostro fornitore DNS, messo in un file di configurazione, che scade o viene revocato in silenzio il giorno in cui qualcuno ruota le credenziali.

Tre varianti della stessa storia:

• Il token è stato revocato durante una pulizia di sicurezza, sei mesi prima.
• Il dominio è stato trasferito presso un altro registrar, e nessuno ha pensato a informarne lo script.
• I server dei nomi sono cambiati, la zona è ora gestita altrove, e lo script scrive coscienziosamente il suo record in una zona che nessuno consulta più.

Nei tre casi l'errore è esplicito nel registro. Bisogna però che qualcuno lo apra, ed è tutto qui il problema. Chi gestisce un certificato jolly farebbe bene a mettere la prova a vuoto nello stesso giorno in cui rivede le credenziali: i due compiti falliscono per la stessa ragione.

3. Il rinnovo è riuscito, la distribuzione no

È la versione crudele. Il nuovo certificato è sul disco, datato oggi, perfettamente valido. Il vostro server web presenta ancora il vecchio, perché non è stato ricaricato dal suo avvio.

Niente nel registro di rinnovo sembra anormale. Il file c'è. E i vostri visitatori ricevono comunque l'avvertimento di sicurezza a schermo intero.

La causa è quasi sempre un gancio di ricarica assente o silenzioso:

# La ricarica deve far parte del rinnovo, non di un gesto manuale
--deploy-hook "systemctl reload nginx"

Due trappole da conoscere. Un gancio che fallisce non fa fallire il rinnovo: lascia un messaggio nel registro e restituisce il controllo. E un servizio che ha bisogno di un riavvio completo, anziché di una ricarica, non prende il nuovo file; è frequente sulle configurazioni che terminano il TLS altrove che nel server web, dietro un proxy o un bilanciatore di carico, dove il certificato deve essere spinto in due punti.

Il quarto guasto, più raro e più spiazzante

I tre precedenti vengono dalla vostra installazione. Questo viene da altrove, e spiazza perché il comando è corretto e il server è irreprensibile.

La quota è stata raggiunta. Le autorità di certificazione limitano il numero di certificati emessi per uno stesso dominio in un periodo dato. Ci si arriva raramente in funzionamento normale, e molto facilmente in ciclo di debug: dieci tentativi di riemissione nel pomeriggio, ed eccovi bloccati per una settimana con un certificato scaduto in produzione. È la ragion d'essere della prova a vuoto, che non consuma nulla.

La chiave di account è sparita. Una reinstallazione del server, un ripristino parziale, un contenitore ricostruito senza il suo volume: il client non ritrova più l'account che possedeva i certificati, e riparte da zero senza dirlo chiaramente.

Il dominio non risolve più verso di voi. Un record modificato, una migrazione in corso, un passaggio mal terminato. La validazione fallisce perché atterra su un'altra macchina, il che è esatto e non ha nulla a che vedere con il certificato.

Diagnosticare in tre comandi

certbot renew --dry-run                 # rigioca tutto il rinnovo senza consumare quota
curl -sI http://esempio.it/.well-known/acme-challenge/test   # la sfida passa?
echo | openssl s_client -connect esempio.it:443 2>/dev/null | openssl x509 -noout -dates

Il primo acchiappa i guasti 1 e 2. Il terzo acchiappa il guasto 3, ed è il solo a dire ciò che il pubblico riceve davvero.

E se volete solo sapere che cosa riceve il pubblico in questo momento, senza aprire un terminale, la pagina che legge un certificato risponde a questa domanda precisa con un solo indirizzo.

Che cosa non fare durante il guasto

Non riemettete in ciclo: è così che un problema riparabile diventa un problema di una settimana. Non tagliate HTTPS per «rimettere il sito in linea»: tutti i link del web che puntano ai vostri indirizzi in https:// si romperebbero, e i browser memorizzano a lungo questa preferenza. E non installate un certificato autofirmato come rimedio: produce esattamente la stessa pagina rossa, con le stesse conseguenze, più un secondo problema da disfare poi.

La verifica che li acchiappa tutti e tre

Ciascuno di questi guasti è invisibile dall'interno ed evidente dall'esterno. Allora guardate dall'esterno: aprite una connessione TLS verso il vostro stesso nome host e leggete la data di scadenza del certificato realmente servito.

Questa sola misura copre in un colpo una sfida fallita, un problema DNS e una ricarica mancante, perché tutti e tre finiscono nello stesso posto: un vecchio certificato ancora presentato al pubblico. Ha anche il merito di non presupporre nulla della vostra installazione, il che la rende valida dopo un cambio di host o di stack tecnico.

Avvisate a trenta giorni, sette giorni e un giorno. Trenta lasciano lo spazio per fare debug con calma; uno acchiappa la ricarica che non è mai avvenuta. Una verifica quotidiana basta ampiamente, ed è un caso in cui aumentare la frequenza non porta nulla: una data di scadenza non cambia da un'ora all'altra.

Due abitudini che valgono la pena

Rinnovare con margine. A sessanta giorni su un certificato di novanta, un fallimento vi lascia un mese anziché un pomeriggio. È l'impostazione predefinita della maggior parte dei client, ed è uno dei rari valori predefiniti che non bisogna assolutamente toccare.

Provare il rinnovo, non solo il certificato. La prova a vuoto esiste in quasi tutti i client. Lanciarla una volta al mese trasforma un guasto silenzioso in un guasto noto, mesi prima che conti. E poiché nessun altro vi avviserà, è il vostro unico allarme anticipato.

Quando è già scaduto

Non cercate prima la causa. Rinnovate e ricaricate, rimettete il sito in stato, e fate l'indagine dopo: è lo stesso ordine dei primi quindici minuti di un incidente, per la stessa ragione, ossia che un sito bloccato costa qualcosa a ogni minuto mentre voi capite.

Niente di tutto ciò cambia il vostro posizionamento, di passaggio: HTTPS pesa molto meno per i motori di quanto il panico suggerisca. Conta per la persona che non riesce ad aprire il vostro sito.