La chiave era 4: chi decide di quali siti web si fida il software che usiamo

Questo articolo è stato tradotto automaticamente. La versione originale è disponibile in inglese.

Ultimo aggiornamento: 25 ottobre 2026 · 21 min di lettura

Qui abbiamo un problema

Sabato 17 ottobre 2026, alle 18:05 UTC, il programma dei certificati radice di Chrome (Chrome Root Program) ha ricevuto la segnalazione di un ricercatore di sicurezza identificato pubblicamente solo come Wayne. Sosteneva di possedere le chiavi private di otto autorità di certificazione gestite da eMudhra, una società quotata con sede a Bangalore, in India. Per dimostrarlo, aveva usato ciascuna delle otto chiavi per firmare lo stesso breve messaggio: «Qui abbiamo un problema – Wayne».

Non aveva avuto bisogno di forzare nulla. Quando la notizia è diventata pubblica, il ricercatore di sicurezza Scott Helme ha descritto l’aspetto di quelle chiavi. Una era semplicemente il numero 4. Altre due erano 56 e 115. Helme ha detto di averle ricavate tutte dai rispettivi certificati pubblici, sul suo portatile, e che gli era bastato meno di un secondo. Una verifica indipendente condotta da giornalisti ha confermato che la chiave privata dietro «EM OV TLS CA – G3C» di eMudhra era 4.

Le otto erano autorità di certificazione intermedie, lo strato operativo di una società di certificati, quello che firma le credenziali di altri. Sei erano autorizzate a emettere certificati per siti web, e quelle sei erano considerate attendibili dai programmi dei certificati radice di Chrome, Mozilla, Microsoft e Apple. Le altre due servivano alla firma del codice, i certificati con cui i produttori di software firmano i propri programmi, ed erano considerate attendibili da Microsoft. Le loro chiavi erano state generate in modo scorretto, quindi chiunque sapesse dove guardare poteva calcolarle a partire dai certificati stessi, che per loro natura sono pubblici. Era possibile farlo da quando i certificati erano stati creati, nell’aprile 2025.

Alle 19:45 UTC, un’ora e quaranta minuti dopo l’arrivo della segnalazione, Chrome aveva confermato le scoperte e inviato un blocco ai suoi utenti. Nessuno ha dovuto installare un aggiornamento o riavviare il browser.

La rapidità contava per via di ciò che una chiave del genere permette di fare. Chi avesse in mano una qualsiasi delle sei chiavi per siti web e fosse in grado di intercettare la connessione di una persona poteva presentare un certificato falso per una banca, un servizio di posta elettronica o qualunque altro sito, a prescindere dalla società di certificati usata dal sito vero, e il software che si fidava della catena di eMudhra lo avrebbe accettato. A sbarrare la strada c’erano due protezioni principali: un sistema pubblico di registrazione chiamato Certificate Transparency, che alcuni programmi esigono e molti altri no, e i blocchi che ciascun programma riusciva a ricevere in tempo.

Che un certificato falso funzionasse o no dipendeva da decisioni di norma invisibili: chi garantisce per un sito web, chi decide che a quel garante si debba credere, e con quale rapidità quella fiducia può essere ritirata quando il garante si rivela difettoso.

Che cosa garantisce un certificato

Un certificato per siti web è un piccolo documento firmato che lega un nome, come l’indirizzo web di una banca, a una chiave pubblica. Le chiavi pubbliche vanno in coppia con chiavi private. La chiave privata resta segreta e produce firme digitali; quella pubblica permette a chiunque di verificare che una firma provenga dalla sua compagna. Quando il browser si connette a un sito, il sito dimostra di possedere la chiave privata che corrisponde alla chiave pubblica contenuta nel suo certificato. Il certificato, a sua volta, afferma che quella chiave pubblica appartiene a quel nome, e un’autorità di certificazione, o CA, si fa garante dell’affermazione firmandola.

Prima di firmare un certificato per un sito web, la CA deve verificare che il richiedente controlli il dominio. Uno dei metodi approvati consiste nel fornire al richiedente un valore casuale e poi cercarlo nei record DNS del dominio, la rubrica pubblica di internet, dove solo chi controlla il dominio potrebbe averlo inserito. La CA può anche accertare che il richiedente possieda davvero la chiave privata che vuole far certificare, con un test tecnico chiamato prova di possesso, anche se lo standard di riferimento le consente pure di fidarsi della parola del richiedente.

Nessun browser potrebbe controllare da sé ogni CA del mondo, perciò la fiducia viene delegata lungo una catena. In cima stanno i certificati radice, conservati in un elenco chiamato archivio dei certificati attendibili, che viene distribuito con il sistema operativo o con il browser. Le radici autorizzano le CA intermedie, e le intermedie emettono i certificati usati dai siti web. Quando il software riceve il certificato di un sito, segue le firme verso l’alto, dal sito a un’intermedia e da questa a una radice, e accetta il sito solo se la catena termina in una radice presente nel suo archivio, ogni firma risulta valida, il certificato è in corso di validità e copre il nome visitato, e nessun’altra regola del software lo vieta.

