Per qualche giorno, a fine settembre 2026, è stato possibile ottenere un certificato HTTPS perfettamente valido per google.com e youtube.com senza mai aver violato un solo server di Google. Bastava impossessarsi del registro sbagliato: quello di un piccolo ccTLD nazionale. È la dimostrazione plastica di un rischio che gli esperti di PKI denunciano da anni, ma che raramente si materializza con un bersaglio così visibile: la sicurezza del web non dipende solo da quanto è solida la tua infrastruttura, ma anche da quella del più debole dei domini che condividono la stessa catena di fiducia DNS.

Tre registri nazionali, un’unica tecnica

Il 6 ottobre 2026 il Chrome Secure Web and Networking Team ha pubblicato un resoconto in cui conferma di aver rilevato, nella settimana precedente, il compromesso di tre registri di domini di primo livello nazionali: .gh (Ghana), .sl (Sierra Leone) e .as (Samoa Americane). Google è stata chiara su un punto: “gli aggressori hanno compromesso i ccTLD di terze parti”, non l’infrastruttura di Google. Il problema è che un ccTLD compromesso espone chiunque possieda un dominio sotto quel suffisso, inclusi marchi globali che di quei territori non hanno nulla a che fare se non una registrazione difensiva o regionale.

Il meccanismo è concettualmente semplice e per questo pericoloso. Chi controlla i record DNS autoritativi di un dominio può superare qualsiasi procedura di domain control validation (DCV): le autorità di certificazione, per verificare che il richiedente sia il legittimo proprietario, chiedono tipicamente di pubblicare un record TXT con un valore casuale, oppure verificano la risposta su un percorso HTTP del dominio. Chi ha già in mano il DNS supera questi controlli senza sforzo, perché è lui stesso a decidere cosa rispondere. Una volta superata la DCV, la richiesta di un certificato di dominio validato (DV) a una CA pubblica è una formalità automatizzata, ed è esattamente qui che il sistema, pur funzionando esattamente come progettato, produce un risultato disastroso.

Cosa raccontano i log di Certificate Transparency

A ricostruire la cronologia sono stati i log pubblici di Certificate Transparency (CT), obbligatori per ogni certificato pubblico dal 2018 e proprio per questo diventati lo strumento principale di rilevamento di abusi come questo. The Hacker News, incrociando i dati con servizi come ctlogs.dev e Cert Spotter, ha trovato che fino al 10 settembre le uniche emissioni legittime per i domini coinvolti erano quelle di Google Trust Services. Poi la sequenza si è rotta: il 22 settembre compaiono i primi certificati fraudolenti per il ccTLD .gh, il 25 settembre per .sl, il 27 settembre per .as. In tutto sono stati individuati 12 certificati per 7 nomi di dominio diversi, tutti di tipo DV: due per google.com.gh e youtube.com.gh, sei per il ccTLD .sl (google.sl, google.com.sl, youtube.sl) e quattro per .as (google.as, youtube.as). Undici sono stati emessi da Let’s Encrypt, uno da ZeroSSL.

Matthew McPherrin, rappresentante di Let’s Encrypt, ha confermato pubblicamente sul forum della CA: “sì, sono stati emessi certificati per Google e YouTube, e sono stati revocati”. Google, da parte sua, non attribuisce colpe alle autorità di certificazione coinvolte: nessuna delle due ha sbagliato alcunché, hanno semplicemente verificato un controllo DNS che, in quel momento, era davvero nelle mani sbagliate. I due certificati .gh e quello ZeroSSL sono stati revocati già il 26 settembre; i rimanenti nove certificati Let’s Encrypt sono stati revocati il 1° ottobre, quindi con un certo ritardo rispetto alla prima emissione fraudolenta.

Perché un certificato “vero” è più pericoloso di uno falso

Un certificato emesso legittimamente da una CA pubblica, anche se ottenuto con l’inganno, non genera alcun avviso nel browser: il lucchetto resta verde, la connessione risulta cifrata. Combinando il controllo del DNS con un certificato HTTPS valido per lo stesso dominio, un attaccante può costruire una pagina di phishing indistinguibile dall’originale o posizionarsi come man-in-the-middle su traffico che l’utente crede protetto end-to-end. Google ammette i limiti della propria visibilità: “non possiamo garantire che la nostra analisi abbia individuato tutti i domini coinvolti”, e conferma che sono stati compromessi certificati anche per “diversi marchi globali di primo piano e servizi online molto diffusi”, senza nominarli.

