Alcuni link in questa pagina sono link di affiliazione: se ti registri tramite questi link, il sito riceve una commissione senza costi aggiuntivi per te. Prezzi e consigli non cambiano.

Il 17 ottobre 2026 un ricercatore ha comunicato ai programmi root che le chiavi private di otto CA intermedie di eMudhra erano compromesse, e lo ha dimostrato nel modo più brutale: ha firmato un breve messaggio con ciascuna delle otto chiavi e ha allegato le firme. Chiunque può verificarle con OpenSSL. Le chiavi erano recuperabili da aprile 2025.

I browser sono stati corretti in pochi giorni. Firefox e Chrome hanno bloccato gli intermedi il 17, le piattaforme Microsoft il 20, i prodotti Apple il 22. Quello con cui navighi è, ormai, a posto.

Le macchine che amministri sono un altro discorso. Questa è la checklist per quelle, più le parti della storia che decidono cosa conviene controllare. Tutto ciò che riguarda l’incidente viene dalla pagina dell’incidente, che abbiamo riletto il giorno della pubblicazione. I quattro endpoint di test del passo 1 li abbiamo lanciati su una nostra macchina Ubuntu 26.04, e tutti e quattro sono falliti con un errore di certificato, che è il risultato voluto. Non abbiamo controllato ogni runtime presente, e i passi qui sotto non sono il resoconto di quel lavoro.

Cosa si è rotto davvero

Gli otto intermedi risalgono a root di cui si fidano i programmi root di Mozilla, Microsoft, Apple e Chrome. Chi possiede una delle chiavi private può emettere un certificato per qualunque dominio, e un client che si fida ancora dell’intermedio lo accetterà.

La causa vale la pena di ricordarla. La CA ha generato le chiavi in modo errato, quindi si possono ricavare dai certificati stessi. Era vero fin dal giorno in cui i certificati furono creati, aprile 2025. I log di Certificate Transparency non contengono voci per questi intermedi in quel periodo, perciò i client che impongono CT, cioè i browser principali, non potevano essere attaccati così. Per i client che non controllano CT è un’altra storia, e la pagina dell’incidente dice chiaramente che nessuno sa se degli attaccanti abbiano sfruttato il difetto contro di loro.

La CA ha revocato gli intermedi, e i programmi root hanno distribuito la revoca con i propri canali: OneCRL e CRLite per Mozilla, CRLSets per Chrome. È così che un browser resta protetto senza una nuova build. Moltissimi client non guardano nessuno di questi canali.

Due livelli di fiducia, e ne è stato colpito uno solo

La maggior parte delle guide al self-hosting li mescola, quindi conviene separarli.

I tuoi certificati sono a posto. Se Caddy, Traefik, acme.sh o certbot ottengono i certificati da Let’s Encrypt, nulla in essi è cambiato. Gli intermedi di eMudhra non fanno parte di quella catena, e il protocollo ACME e le chiavi del tuo account non c’entravano. Il rinnovo continua a funzionare.

Quello di cui si fidano i tuoi strumenti è la parte esposta. Ogni richiesta HTTPS in uscita dal tuo server (git pull, curl verso un’API, l’installazione di un pacchetto, il pull di un container, un webhook) è affidabile quanto lo store dei certificati di quella macchina. Se contiene ancora gli intermedi sbagliati, qualcuno sul percorso di rete può spacciarsi per GitHub, per il tuo mirror di pacchetti o per qualsiasi API, e il client lo accetterà senza fiatare.

Questo è tutto il rischio, e la maggior parte sta in software che non è un browser.

Perché «aggiorna il sistema» non è tutta la soluzione

Due cose distinguono i browser da tutto il resto.

Primo, la revoca. I browser fanno revocare questi intermedi tramite OneCRL, CRLite e CRLSets. curl, git, i binari Go e la maggior parte dei runtime non usano nulla di tutto ciò, e per loro l’unica cura è un trust store che non contenga più gli intermedi.

Secondo, Certificate Transparency. I browser rifiutano i certificati mai registrati nei log. Alla maggior parte dei client non-browser non interessa. La pagina dell’incidente gestisce per questo due host di test aggiuntivi: i loro certificati non sono mai stati registrati in CT, quindi un client che vi si collega si fida degli intermedi sbagliati e non impone nemmeno CT. È la combinazione che un attaccante può usare senza che nessuno se ne accorga.

Il lavoro quindi non è un aggiornamento, ma uno per ogni programma che porta con sé un trust store o ne eredita uno.

L’audit da 30 minuti

Eseguilo su ogni server, runner CI e macchina di sviluppo che tocchi. Ogni passo è uno o due comandi.

1. Aggiornare il bundle CA di sistema

Debian e Ubuntu:

sudo apt update && sudo apt upgrade -y ca-certificates

RHEL, Fedora, Alma, Rocky:

sudo dnf upgrade -y ca-certificates

Alpine:

sudo apk upgrade ca-certificates

Le versioni corrette dei pacchetti sono elencate nella pagina dell’incidente. Per Debian 12 è 20250419~deb12u2, per Ubuntu 24.04 20260816ubuntu0.24.04.1, per Alpine 20261020-r0. Confronta con dpkg -l ca-certificates o apk info ca-certificates, poi fai il test vero. Un errore di certificato significa che questo client non si fida degli intermedi compromessi. Una risposta riuscita significa che sei ancora esposto:

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
curl https://dv-g3b-noct-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/