I programmi dei certificati radice, gestiti dai produttori di sistemi operativi e di browser come Apple, Google, Microsoft e Mozilla, valutano le autorità di certificazione e decidono quali radici entrano nell’archivio. Ecco perché la chiave privata di un’intermedia vale così tanto. A meno che non sia stata limitata a determinati nomi, e quelle di eMudhra non lo erano, un’intermedia può firmare un certificato per qualsiasi dominio, e quel certificato risulta valido risalendo fino a una radice attendibile. La chiave della radice può restare custodita al sicuro; è quella dell’intermedia a firmare ogni giorno, e se trapela, con lei trapela anche l’avallo della radice.

Nulla di tutto questo dice se un sito web sia onesto, anche se il lucchetto del browser viene comunemente inteso così. Quando Google ha studiato la questione, nel 2021, solo l’11% dei partecipanti aveva capito correttamente che cosa significasse il lucchetto, e quasi tutti i siti di phishing usavano HTTPS e quindi lo mostravano anch’essi. Nel 2023 Google ha annunciato che Chrome avrebbe sostituito il lucchetto con un’icona diversa. Un certificato di base dice soltanto che la connessione arriva a chi detiene la chiave per quel nome. Alcuni certificati indicano anche l’organizzazione che sta dietro il sito; nessuno garantisce per le sue intenzioni.

C’è poi un altro livello. La Certificate Transparency, definita da ingegneri di Google nel 2013, inserisce i certificati in registri pubblici dove chiunque può verificare che cosa abbia emesso ciascuna CA. Nelle intenzioni dei suoi ideatori, prima o poi i client avrebbero rifiutato qualsiasi certificato non registrato, così che un certificato tenuto fuori dai registri, che lo avesse emesso una CA o un ladro in possesso della chiave di una CA, venisse respinto. Chrome lo fa in modo predefinito per ogni connessione che si appoggia al suo archivio di certificati radice.

L’avvertimento rimasto senza risposta

Le regole per creare le chiavi delle CA sono severe. Per le radici e per alcune chiavi intermedie, i Baseline Requirements del settore, il regolamento che i programmi dei certificati radice dei browser e le CA mantengono insieme, stabiliscono che la CA debba seguire uno script di generazione delle chiavi messo per iscritto e far assistere alla cerimonia un revisore qualificato, oppure registrarla interamente in video. Qualsiasi chiave di una CA deve essere generata da più persone insieme, nessuna delle quali possiede da sola tutte le conoscenze necessarie per farlo.

Il 30 aprile 2025 eMudhra ha creato un lotto di 24 intermedie. Erano divise in tre serie, contrassegnate con A, B e C, con due tipi di chiave, RSA e il tipo a curva ellittica chiamato P-384, e quattro scopi d’uso. Le otto chiavi compromesse erano tutte le chiavi P-384 delle serie B e C. Tutte e otto erano numeri interi inferiori a 256. Scritta per intero, ciascuna era una lunga fila di zeri con qualcosa nell’ultimo byte.

Perché questa chiave si poteva indovinare

Una chiave privata sulla curva P-384 è semplicemente un numero, scelto a caso tra 1 e un limite fisso che è a sua volta lungo 384 bit. La chiave pubblica si ricava dalla chiave privata con un calcolo facile da eseguire in avanti e, per un numero davvero casuale, impossibile da ripercorrere a ritroso. È stampata nel certificato. Il numero 4 è una chiave privata perfettamente lecita; è anche uno dei primi numeri che chiunque proverebbe. Mozilla ha fatto notare che chiavi così piccole si recuperano quasi all'istante: si calcolano le chiavi pubbliche per 1, 2, 3 e così via fino a 256, e si confronta ciascuna con quella del certificato. Quando due coincidono, la chiave privata è il numero da cui si è partiti. Una chiave davvero casuale non offre nessuna lista breve del genere. Come ha detto Scott Helme, l'intervallo contiene all'incirca 10 elevato alla 115 possibilità, «quindi nessuno andrà mai a cercare lì dentro». Dennis Jackson di Mozilla ha anche affidato il compito ad agenti di IA eseguiti in locale. Hanno recuperato la chiave al primo tentativo, partendo da un prompt semplice.