La risposta: CRLSet, revoche e un limite dichiarato

La prima mitigazione è arrivata lato Chrome: Google ha bloccato l’utilizzo dei certificati fraudolenti per i propri domini tramite CRLSets, il meccanismo di revoca distribuito via aggiornamenti del browser che non richiede di contattare in tempo reale l’infrastruttura OCSP delle CA. In parallelo ha ottenuto dalle CA emittenti la revoca formale, estendendo la protezione anche a chi non usa Chrome. L’analisi dei log CT ha poi fatto emergere altre organizzazioni colpite, per cui Chrome ha aggiunto proattivamente ulteriori certificati alla blocklist, avvisando dove possibile i diretti interessati.

Ma lo stesso post di Google contiene un avvertimento che vale la pena leggere per intero, perché ribalta la narrazione rassicurante del “gli utenti Chrome non devono fare nulla”: “l’intervento lato browser non dovrebbe essere la misura su cui fare affidamento per proteggere i propri utenti”. In altre parole, chi possiede domini non può delegare la propria sicurezza TLS al fatto che Google se ne accorga e blocchi i certificati incriminati: la finestra di esposizione, prima che qualcuno individui l’abuso nei log CT, resta comunque aperta.

Cosa possono fare davvero i proprietari di domini

• Monitorare in modo continuativo i log di Certificate Transparency per l’intero portafoglio di domini posseduti, inclusi quelli parcheggiati, regionali o acquisiti a scopo puramente difensivo: sono proprio i domini meno sorvegliati quelli più comodi da sfruttare.
• Pubblicare record CAA (RFC 8659) che limitino esplicitamente quali CA possono emettere per il proprio dominio, vincolandoli dove possibile al proprio account tramite CAA Account URI binding (RFC 8657): questo impedisce che un attaccante, dopo aver perso il controllo del DNS, riutilizzi una validazione già in cache per emettere nuovi certificati. Il CAA non blocca l’emissione durante un hijack attivo, ma diventa decisivo subito dopo il ripristino del controllo legittimo.
• In caso di certificato non richiesto scoperto nei log CT, inviare un Certificate Problem Report alla CA emittente: i Baseline Requirements del CA/Browser Forum impongono di indagare e dare una prima risposta entro 24 ore.
• Ricordare che oggi una validazione di dominio può essere riutilizzata fino a 200 giorni (in calo a 100 da marzo 2027 e a 10 da marzo 2029): più lunga la finestra, più a lungo un hijack temporaneo del DNS può tradursi in emissioni fraudolente anche dopo la risoluzione del problema.

Resta sullo sfondo la domanda più scomoda, quella a cui né Google né le CA coinvolte hanno ancora risposto pubblicamente: come sono stati compromessi i tre registri ccTLD, chi c’è dietro e quanti altri domini, oltre ai sette individuati nei log CT, abbiano avuto certificati fraudolenti emessi a loro insaputa. Finché quella domanda resta aperta, ogni organizzazione che possiede proprietà digitali sotto un ccTLD gestito da un operatore terzo dovrebbe considerare il proprio DNS, non solo i propri server, come parte della superficie di attacco da sorvegliare.

Cronologia essenziale

10 set 2026 - Ultima data nei log CT con sole emissioni legittime (Google Trust Services)
22 set 2026 - Primi certificati fraudolenti per il ccTLD .gh (Ghana)
25 set 2026 - Primi certificati fraudolenti per il ccTLD .sl (Sierra Leone)
26 set 2026 - Revocati i 2 certificati .gh e il certificato ZeroSSL
27 set 2026 - Primi certificati fraudolenti per il ccTLD .as (Samoa Americane)
1 ott 2026  - Revocati i restanti 9 certificati Let's Encrypt
6 ott 2026  - Google pubblica "Chrome's response to recent ccTLD registry hijacks"
7 ott 2026  - The Hacker News verifica indipendentemente i certificati via ctlogs.dev e Cert Spotter

Domini coinvolti (certificati DV, poi tutti revocati):
  google.com.gh, youtube.com.gh
  google.sl, google.com.sl, youtube.sl
  google.as, youtube.as

CA emittenti: Let's Encrypt (11 certificati), ZeroSSL (1 certificato)

Fonti: Google (blog.google/security/chromes-response-to-recent-cctld-registry-hijacks), The Hacker News, BleepingComputer, Infosecurity Magazine.