Se usi Java dai pacchetti Debian o Ubuntu, c’è un’altra cosa: l’aggiornamento di sistema non rinfresca il keystore Java, per un vecchio bug di ca-certificates-java. Il consiglio della pagina dell’incidente è ricrearlo come root:

rm -f /etc/ssl/certs/java/cacerts && update-ca-certificates --fresh

2. Correggere i bundle che l’aggiornamento di sistema non ha mai toccato

Diversi runtime portano una copia propria e non si accorgono del tuo aggiornamento di ca-certificates.

requests di Python legge il bundle certifi, non lo store di sistema. La versione corretta è certifi 2026.10.19, e pip stesso è corretto dalla 26.2.2:

pip install --upgrade certifi pip

Node.js include un proprio store di root e per impostazione predefinita non legge quello di sistema. Le versioni corrette sono 26.12.1, 24.22.1 e 22.23.4, quindi un servizio Node a lunga durata ha bisogno di un Node più recente, non di un ca-certificates più recente. Go su Linux legge lo store di sistema, ma il progetto ha comunque pubblicato correzioni nelle versioni 1.27.3 e 1.26.10, e i programmi Rust che includono webpki-roots vanno ricompilati con un crate corretto.

Quando abbiamo guardato, certbot e containerd risultavano ancora in sospeso nella pagina dell’incidente. Ricontrolla quella pagina prima di dare per scontato che la tua versione sia coperta.

Tutto ciò che legge lo store di sistema va comunque riavviato. Un servizio avviato prima dell’aggiornamento tiene in memoria il vecchio store finché non lo riavvii.

3. Rifare il pull o ricostruire le immagini dei container

Un’immagine congela il proprio bundle di CA al momento della build. Se è stata costruita prima che la distribuzione rilasciasse la rimozione, si fida degli intermedi per quanto sia aggiornato l’host.

docker pull debian:bookworm   # oppure la tua immagine base
docker compose build --pull   # se costruisci le tue

Il problema: un vecchio tag non viene mai ricostruito. Se il tuo Dockerfile dice ancora node:20, golang:1.23 o alpine:3.19, quelle righe sono a fine vita, e un nuovo pull restituisce lo stesso bundle obsoleto. Passa a un tag supportato. Per le immagini che non costruisci tu, controlla che l’editore abbia pubblicato un nuovo tag dopo il 20 ottobre. È il passo che la maggior parte delle persone salta, ed è quello che protegge i container.

4. Aggiornare le app Electron ovunque sviluppi

Le app Electron ricevono la correzione solo quando vengono ricostruite su una release di Electron corretta (44.9.1, 43.8.1 e 42.11.16 sono le linee corrette). Aggiornare il sistema operativo o il browser non serve a nulla. Slack, Discord e tutto ciò che gira su quel runtime, sul desktop come sui runner CI, ha bisogno di un aggiornamento proprio.

Gli strumenti di sviluppo di Apple erano un caso particolare: git, curl e python3 forniti con macOS si fidavano ancora dei certificati compromessi al 28 ottobre, e macOS 27.2 ha annullato le correzioni che alcuni avevano applicato a mano. Su un Mac, prova gli strumenti direttamente con i comandi curl qui sopra invece di fidarti della versione del sistema.

5. Guardare i runner che la tua CI usa davvero

Un runner ospitato, un agente self-hosted o un container di build è qui un bersaglio per la catena di fornitura. Se un attaccante può spacciarsi per il registro dei pacchetti, ciò che quel runner costruisce è alla sua mercé. Controlla che l’immagine del runner sia aggiornata e che l’immagine base fissata al passo 3 sia stata rinfrescata. GitLab Runner 19.5.1 è la versione corretta, se è il tuo runner.

Cosa non viene toccato

Questo argomento era di tendenza per via della multi-perspective validation di Let’s Encrypt, in cui il controllo di un dominio viene verificato da più punti di rete, in modo che un dirottamento BGP su un percorso non possa ingannare la CA e farle emettere per un dominio per cui non dovrebbe. È una difesa reale, e sta al livello dell’emissione: protegge il momento in cui un certificato viene richiesto.

Il problema eMudhra sta al livello della fiducia. Le chiavi di una CA sono state compromesse, il che non ha nulla a che fare con il modo in cui i domini sono stati validati, quindi la multi-perspective validation non l’avrebbe intercettato. I due piani si confondono facilmente. «Let’s Encrypt valida da più posti» non è un motivo per saltare l’audit qui sopra.

Per il tuo stack ACME si riduce a tre cose. I tuoi certificati non sono toccati e i rinnovi continuano. I tuoi client sono il rischio, e solo l’aggiornamento del trust store lo risolve. E Caddy o Traefik che terminano il TLS con il tuo certificato vanno benissimo, mentre git, curl, docker e i runtime sullo stesso server sono la superficie d’attacco.

Dove eseguire l’audit

Lo stack che controlli è molto probabilmente un piccolo VPS o un host di container, e i passi qui sopra presuppongono una shell su di esso. Se stai ancora scegliendo la macchina, la fascia economica l’abbiamo testata e descritta nel confronto dei VPS. La configurazione ACME che serve questo sito, Caddy e Docker dietro un unico hostname, è nella guida a Caddy in produzione. Il caso della macchina datata, dove certbot non si installa e riprendi il rinnovo con acme.sh, è quello che la maggior parte degli utenti di self-hosting eredita prima o poi.