Come ha potuto una cerimonia delle chiavi produrre numeri così piccoli? La spiegazione preliminare di eMudhra, pubblicata il 19 ottobre, è che lo script usato quel giorno avesse un difetto. La società afferma di aver approvato una modifica una tantum alla procedura abituale per provare l’esportazione delle chiavi, che un errore di programmazione ha fatto creare all’hardware una seconda coppia di chiavi, più debole, accanto a quelle corrette, e che le chiavi deboli sono state poi usate per errore per richiedere i certificati perché le loro etichette si somigliavano. Afferma che le chiavi sono state generate in moduli di sicurezza hardware prodotti da Utimaco, i dispositivi resistenti alla manomissione destinati a generare e custodire le chiavi delle CA.

eMudhra definisce preliminare questa ricostruzione, che lascia aperto il nodo centrale. Un commentatore della segnalazione pubblica di Mozilla ha osservato che o le chiavi erano state create fuori dall’hardware sicuro e poi caricate al suo interno, contro le regole, oppure l’hardware poteva in qualche modo essere configurato per generare da sé chiavi difettose. Un altro partecipante, sulla mailing list pubblica di Mozilla, ha ipotizzato, senza conferme, che un software avesse scambiato per la chiave stessa un piccolo file che rimandava alla vera chiave custodita nell’hardware. Mozilla, pur con sforzi molto maggiori, non è riuscita a recuperare le chiavi P-384 della serie A dello stesso lotto. Il 20 ottobre ha inviato a eMudhra alcune domande con una scadenza di 24 ore; al 23 ottobre non aveva ricevuto risposta, e nessuno aveva spiegato come fossero nate le chiavi deboli.

Quello che è documentato è che il problema si era manifestato più di un anno prima. Nel giugno 2025 un servizio pubblico di monitoraggio aveva mostrato che eMudhra distribuiva sei liste di revoca dei certificati con firme non valide per queste stesse intermedie. Una lista di revoca, o CRL, è un registro firmato dei certificati che una CA ha annullato, e la sua firma deve risultare valida con la chiave pubblica contenuta nel certificato della CA. Il rapporto di eMudhra dell’epoca diceva che Sectigo, un’altra società di certificati, l’aveva avvisata per la prima volta via email il 3 giugno 2025, e che il messaggio era stato messo in quarantena dai filtri interni e non era stato visto. Le liste difettose erano state sostituite il 6 giugno.

Nell’ottobre 2026 eMudhra ha spiegato in che cosa fosse consistita quella correzione. Le liste erano state firmate inizialmente con le chiavi originali, generate in modo correttamente casuale; poiché i certificati contenevano le metà pubbliche delle chiavi deboli, quelle firme non risultavano valide, e la società aveva rifirmato le liste con le chiavi difettose. Nel giugno 2025, dunque, eMudhra aveva la prova che i suoi certificati non corrispondevano alle chiavi che credeva di usare, e aveva corretto le liste.

Il Chrome Root Program ha chiesto perché eMudhra si fosse limitata a rifirmare le liste invece di sospendere le operazioni, indagare sul perché esistessero due coppie di chiavi per queste CA e revocare i certificati. eMudhra afferma che le sue radici e le sue CA emittenti sono state sottoposte ad audit indipendenti per due anni consecutivi. Il 14 ottobre 2026, tre giorni prima della segnalazione di Wayne, ha pubblicato una lista di revoca per un’altra radice, emSign Root TLS CA – G1, la cui firma a sua volta non risultava valida.

Due tipi di interruttore

La prima mossa di Chrome è stata rapida perché aveva per bersaglio le chiavi. Chrome mantiene una lista di blocco chiamata CRLSet, che Google invia ai browser in background. L’aggiornamento distribuito alle 19:45 UTC bloccava le impronte digitali delle chiavi pubbliche delle sei intermedie. Poiché il blocco indicava le chiavi, copriva ogni certificato che usasse quelle chiavi, compresi quelli che un falsario avrebbe potuto creare in seguito. Mozilla ha bloccato i certificati in Firefox con la propria lista, OneCRL, e ha concluso alle 22:59 UTC. OneCRL funziona senza che gli utenti debbano aggiornare o anche solo riavviare Firefox.

Una lista inviata in background protegge solo il software che la riceve. Il 20 ottobre Mozilla ha rilasciato un aggiornamento di Firefox per gli utenti le cui configurazioni avevano impedito l’arrivo della lista di blocco, e in seguito una correzione per alcuni profili di Firefox per Android che non la applicavano. Google ha cominciato a inviare un blocco equivalente ai dispositivi Android attraverso Google Play Services intorno alle 22:00 UTC di lunedì 19 ottobre, e il giorno dopo ha detto che la maggior parte lo aveva ricevuto. Microsoft e Apple hanno seguito nel giro di pochi giorni, anche se le ricostruzioni pubblicate non concordano sulla data esatta dell’intervento di Apple.

Si sono mosse anche le autorità di certificazione. eMudhra ha contrassegnato come revocati tutti e otto i certificati entro le 09:38 UTC del 18 ottobre, indicando come motivo la compromissione della CA. Sectigo, che aveva certificato le intermedie con una firma incrociata, ha finito di revocare i propri certificati incrociati il 19 ottobre. Chrome ha anche fatto in modo che i registri della Certificate Transparency rifiutassero qualsiasi certificato con una catena che portasse alle CA compromesse, così che un certificato falso non potesse più ottenere le registrazioni che il software con controllo CT esige.

Lo strumento più pesante consiste nel rimuovere la radice che aveva autorizzato le intermedie. Il 20 ottobre, rilevando che a quel punto diverse persone avevano recuperato le chiavi in modo indipendente, Mozilla ha deciso la rimozione d’emergenza dal proprio archivio dei certificati attendibili di emSign ECC Root CA – G3, la radice di eMudhra sopra le intermedie compromesse. Firefox non ne aveva bisogno; OneCRL copriva già Firefox. Serviva a tutti gli altri che usano l’elenco di radici di Mozilla, o uno da esso derivato, senza OneCRL. Mozilla ha avvertito che la modifica avrebbe reso alcuni server irraggiungibili per quegli utenti finché i server non fossero passati a nuove catene di certificati.

Chrome ha rimosso la stessa radice dal proprio archivio. Google prevedeva che la modifica raggiungesse tutti i dispositivi che si affidano al Chrome Root Store la mattina di martedì 27 ottobre 2026, ora del Pacifico, e prima ancora sulle versioni di prova Canary e Beta. Google ha detto chiaramente che, di conseguenza, alcuni certificati legittimi collegati a quella radice avrebbero smesso di funzionare in Chrome.

I due interruttori differiscono in ciò che intercettano e in chi danneggiano. Rimuovere una radice interrompe ogni percorso che passa da quella radice, compresi quelli dei siti onesti, ma lascia scoperti i percorsi che passano da altre radici, e le intermedie di eMudhra ne avevano un altro. Sectigo le aveva certificate con firma incrociata, collegando le stesse chiavi a una radice chiamata AAA Certificate Services, emessa con il marchio Comodo. Chrome aveva eliminato quella radice nell’aprile 2025, ma alcuni sistemi la consideravano ancora attendibile: Ubuntu ha rimosso emSign ECC Root CA – G3 da tutte le sue versioni supportate e, dalle versioni più vecchie che ancora la includevano, anche la radice Comodo. Un blocco legato all’intermedia stessa intercetta tutte le strade in una volta. È l’approccio scelto dal linguaggio di programmazione Go: dalle versioni rilasciate il 19 ottobre, il verificatore di certificati di Go scarta qualsiasi catena che contenga una delle intermedie compromesse, quale che sia la radice in cui termina.

L’aggiornamento di tutti gli altri

Il 18 ottobre Mozilla ha scritto nella sua segnalazione pubblica di essere preoccupata per l’ecosistema più ampio, perché molti endpoint non hanno un modo efficace per ricevere le informazioni sulle revoche. I browser avevano le loro liste in background. Molto altro software che stabilisce connessioni sicure non ha nulla del genere.

Il sito di monitoraggio dell’incidente, una pagina pubblica creata da Dennis Jackson di Mozilla, ha spiegato nel dettaglio chi era esposto. Le applicazioni e le librerie che includono un proprio pacchetto di radici attendibili avevano bisogno di aggiornamenti software. Lo stesso valeva per le app basate su Electron, il framework su cui poggiano programmi desktop come Slack e Discord, che ricevono la correzione di Electron solo quando vengono ricompilate su una versione aggiornata.

Alcune falle stavano nei file di fiducia degli stessi sistemi operativi. Al 22 ottobre, il sito dell’incidente indicava che macOS bloccava le intermedie compromesse, ma che i suoi strumenti integrati da riga di comando, tra cui curl, git e python3, verificavano i certificati con un file separato senza consultare le revoche, e quel file non era stato aggiornato. Su Ubuntu, l’archivio dei certificati attendibili di Java richiedeva un intervento manuale dopo l’aggiornamento di sistema, a causa di un problema di sincronizzazione che Canonical al 22 ottobre non aveva risolto, e i browser installati come pacchetti snap non usavano affatto l’archivio di sistema.

Altre falle stavano nelle librerie che portano con sé i propri elenchi. Go ha distribuito la correzione con le versioni di sicurezza 1.27.3 e 1.26.10, con il codice CVE-2026-111943. Il pacchetto certifi di Python, molto diffuso, ha rimosso tutte e quattro le radici emSign il 18 ottobre, poi ha ripristinato le tre non coinvolte in una versione etichettata 2026.10.19; un rilascio automatico del 23 ottobre ne ha tolte di nuovo due su tre. E alcuni prodotti potevano essere corretti solo da chi li produce: il team di sicurezza Talos di Cisco ha indicato le reti private virtuali tra i prodotti che probabilmente avrebbero avuto bisogno di aggiornamenti.

Sotto tutto questo c’era la Certificate Transparency. La maggior parte dei browser la applica, ma molti client che non sono browser, tra cui curl, no. Un certificato falso creato con una delle chiavi di eMudhra e mai registrato sarebbe stato respinto da Chrome, ma avrebbe potuto essere accettato da quei client, purché si fidassero ancora della catena di eMudhra e nient’altro lo fermasse, per esempio un’app che accetta solo i certificati noti dei propri server.

Ci sono solide ragioni per sostenere che il sistema abbia funzionato. Nessun certificato per siti web collegato alle sei intermedie era stato registrato nella Certificate Transparency prima del blocco di Chrome del 17 ottobre, quindi tra la creazione delle chiavi, nell’aprile 2025, e quel blocco nessun certificato falso ottenuto con esse avrebbe potuto essere usato contro i client che applicano la CT. Talos ha dichiarato di non aver osservato alcun uso malevolo in circolazione alle 14:00 UTC del 21 ottobre. eMudhra afferma che solo una delle intermedie coinvolte era mai stata messa in produzione, e che nessuna aveva mai emesso un certificato a un sito web o a un produttore di software.

Per il software che ha applicato la CT per tutto il tempo, l’argomento regge, e la protezione è venuta da una regola permanente, non dall’emergenza del fine settimana. La sua portata è più ristretta di quanto suggerisca la frase «il sistema ha funzionato». Firefox per Android ha cominciato ad applicare la Certificate Transparency solo con la versione 145, offerta per la prima volta agli utenti l’11 novembre 2025. Le app Android possono usare i controlli CT integrati solo da Android 16, e li ottengono in modo predefinito solo se compilate per Android 17.

L’emergenza ha contato anche per ciò che è venuto dopo. La prima comunicazione di Mozilla ai gestori a valle degli archivi di certificati attendibili evitava deliberatamente di dire che le chiavi potevano essere recuperate da chiunque. Al 20 ottobre questo importava ormai poco: diverse persone le avevano recuperate in modo indipendente, e Helme aveva pubblicato tutti e otto i valori. Una volta che le chiavi erano di fatto pubbliche, a separarle da qualsiasi nuova falsificazione c’erano i blocchi e i rifiuti dei registri CT. Al 24 ottobre nulla di quanto pubblicato mostrava se, tra l’aprile 2025 e l’ottobre 2026, qualche aggressore avesse usato le chiavi difettose contro client che non applicano la CT.

Chi controlla l’interruttore

Le decisioni su quali radici debbano considerare attendibili browser e sistemi operativi spettano ai programmi dei certificati radice, e le regole di questi programmi lasciano ai loro proprietari ampi margini. La policy di Chrome dice che Google include o rimuove i certificati «a sua esclusiva discrezione», e che ogni certificato incluso deve offrire agli utenti un valore superiore al rischio di mantenerlo. La policy di Mozilla dice che Mozilla può disattivare o rimuovere un certificato a sua esclusiva discrezione, in qualsiasi momento e per qualsiasi motivo. Mozilla dice anche di non chiedere alcun compenso per l’inclusione.

Quella discrezionalità è stata usata in modi diversi. Nel 2014, dopo che il National Informatics Centre indiano aveva emesso certificati non autorizzati per diversi domini di Google, Chrome non ha eliminato la radice India CCA che gli stava sopra. L’ha limitata a un elenco di domini indiani. Tre anni prima la risposta a un’autorità olandese era stata totale: il 3 settembre 2011 Google aveva deciso di rifiutare tutte le autorità di certificazione gestite da DigiNotar, e diciassette giorni dopo un tribunale olandese aveva dichiarato il fallimento della società.

DigiNotar, 2011

La violazione di DigiNotar è venuta alla luce grazie a un utente qualunque. Il 28 agosto 2011 un cliente di ParsOnline, un provider internet iraniano, ha scritto in un forum di assistenza di Google a proposito di un avviso sul certificato che Chrome gli aveva mostrato. Il certificato si presentava come di Google, e proveniva da DigiNotar, i cui sistemi erano stati violati. Gli investigatori della società di sicurezza Fox-IT, incaricati dal governo olandese, hanno poi scoperto che un certificato fraudolento valido per gli indirizzi google.com era stato usato in un vasto attacco contro circa 300.000 utenti, quasi tutti in Iran, il cui traffico verso Google era stato probabilmente intercettato o dirottato. Avevano ricavato la stima da 298.140 indirizzi internet distinti che avevano verificato lo stato del certificato falso, e l'avevano definita un'approssimazione molto grossolana. Il 3 settembre il governo olandese ha revocato pubblicamente la propria fiducia in DigiNotar. A fine ottobre 2026 non era stato segnalato alcun attacco con le chiavi di eMudhra. DigiNotar ha mostrato che cosa fa il potere di firma di una CA nelle mani di qualcuno disposto a usarlo.

L’inclusione nell’archivio dei certificati radice di Chrome, ha scritto Google, richiede che il titolare di una CA dimostri in modo continuativo la competenza tecnica e il rigore operativo necessari per proteggere gli utenti di Chrome, e Google ha detto di stare «indagando attentamente» se i restanti certificati CA di eMudhra debbano restarvi. Il 23 ottobre eMudhra ha scritto nella segnalazione pubblica che l’intensa attenzione sui social media e le analisi di investitori e clienti avevano reso un’analisi significativa dell’evento «praticamente impossibile». Chrome ha risposto lo stesso giorno che non era una giustificazione, e che eMudhra aveva ancora degli obblighi verso i «miliardi» di persone che si affidano al sistema e che il suo errore aveva esposto.

Il consiglio di amministrazione di eMudhra aveva già deciso, il 22 ottobre, di ritirarsi dal mercato globale dei certificati SSL/TLS. La società afferma che quell’attività rappresenta una parte molto piccola delle sue operazioni.

Le stesse aziende scrivono anche regole comuni con le CA in un organismo chiamato CA/Browser Forum. In una votazione chiusa l’11 aprile 2025, diciannove giorni prima che eMudhra generasse le chiavi difettose, Apple, Google, Microsoft e Mozilla hanno votato tutte per accorciare la vita dei certificati per siti web, e anche 25 emittenti di certificati, tra cui eMudhra, hanno votato a favore. La tesi della proposta era che la revoca non protegge adeguatamente le persone alla scala di internet, mentre la scadenza sì. «I periodi di validità dei certificati, e la loro applicazione da parte di chi vi fa affidamento, sono incredibilmente affidabili», si leggeva nel testo. In base alle regole in vigore nell’ottobre 2026, i certificati per siti web emessi dal 15 marzo 2026 possono durare al massimo 200 giorni; dal 15 marzo 2027, 100 giorni; e dal 15 marzo 2029, 47 giorni.

Questi limiti si applicano ai certificati usati dai siti web, in base alla data di emissione. Il testo della regola non pone limiti ai certificati delle CA che stanno al centro di questo incidente, quindi durate più brevi non avrebbero fatto scadere le intermedie di eMudhra. Né la revoca è scomparsa. Let’s Encrypt, l’autorità di certificazione gratuita, ha chiuso nell’agosto 2025 il suo servizio OCSP, che permetteva ai browser di chiedere informazioni su un certificato alla volta, perché ogni richiesta rivelava alla CA quale sito veniva visitato e da quale indirizzo internet. I blocchi d’emergenza del 17 ottobre erano, di fatto, liste di revoca che i produttori di browser hanno curato e distribuito da sé.

Questo assetto concentra molto potere in poche mani private, per lo più americane. Ciò che il caso eMudhra mostra è il modo in cui quel potere viene esercitato: in una segnalazione aperta, dove chiunque può leggere le domande, le scadenze e le risposte, con le motivazioni pubblicate dalle stesse aziende che effettuano la rimozione.

I certificati che devono traslocare

Rimuovere una radice è rapido da annunciare e lento da assorbire. Al 21 ottobre Chrome contava circa 30.800 precertificati non scaduti collegati a emSign ECC Root CA – G3. Un precertificato è la copia di un certificato inviata ai registri di trasparenza prima dell’emissione, quindi il dato conta i certificati registrati, non i siti web che li usano ancora. Di questi, 30.791, ovvero il 99,9%, provenivano da due intermedie appartenenti a InCommon, un servizio di certificati gestito da Internet2, un’organizzazione statunitense di reti. Quelle due non erano tra le otto intermedie compromesse; erano semplicemente appese alla radice in via di rimozione. eMudhra ha stimato che circa 30.000 certificati dovessero essere trasferiti, quasi tutti emessi tramite ACME, il protocollo che permette ai server di richiedere e rinnovare i certificati in automatico. eMudhra ha smesso di emettere sotto la radice G3 il 20 ottobre.

L’automazione, da sola, non risolve il problema. I client ACME standard sostituiscono un certificato solo quando arriva la sua data di rinnovo, a meno che non supportino un’estensione più recente che permette alla CA di chiedere un rinnovo anticipato o che qualcuno intervenga a mano. Il 21 ottobre Chrome ha fatto notare che passare dalla gerarchia a curva ellittica di eMudhra a quella RSA può richiedere anche di modificare le impostazioni del client.

I certificati di InCommon arrivano attraverso CertiNext, un fornitore la cui società madre è eMudhra. Il 22 ottobre InCommon ha comunicato ai titolari dei suoi certificati che molti di loro avevano passato la settimana a rispondere a errori di certificato e a fare piani in funzione di cambiamenti fuori dal loro controllo, dopo una migrazione riuscita ma estenuante tra primavera ed estate. Il suo consiglio, quella mattina, era di riemettere i certificati coinvolti come RSA finché l’emissione a curva ellittica non fosse stata ripristinata.

Il 20 ottobre eMudhra aveva detto che l’unica alternativa per i clienti di G3 erano intermedie collegate alla sua radice RSA, emSign Root CA – G1. Mozilla ha detto lo stesso giorno che per il momento non stava revocando la fiducia in G1. G1 era tra i restanti certificati di eMudhra su cui Chrome aveva detto il 20 ottobre di indagare attentamente; al 24 ottobre Chrome non aveva annunciato alcuna decisione. Il 21 ottobre Chrome aveva chiesto a eMudhra di confermare se i clienti venissero spostati su G1, sulla gerarchia di un’altra società o su entrambe.

L’aggiornamento di InCommon della sera del 22 ottobre ha risolto il problema immediato. I certificati a curva ellittica venivano di nuovo emessi, ora collegati alla radice G1, e i client esistenti potevano rinnovare senza alcuna modifica alle impostazioni. Lo stesso aggiornamento diceva che eMudhra avrebbe smesso di emettere da qualsiasi intermedia collegata alle sue radici pubbliche di lì a 30 giorni, in una data che CertiNext avrebbe confermato, e che InCommon stava lavorando a un percorso sostitutivo. Per i titolari dei certificati, che avevano concluso una faticosa migrazione in primavera e in estate, la rimozione di una sola radice ne aveva avviata un’altra.

Articoli correlati

• Fin dove arriva una lista di sanzioni americana dentro una corte dell’Aia
• Che cosa aspetta Bitcoin?
• Come funziona davvero l’IA: ciò che gli sviluppatori sanno e i titoli dei giornali no

Letture consigliate

In qualità di Affiliato Amazon, Eikleaf riceve un guadagno dagli acquisti idonei. I link ai libri qui sotto sono link di affiliazione: se acquisti tramite essi, potremmo ricevere una piccola commissione senza costi aggiuntivi per te.

• Codici & segreti: la storia affascinante dei messaggi cifrati dall’antico Egitto a internet — Simon Singh (2011). Una storia accessibile della crittografia che spiega la cifratura a chiave pubblica, la matematica dietro i certificati e le chiavi private dell’articolo.
• Security Engineering: A Guide to Building Dependable Distributed Systems (3rd ed.) — Ross Anderson (2001). Il riferimento standard su come falliscono i sistemi di sicurezza reali, con capitoli su infrastruttura a chiave pubblica, autorità di certificazione e fiducia.
• Sicurezza digitale: miti da sfatare, strategie da adottare — Bruce Schneier (2001). Uno dei principali autori di sicurezza informatica spiega, senza matematica, perché i certificati digitali e le catene di fiducia sono solidi solo quanto le organizzazioni che li sostengono.

Video consigliati

Avvertenza sull’IA generativa

Alcuni contenuti di questa pagina sono stati generati e/o modificati con l’ausilio di un’IA generativa.

Media

HTTPS e lucchetto nella barra degli indirizzi di un sito web – Wikimedia Commons (Foto: Santeri Viinamäki, CC BY-SA 4.0)

Modulo di sicurezza hardware nCipher nShield F3 – Wikimedia Commons (Foto: Alexander Klink, CC BY 3.0)

Sede del Googleplex – Wikimedia Commons (Foto: Asoundd, CC BY-SA 4.0)

Fonti principali e riferimenti

Mozilla Bugzilla. “Bug 2083449: eMudhra: Private key compromise of Intermediate Certificates.” Opened 18 October 2026, comments to 23 October 2026. https://bugzilla.mozilla.org/show_bug.cgi?id=2083449

Chrome and Android Security Teams. “Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates.” Google, The Keyword, 20 October 2026. https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/

Mozilla dev-security-policy mailing list. “Compromised eMudhra Intermediate Certificates” thread, posts by Dennis Jackson (Mozilla) and the Chrome Root Program, 20 October 2026, and by Wayne and Corey Bonnell, 21 October 2026. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE

Jackson, Dennis. “eMudhra Intermediate CA Compromise.” Incident tracking site, 20 October 2026, updated 22 October 2026. https://emudhra.we-have-a-problem.com/

InCommon (Internet2). “Moving Forward Together: InCommon Certificate Service Update.” Updates of 22 October 2026. https://incommon.org/about/news/incommon-certificate-service-update

InCommon (Internet2). “InCommon Certificate Service FAQ.” Last updated 22 October 2026, 18:30 ET. https://incommon.org/certificates

Stanescu, Luci. “eMudhra CA compromise fixes available.” Ubuntu blog, Canonical, 20 October 2026, updated 22 October 2026. https://ubuntu.com/blog/emudhra-ca-compromise-fixes-available

Canonical. “USN-8944-1: ca-certificates update” and “USN-8944-2: ca-certificates update.” Ubuntu security notices, 20 October 2026. https://ubuntu.com/security/notices/USN-8944-1 and https://ubuntu.com/security/notices/USN-8944-2

Go team. “[security] Go 1.27.3 and Go 1.26.10 are released.” golang-announce, posted 20 October 2026 (releases dated 19 October 2026). https://groups.google.com/g/golang-announce/c/66pojueaQek

Go project. “Release History.” Accessed 24 October 2026. https://go.dev/doc/devel/release

certifi. “Remove emsign (#437),” “Restore unaffected emSign roots (#439) (#440)” and “2026.10.23 (#445).” python-certifi repository, 18, 20 and 23 October 2026. https://github.com/certifi/python-certifi/commit/5cb238caeeb6c30ec1a7309ad3e16a5aa7b10ce8 and https://github.com/certifi/python-certifi/commit/662df63d7906df66f1f07c0751a3dfe9da14d914 and https://github.com/certifi/python-certifi/commit/b60466c9f2882d9cf088943c650b0faac06c080c

Cisco Talos. “Compromised eMudhra intermediate certificates.” Talos Intelligence blog, 21 October 2026. https://blog.talosintelligence.com/compromised-intermediate-certificates/

eMudhra Limited. “eMudhra Statement on distrust of select Global TLS Intermediate and one Root CA.” 21 October 2026. https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca

eMudhra Limited. “eMudhra to exit global SSL/TLS certificate business.” 22 October 2026. https://emudhra.com/en/press-release/emudhra-to-exit-global-ssl-tls-certificate-business

Abrams, Lawrence. “Mozilla, Google, Apple block compromised eMudhra CA certificates.” BleepingComputer, 20 October 2026. https://www.bleepingcomputer.com/news/security/mozilla-google-apple-block-compromised-emudhra-ca-certificates/

Helme, Scott. “Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds.” 20 October 2026. https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/

Sharwood, Simon. “Indian certification authority eMudhra’s private keys compromised – one of them was the number ‘4’.” The Register, 20 October 2026. https://www.theregister.com/a/5304312

Mozilla Bugzilla. “Bug 1970728: eMudhra: Invalid CRL signatures.” June 2025. https://bugzilla.mozilla.org/show_bug.cgi?id=1970728

Mozilla. “Firefox for Android 145.0 release notes.” 11 November 2025. https://www.firefox.com/en-US/firefox/android/145.0/releasenotes/

Cooper, D., et al. “RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.” IETF, May 2008. https://www.rfc-editor.org/rfc/rfc5280

Laurie, B., Langley, A., and Kasper, E. “RFC 6962: Certificate Transparency.” IETF, June 2013. https://www.rfc-editor.org/rfc/rfc6962

CA/Browser Forum. “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, Version 2.3.1.” 4 October 2026, sections 3.2.2.4.7, 6.1.1.1 and 6.3.2. https://github.com/cabforum/servercert/blob/3574ae809e5f909b58ee4c26b7bac4a3b9e78421/docs/BR.md

CA/Browser Forum. “Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods.” 11 April 2025. https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/

Google. “Chrome Root Program Policy, Version 1.8.” Last updated 5 February 2026. https://googlechrome.github.io/chromerootprogram/crp/policy/

Mozilla. “Mozilla Root Store Policy, Version 3.1.” Effective 1 July 2026. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

Aas, Josh. “OCSP Service Has Reached End of Life.” Let’s Encrypt, 6 August 2025. https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-end-of-life/

Adrian, David, Serena Chen, Joe DeBlasio, Emily Stark and Emanuel von Zezschwitz. “An update on the lock icon.” Chromium Blog, May 2023. https://blog.chromium.org/2023/05/an-update-on-lock-icon.html

von Zezschwitz, Emanuel, Emily Margarete Stark and Serena Chen. “‘It builds trust with the customers’ – Exploring User Perceptions of the Padlock Icon in Browser UI.” SecWeb 2022, IEEE. https://research.google/pubs/it-builds-trust-with-the-customers-exploring-user-perceptions-of-the-padlock-icon-in-browser-ui/

Android Developers. “Network security configuration: Certificate transparency.” Accessed 24 October 2026. https://developer.android.com/privacy-and-security/security-config

Langley, Adam. “Maintaining digital certificate security.” Google Online Security Blog, July 2014. https://security.googleblog.com/2014/07/maintaining-digital-certificate-security.html

Adkins, Heather. “An update on attempted man-in-the-middle attacks.” Google Online Security Blog, 29 August 2011, updated 3 September 2011. https://security.googleblog.com/2011/08/update-on-attempted-man-in-middle.html

Fox-IT. “Black Tulip: Report of the investigation into the DigiNotar Certificate Authority breach.” 13 August 2012. https://zoek.officielebekendmakingen.nl/blg-191225.pdf