eMudhra intermedio CA compromesso: guida all'impatto e alla risoluzione

Fonti controllate il 22 ottobre 2026, ora di Pechino. Apubblico: singoli utenti, operatori di siti web, sviluppatori e amministratori di sistema.

Gravi punti deboli hanno reso recuperabile un gruppo di chiavi private eMudhra/emSign intermedie CA. Ciò influisce sui client che utilizzano il sistema di certificazione pubblico per autenticare siti Web, API e software. La fiducia pubblica abbraccia i principali sistemi operativi, ma l’insieme di chiavi compromesse e il potenziale impatto sui client sono ambiti diversi. 15

Il testo principale utilizza parentesi quadre per numerare le fonti corrispondenti e tutti i collegamenti di riferimento esterni sono elencati nell’appendice. La versione elencata è la versione di base confermata per contenere la correzione di questo incidente alla data di verifica. Durante la distribuzione, viene data priorità alla versione stabile aggiornata nello stesso ramo supportato.

TL;DR

Etto chiavi private intermedie CA sono confermate compromesse. I rapporti attuali non stabiliscono che le chiavi private root o la crittografia HTTPS in generale siano state violate. Gli aggiornamenti abbracciano gran parte dell’ecosistema della fiducia pubblica; il rischio residuo dipende dall’applicazione reale.15

1. Utenti individuali: aggiorna browser, sistemi operativi e componenti di sicurezza. Su Android, aggiorna anche i servizi Google Play. Utilizzare Firefox Android 158.0.2 o successivo. 12
2. Server : aggiorna i pacchetti ca-certificates/NSS della distribuzione e controlla i trust store raggruppati con le applicazioni. Aggiornare solo l’host non è sufficiente. 7810
3. Ambienti di sviluppo: aggiorna Node 24 a 24.22.1 o una versione più recente in quel ramo, a seconda dei casi. Negli ambienti Python, aggiornare almeno a pip 26.2.2, certifi 2026.10.19 e uv 0.13.4. Ottieni i file binari Go fissi o ricostruiscili; aggiornare Java in base ai consigli del fornitore. 12–15
4. Attiva gli aggiornamenti: riavvia i servizi interessati e ricostruisci e ridistribuisci i contenitori. Per Cloudflare Tunnel, aggiorna cloudflared a 2026.10.2 o successivo. 7
5. Certificati del sito Web: sostituisce una catena interessata se contiene un CA intermedio revocato o bloccato o si basa su una radice non attendibile. La riemissione di un certificato non sostituisce l’aggiornamento degli archivi attendibilità client. 158
6. Verifica: testa il percorso TLS effettivo di ciascuna applicazione. Distinguere il rifiuto del certificato dai timeout e dagli errori DNS. Mantieni abilitata la verifica del certificato; non utilizzare -k né ignorare la verifica per eliminare gli errori. 7

1 Fatti e cause dell’incidente

fatti confermati

Mozilla e Google hanno confermato difetti in otto chiavi private intermedie eMudhra CA. Il ricercatore ha fornito la prova del controllo della chiave privata; Mozilla ha recuperato in modo indipendente le chiavi e ha riprodotto il problema. Sei CA intermedie servono TLS e due servono la firma del codice. 25

Il difetto risiede nelle chiavi generate: queste CA intermedie utilizzano la curva P-384, ma le loro chiavi private sono numeri interi inferiori a 256. Ciò è ben lungi dal selezionare in modo sicuro le chiavi in modo casuale dall’ampio intervallo previsto. Il recupero di queste chiavi deboli non dimostra che le chiavi P-384 generate correttamente possano essere danneggiate. 2

Il “certificato è stato violato” qui dovrebbe essere inteso esattamente come “la chiave privata corrispondente può essere recuperata”. Il certificato e la chiave pubblica in esso contenuta sono intrinsecamente pubblici; ciò che veramente deve essere tenuto segreto è la chiave privata in grado di generare una firma valida.

Problemi relativi al processo di generazione delle chiavi ancora in fase di studio

Una descrizione iniziale di eMudhra fa risalire il problema a una cerimonia di generazione della chiave avvenuta nell’aprile 2025. La spiegazione prevede una fase di incapsulamento e decapsulamento della chiave: oltre alla chiave forte originale, appare un altro set di chiavi deboli e le chiavi deboli vengono successivamente utilizzate per la richiesta e l’emissione del certificato. La società ha comunque affermato che l’esatta causa principale non è stata determinata in modo definitivo. 6

Pertanto, ciò che si può determinare è che queste chiavi sono gravemente deboli e sono state compromesse; l’errore non può essere ulteriormente descritto in quanto è stato dimostrato che una determinata fonte hardware di numeri casuali di HSM è difettosa, né può essere descritto come una svolta crittografica generale di RSA, ECC o TLS.

Cosa significa sfiducia nel certificato radice?

Il browser o il sistema operativo possono bloccare direttamente il certificato o la chiave pubblica dell’intermediario CA interessato oppure rimuovere il root trust che conduce ad essi. Quest’ultima misura rifiuterà anche alcuni certificati legittimi sotto la stessa radice.

Google ha pianificato la rimozione di emSign ECC Root CA - G3 per proteggere gli utenti del root store Chrome che non ricevono aggiornamenti da CRLSet. Si prevede che la rimozione del root store verrà effettuata nel periodo corrispondente dal 27 al 28 ottobre, ora di Pechino; l’ora originale di Google è la mattina del 27 ottobre, ora legale del Pacifico degli Stati Uniti. Questo piano è separato dal blocco di emergenza della chiave pubblica implementato in precedenza. 1

Diffidare di una radice è una misura di risposta; non dimostra di per sé che la chiave privata root sia stata compromessa.

2 Perché il potenziale impatto abbraccia l’ecosistema della fiducia pubblica

Chiavi compromesse e percorsi di trust interessati

Oggetto del giudizio	La portata di questo incidente
Chiave problematica identificata	8 chiavi private intermedie CA per eMudhra
Piattaforme che potrebbero richiedere un intervento	Archivio radice pubblico, browser, sistema operativo, runtime del linguaggio, pacchetto software ed ecosistema contenitore
Possibile identità impersonata TLS	Siti Web o servizi visitati da client che accettano ancora la catena di certificati contraffatti associata
Significa che tutti i dispositivi sono stati compromessi?	No; le condizioni di fiducia, la posizione della rete dell’aggressore e altre strategie di verifica determinano la sfruttabilità
Significa che tutti i certificati legali non sono validi?	No; l’invalidazione associata dipende da quali radici o catene di certificati il ​​client non ha considerato attendibili.

Red Hat limita esplicitamente lo sfruttamento alle condizioni in cui il client accetta ancora la catena in questione, l’aggressore possiede la chiave privata compromessa ed è in grado di intercettare la connessione nella rete. La copertura del rischio non deve essere confusa con il numero di attacchi avvenuti. 10

Anche i siti web che utilizzano altri CA potrebbero essere impersonificati

Supponiamo che un sito Web utilizzi effettivamente il certificato Let’s Encrypt e che il client del visitatore si fidi di più CA pubblici contemporaneamente. Un utente malintenzionato potrebbe tentare di utilizzare l’intermedio compromesso CA per creare un altro certificato per lo stesso nome di dominio. I clienti solitamente non richiedono in anticipo che il nome a dominio possa utilizzare solo Let’s Encrypt; se la catena falsa viene comunque accettata, quella effettivamente utilizzata dal sito CA, non è sufficiente per escludere tali attacchi. 8

Questo meccanismo spiega: la sostituzione di un altro certificato CA originariamente normale non ripristinerà automaticamente la fiducia del cliente nello CA compromesso. Ciò che realmente deve essere interrotto è il percorso che consente ai clienti di accettare identità false.

I tre effetti devono essere trattati separatamente

Rischio di impersonificazione dell’identità: I client che non hanno bloccato la catena pertinente possono accettare l’identità forgiata dall’aggressore, provocando l’invio di richieste sensibili a servizi falsi.

Rischio legittimo di disponibilità del servizio: la rimozione del trust root può causare errori di certificato per siti Web altrimenti legittimi, che potrebbero richiedere la migrazione a un’altra catena accettata.

Rischio di copertura della distribuzione: il sistema operativo potrebbe essere riparato mentre un truststore in bundle con l’applicazione, un ambiente virtuale, una vecchia immagine del contenitore o un programma compilato conserva il vecchio comportamento di convalida.

Questi tre ambiti non sono identici. La risposta di Cloudflare copre la convalida dell’identità remota, gli archivi di fiducia condivisi, le immagini di base e le singole applicazioni, illustrando perché le ultime due attività devono essere gestite separatamente. 7

3 CA e fornitori di certificati interessati

Fornitore e tipo di impatto

fornitore o sistema	Ruolo in questo incidente	Confini che vanno distinti
eMudhra／emSign	La chiave privata intermedia CA è direttamente compromessa.	Non è possibile scrivere tutte le radici eMudhra e tutti i certificati come crackati
Catena di firme incrociate correlata a Sectigo	La certificazione incrociata A è stata emessa per lo stesso lotto di chiavi pubbliche interessate, formando un altro percorso di attendibilità.	La corrispondente certificazione incrociata o chiave pubblica deve essere bloccata; non è stato dimostrato che la chiave privata root Sectigo sia stata compromessa.
Livelli di certificato rilevanti per Internet2/InCommon	Alcuni certificati legittimi si basano sulla rimozione della radice emSign ECC, comportando la migrazione	È un effetto collaterale della sfiducia delle radici e non può essere conteggiato come la metà di quelle 8 chiavi deboli CA
Let’s Encrypt, DigiCert, Google Trust Services, GlobalSign, ecc.	Non elencato come la parte la cui chiave privata è stata compromessa in questo rapporto	I certificati legittimi non vengono invalidati in modo uniforme; i client vulnerabili potrebbero comunque accettare certificati falsi che si spacciano per i siti Web che servono
CDN, piattaforma cloud, rivenditore di certificati	Possibilmente fornire certificati pertinenti o utilizzare un truststore pubblico quando ci si connette all’origine e API	Per verificare l’effettiva catena di certificati e il validatore, non limitarti a guardare la piattaforma o il nome del prodotto

L’avviso di Mozilla documenta le chiavi compromesse e le firme incrociate Sectigo. La discussione pubblica sugli incidenti di Google affronta la migrazione delle gerarchie legittime Internet2/InCommon. Le correzioni di 25 Cloudflare riguardano il servizio e la fiducia dei clienti; non indicano la compromissione delle chiavi private CA di Cloudflare. 7

Catena di certificati TLS e firma incrociata

La seguente relazione questa volta descrive solo i percorsi correlati a TLS. Non include i percorsi di firma del codice, né significa che questi percorsi siano ancora attendibili su tutte le piattaforme. 17

emSign Root TLS CA - G3 è uno degli emittenti diretti degli intermediari TLS interessati e può esso stesso rappresentare un punto di riferimento fiduciario in alcuni negozi. emSign ECC Root CA - G3 fornisce un altro livello di firma incrociata. AAA Certificate Services di Sectigo crea un percorso aggiuntivo alle stesse chiavi pubbliche intermedie CA. 17

Pertanto, ci sono due diverse granularità durante la riparazione:

• Blocca esattamente l’intermedio CA o la chiave pubblica: questo può preservare altre gerarchie legittime sotto la stessa radice, dove il validatore supporta quel meccanismo.
• Rimuovi root trust: può proteggere i client senza funzionalità di blocco CA intermedie, ma potrebbe influire sulla compatibilità. Devono essere coperti anche tutti gli altri percorsi accettati dal cliente. 5

“Elimina tutte le radici Sectigo/eMudhra” non dovrebbe essere considerato un passo generale indiscriminato, né la semplice eliminazione di un certificato con un nome simile dovrebbe significare che tutti i percorsi vengono chiusi.

4 Copertura del sistema operativo e del browser

Piattaforma principale

Piattaforma	Disposizione conosciuta	Ambito che dovrebbe essere controllato durante l’utilizzo
Windows e Windows Server	Microsoft Distribuzione bloccata tramite aggiornamento automatico dell’elenco dei certificati attendibili	Se il dispositivo ha ricevuto l’aggiornamento; CA bundle autonomo non utilizza necessariamente il percorso di verifica di Windows
macOS, iOS, iPadOS, ecc. Piattaforma Apple	Il coordinatore dell’incidente ha confermato che Apple ha implementato il blocco in questione	Non è garantito che tutte le versioni precedenti e le app di terze parti ricevano la stessa copertura
Android	Google distribuisce blocchi equivalenti tramite il servizio Google Play	ROM senza servizio Google Play deve essere verificato secondo l’annuncio del produttore; utilizzare il verificatore integrato per ulteriori verifiche
Ubuntu	Sono state fornite correzioni del pacchetto di certificati di sistema, inclusi più rami della versione corrente e precedente	La vecchia versione di ESM supporta condizioni, pacchetto di certificati interni del contenitore e libreria integrata dell’applicazione
Debian e Devuan	Debian registrato ca-certificates fisso	È necessario verificare il ramo effettivamente utilizzato e il pacchetto installato e non è possibile copiare il numero di versione di un altro ramo.
RHEL e derivati	L’elenco ufficiale è RHEL 6, 7, 8, 9, 10 e copre i prodotti e le immagini correlati che potrebbero essere interessati	Al momento di questo controllo, l’annuncio non ha ancora elencato un elenco completo di correzioni ed errata; “Aggiornamento non trovato” non può essere considerato inalterato
Fedora, Arch, Gentoo, Alpine, ecc.	Il manutentore dell’evento ha compilato i record di riparazione corrispondenti	Confermato in modo indipendente dal rilascio, dal ramo della versione e dall’immagine
FreeBSD	Elenca ufficialmente tutte le versioni supportate e fornisce riparazioni del trust store del sistema	Dopo l’aggiornamento, riavviare il processo del demone pertinente in base all’annuncio; controllare separatamente il trust store dell’applicazione indipendente.

Per un riepilogo di Windows, Apple e versioni, vedere 4; per Android vedere 1; per Ubuntu, Debian, RHEL e FreeBSD I record dell’emittente sono visualizzati rispettivamente in 8–11.

I sistemi che non sono più supportati, i dispositivi offline, NAS, router e altri ambienti integrati devono confermare se si fidano ancora della catena pertinente e se dispongono di canali per ricevere revoche o aggiornamenti software. Il nome stesso della piattaforma non sostituisce il controllo del comportamento di verifica effettivo.

La protezione del browser è diversa dalla protezione del sistema operativo

Chrome utilizza CRLSet per distribuire i blocchi di emergenza; Firefox utilizza meccanismi come OneCRL. Firefox è stato rilasciato anche con informazioni di blocco per fornire una protezione aggiuntiva per le configurazioni che non ricevono correttamente le impostazioni remote. 13

Alcune configurazioni di Firefox Android non avevano applicato correttamente l’elenco aggiornato all’avvio, che secondo Mozilla è stato corretto da 158.0.2.. Pertanto, lo stato dei primi 158.0.1 non può essere espanso per includere tutte le configurazioni Android Firefox protette. 2

Sono state adottate misure per la verifica del sistema di Apple e Windows, ma ciò non significa che tutti i programmi della riga di comando sulla stessa macchina saranno sottoposti a verifica del sistema. Il manutentore dell’evento ha ricordato in particolare che alcuni strumenti integrati macOS utilizzano file di certificato indipendenti; il backend TLS effettivo e la sorgente CA dovrebbero essere registrati durante il controllo. 4

Limiti protettivi per la trasparenza dei certificati

Google ha confermato che prima di implementare il blocco, i sei TLS intermedi CA non hanno emesso il certificato TLS inserito nel registro CT. Pertanto, i client Chrome che applicano CT dispongono di una protezione aggiuntiva. Questo fatto non esclude la possibilità che altri client che non eseguono CT abbiano accettato certificati non documentati. 15

“Si scopre che può essere collegato alla radice attendibile”, “esistono potenziali condizioni di sfruttamento” e “si è verificato un attacco” sono tre sentenze diverse e non dovrebbero essere sostituite l’una dall’altra.

5 Ambiente di sviluppo e base di riparazione del runtime

Quella che segue è una linea di base delle correzioni confermate e non è un requisito per bloccare queste versioni a lungo termine. Le distribuzioni possono correggere i numeri di versione precedenti spostando le patch indietro e anche i loro avvisi di sicurezza dovrebbero essere rivisti.

componenti	Versione o metodo di aggiornamento confermato	Considerazioni sulla distribuzione
Node.js 24	24.22.1 oppure aggiornare la versione stabile dello stesso ramo	Contiene gli aggiornamenti del repository root e il rifiuto dei portachiavi pubblici bloccati; verificare il percorso Node effettivamente utilizzato dal servizio e riavviare
Python certifi	2026.10.19 o versione più recente	Controllare ogni ambiente di esecuzione effettivo; non è possibile aggiornare un solo pacchetto in Python globale
pip	26.2.2 o versione più recente	Aggiorna separatamente pip nel vecchio ambiente virtuale e rivedi la versione dopo aver creato il nuovo ambiente
uv	0.13.4 o versione più recente	Aggiorna una copia dello strumento così come è stato effettivamente installato
Go	1.27.3 o 1.26.10, è disponibile anche la versione aggiornata del ramo corrispondente	Ricostruisci e distribuisci i programmi rilevanti dopo aver aggiornato la catena di strumenti o ottieni il binario di riparazione del fornitore
Oracle JDK	Patch Critical per le corrispondenti linee di versione supportate	Diversi editori JDK seguono i propri annunci; non esiste un unico numero di versione applicabile a tutte le versioni Java
Cloudflare Tunnel	cloudflared 2026.10.2 o versione più recente	Aggiorna i servizi in esecuzione; la distribuzione del contenitore richiede la sostituzione dell’immagine e la ridistribuzione
Cloudflare One／WARP	La versione client fissa corrispondente alla piattaforma o la versione stabile aggiornata	Le misure lato client e lato server vengono confermate separatamente. Per versioni specifiche della piattaforma, vedere l’appendice 7

Le istruzioni originali per Node, Python, Go, Oracle e Cloudflare sono rispettivamente disponibili in 13, 12, 14, 15, 7.

Python problema del database dei certificati indipendente

I funzionari di Python hanno sottolineato che il vecchio pip utilizzerà una combinazione di affidabilità del sistema e certifi integrato. La semplice modifica dell’archivio certificati di sistema o l’aggiunta di un file CA a pip non può escludere in modo affidabile il vecchio trust integrato. Pertanto, PIP_CERT, REQUESTS_CA_BUNDLE o --cert non possono essere utilizzati come ricambio universale per la riparazione del vecchio pip. 12

Controlla gli ambienti virtuali esistenti dopo l’aggiornamento. Controlla anche la versione pip effettivamente installata negli ambienti appena creati in modo che i componenti bootstrap più vecchi non reintroducano strumenti vulnerabili. Per l’aggiornamento iniziale, seguire le origini di download e i passaggi di verifica SHA-256 nell’avviso di Python prima di aggiornare altri pacchetti. 12

Go e altri programmi compilati

La correzione per Go ha modificato la logica di convalida per crypto/x509. 14 Dal punto di vista del meccanismo di distribuzione, l’aggiornamento del compilatore sulla macchina di sviluppo non riscriverà il file binario già distribuito. Per ottenere il nuovo blocco del livello di codice è necessario ricostruire e sostituire l’applicazione oppure utilizzare una versione aggiornata fornita dal fornitore. Il fatto che un programma più vecchio possa beneficiare anche degli aggiornamenti root del sistema dipende dall’effettivo percorso di verifica che utilizza.

Contenitori e applicazioni confezionate

Il pacchetto del certificato di sistema, le dipendenze dell’applicazione e il tempo di esecuzione nel contenitore sono generalmente determinati dal contenuto dell’immagine. L’aggiornamento dell’host non è uguale all’aggiornamento del contenuto dell’immagine; l’immagine di base e le dipendenze devono essere aggiornate e l’effettiva istanza in esecuzione deve essere ricostruita, distribuita e controllata. Anche le applicazioni in pacchetto e i programmi desktop forniti con il proprio runtime dovrebbero essere aggiornati in base ai canali di rilascio del fornitore. 710

6 Istruzioni per l’implementazione della riparazione

Determinare innanzitutto l’oggetto da ispezionare

Si consiglia di registrare le seguenti informazioni per i servizi che devono essere protetti, quindi selezionare il percorso di riparazione corrispondente. Questa è una lista di controllo per la distribuzione e non richiede che tutti i componenti siano presenti su ogni sistema.

Progetto	Cosa è necessario registrare
Applicazioni e usi	Browser, client di pagamento API, servizio di invio di e-mail, strumento di download, proxy inverso, ecc.
posizione operativa	Host, contenitore, macchina virtuale, applicazione desktop o dispositivo mobile
Verificare l’implementazione	Validatore del sistema operativo, libreria OpenSSL, Node, Python, Java o implementazione personalizzata dell’applicazione
fonte attendibile	Pacchetto sistema CA, certifi, JDK trust store, CA bundle integrato o configurazione aziendale
Stato della riparazione	Versione installata, origine della patch, se riavviare o ridistribuire
Risultati di accettazione	Se la catena interessata viene rifiutata, se la normale connessione commerciale ha esito positivo e l’ora del controllo

La guida per sviluppatori di Cloudflare afferma specificamente che SDK può delegare la verifica ad altri componenti; solo l’aggiornamento dello SDK di livello superiore non cambia necessariamente la politica di fiducia reale. 7

Sistemi operativi e browser

Windows: abilita e verifica gli aggiornamenti automatici dell’elenco di attendibilità dei certificati. Distribuire gli aggiornamenti attraverso politiche di gestione stabilite. I dispositivi offline o con aggiornamenti automatici disabilitati necessitano del blocco applicato attraverso un apposito processo di gestione. Controllare separatamente i programmi che non utilizzano la convalida del sistema Windows. 4

Apple Piattaforma: Aggiornamenti completi di sistema, componenti di sicurezza e applicazioni. Per gli strumenti di sviluppo su macOS, controlla anche il backend TLS, i file di certificato e le origini di installazione. Non si può ritenere che l’intera macchina sia stata riparata solo perché Safari ha rifiutato la catena di prova. 4

Android: aggiorna i servizi Google Play sui dispositivi che ne sono dotati. Google afferma che il riavvio di un dispositivo può attivare un aggiornamento immediato. Per i dispositivi senza tali servizi, seguire l’avviso del fornitore o ROM; La dichiarazione di copertura di Google non si applica automaticamente a tutti i dispositivi Android. 1

Ubuntu/Debian: aggiorna i pacchetti di certificati dai repository supportati e controlla l’avviso per la distribuzione installata. Ad esempio, un sistema basato su APT può utilizzare:

sudo apt update
sudo apt install --only-upgrade ca-certificates
dpkg-query -W -f='${Package} ${Version}\n' ca-certificates

Gli aggiornamenti rilevanti per Ubuntu 22.04, 24.04, 26.04 e 26.10 sono supporto standard; le versioni precedenti dovrebbero verificare il supporto ESM e lo stato del magazzino. Una volta terminato correttamente il comando, è comunque necessario confrontare la versione del fix pack nel bollettino. 89

RHEL e prodotti correlati: Controllare il pacchetto di certificati e gli errori di sicurezza per canale del prodotto. Il controllo della versione può essere effettuato utilizzando:

rpm -q ca-certificates

Utilizzare il meccanismo di aggiornamento DNF/YUM supportato per ottenere le patch del fornitore; se il canale non ha ancora fornito una correzione, non considerare sicuro “nessun pacchetto aggiornabile”. Quando è necessario rimuovere temporaneamente il root trust, adottare misure chiaramente elencate dal produttore e valutare la compatibilità dei certificati aziendali legittimi. 10

FreeBSD: aggiorna il ramo di sistema pertinente come indicato nell’avviso ufficiale, quindi riavvia i demoni utilizzando la configurazione di trust OpenSSL interessata o riavvia il sistema. 11

Applicazioni e immagini

Dopo aver completato i corrispondenti aggiornamenti del runtime e delle dipendenze del certificato, controllare il percorso del file eseguibile in cui il servizio è effettivamente in esecuzione per evitare che il terminale sia passato a una nuova versione e il daemon utilizzi ancora la vecchia directory di installazione. Per Python multiambiente, i contenitori di servizi e le applicazioni forniti con il proprio runtime, devono essere controllati separatamente.

Per i componenti che devono essere ricompilati, salva la versione di build, la versione di dipendenza e l’ID immagine di distribuzione. L’oggetto di accettazione è l’effettiva istanza in esecuzione e non può semplicemente controllare il nuovo tag nella macchina di compilazione o nel registro delle immagini. 71214

Migrazione del certificato del sito web

Se la catena di un sito web contiene un CA intermedio revocato o bloccato, o in definitiva si basa su una radice non attendibile, procurati un’altra catena che i clienti accettino ancora. Installa la catena completa di certificati del server e controlla ogni ingresso, inclusi bilanciatori del carico, proxy inversi, endpoint CDN e origini accessibili direttamente. 15

La necessità o meno della migrazione dipende dalla catena effettiva. Filtrare solo in base al marchio di vendita del certificato potrebbe non consentire la rivendita o le relazioni di firma incrociata; attendere semplicemente il regolare rinnovo alla scadenza potrebbe non necessariamente completare la migrazione prima dell’aggiornamento del root store.

Per altri normali certificati di siti Web emessi da CA che non si basano sulla root interessata, non è necessario firmarli nuovamente a causa di questo incidente. Allo stesso tempo, il server del sito web stesso dovrebbe comunque eseguire controlli di riparazione lato client quando si chiamano servizi esterni.

7 Verificare che la correzione abbia effettivamente effetto

Il controllo della versione e il controllo del comportamento vengono eseguiti separatamente

I controlli della versione vengono utilizzati per confermare che sono state distribuite patch o componenti fissi; i controlli comportamentali vengono utilizzati per confermare che l’applicazione utilizza effettivamente il percorso di verifica previsto. I due controlli risolvono problemi diversi e nessuno dei due può essere sostituito da “Comando di aggiornamento eseguito con successo”.

Il manutentore dell’evento fornisce i materiali del sito di test e della catena di certificazione e l’ingresso è concentrato nell’appendice 4. Dovrebbe essere verificato nell’effettivo ambiente operativo dell’applicazione di destinazione, mantenendo la normale configurazione di verifica del certificato. 47

Controlla i risultati	Conclusioni che si possono trarre
Rifiuta esplicitamente perché la catena interessata non è attendibile	Indica che il percorso di verifica sottoposto a test ha rifiutato la catena
Accetta normalmente la catena interessata	Indica che è necessario continuare a riparare questo percorso o controllare la configurazione.
Errore DNS, timeout della connessione, rifiuto del proxy o servizio irraggiungibile	Da ciò non si può concludere che il rischio del certificato sia stato eliminato.
Il browser rifiuta, ma la chiamata dell’app non viene controllata	Può solo confermare il browser, non il programma in background.
La catena A è stata rifiutata	È ancora necessario considerare se il cliente accetta un altro percorso di firma incrociata

Il test dovrebbe coprire anche le normali connessioni aziendali per evitare di confondere tutti gli errori di richiesta come riparazioni riuscite dopo che i fallimenti aziendali sono stati causati dalla rimozione di un’eccessiva fiducia.

Condizioni di completamento suggerite

• L’origine dell’aggiornamento e la versione dei componenti interessati sono documentate.
• L’istanza in esecuzione corrispondente è stata riavviata, ricostruita o ridistribuita.
• L’applicazione effettiva rifiuta la catena interessata e la verifica TLS per le normali attività continua a funzionare.
• Non esiste alcuna configurazione per disattivare temporaneamente la verifica del certificato per ripristinare la connessione.
• Se è coinvolta la migrazione del certificato del sito web, tutti gli ingressi esterni sono stati scambiati e verificati.

Le condizioni di completamento sopra riportate costituiscono suggerimenti per l’accettazione del funzionamento e della manutenzione del presente smaltimento; non equivale a dimostrare che l’apparecchiatura non presenta altri problemi di sicurezza.

8 Traffico storico HTTPS e limiti di rischio

Tre tipi di chiavi hanno usi diversi

chiave	Scopo principale
Chiave privata CA	Firmare l’identità e l’associazione della chiave pubblica nel certificato
Chiave privata del sito web	Dimostrare l’identità del server nell’handshake TLS autenticato dal certificato
chiave di sessione	Proteggi i dati effettivamente trasmessi su una connessione

Ottenere la chiave privata CA non equivale a ottenere la chiave privata del sito Web o tutte le chiavi di sessione. A la normale connessione con segretezza in avanti utilizzando lo scambio di chiavi temporanee non esporrà automaticamente le sessioni storiche semplicemente perché la chiave di firma a lungo termine viene successivamente compromessa. Per gli attributi di sicurezza rilevanti di TLS 1.3, vedere RFC 8446. 16

Il rischio principale questa volta si verifica durante la fase di autenticazione: se il client accetta il certificato del server falso, potrebbe stabilire una connessione con l’aggressore ancora crittografata. TLS 1.3 richiede anche un’autenticazione attendibile; il semplice aggiornamento della versione del protocollo non sostituisce il blocco di CA.

Giudizi che possono e non possono essere espressi al momento

Confermato: le specifiche chiavi private intermedie CA sono compromesse; i percorsi di fiducia pubblica interessati hanno un’ampia portata; le principali piattaforme e diversi ecosistemi software sono intervenuti. 145

Non stabilito da questo incidente: che tutti gli utenti hanno subito attacchi man-in-the-middle, che altre chiavi private CA sono compromesse, che tutto il traffico storico HTTPS è decrittografabile o che l’aggiornamento di un browser protegge tutte le applicazioni sul dispositivo.

Il giudizio finale su un servizio specifico dovrebbe basarsi sulla catena di certificati, sulla politica di verifica, sui componenti effettivi in esecuzione e sullo stato dell’aggiornamento, non solo sulla barra degli indirizzi che riporta HTTPS.

Appendice A Nome intermedio interessato CA

I seguenti nomi facilitano i controlli delle risorse. I nomi non sostituiscono le impronte digitali del certificato o gli identificatori di chiave pubblica. La corrispondenza automatizzata dovrebbe utilizzare gli identificatori esatti pubblicati dai manutentori o dai fornitori dell’incidente, inclusi i certificati con firma incrociata. 5

Medio CA	Scopo	Organizzazioni associate
EM EV TLS CA - G3B	TLS	eMudhra BV
EM OV TLS CA - G3B	TLS	eMudhra BV
EM DV TLS CA - G3B	TLS	eMudhra BV
EM EV TLS CA - G3C	TLS	eMudhra Inc
EM OV TLS CA - G3C	TLS	eMudhra Inc
EM DV TLS CA - G3C	TLS	eMudhra Inc
EM OV CS CA - G3B	firma del codice	eMudhra BV
EM OV CS CA - G3C	firma del codice	eMudhra Inc

TLS non è esattamente lo stesso meccanismo di convalida e revoca della firma del codice. Il focus di questo articolo è HTTPS/TLS; l’ambiente di firma del codice dovrebbe adottare Microsoft, JDK o fornitori di software correlati per questo scopo di verifica e i risultati del test del browser non dovrebbero essere considerati come accettazione della firma del codice. 515

Appendice B Collegamento di riferimento

Le seguenti fonti sono state verificate il 22 ottobre 2026. L’annuncio progressivo potrebbe continuare ad essere aggiornato e lo stato e la versione nel testo dovrebbero essere intesi in base alla data di questo documento.

Fatti sugli incidenti e gestione della piattaforma

[1] Google Chrome e Android Annuncio ufficiale Descrive i difetti della chiave privata, il blocco SPKI, la distribuzione del servizio Google Play, la protezione CT e i piani di rimozione del repository root Chrome. Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates

[2] Mozilla Bugzilla 2083449 Registrazione eventi Contiene report originali, verifiche indipendenti, indagini sul processo di generazione, correzioni successive per Firefox Android e discussioni sulla migrazione dei certificati legali; concentrati sui commenti 5, 11, 29 e 30. eMudhra Private key compromise of Intermediate Certificates

[3] Mozilla Firefox Avviso di sicurezza Descrizione della distribuzione di emergenza OneCRL e successivo smaltimento Firefox/NSS. Protecting Firefox users following the compromise of eMudhra intermediate certificates

[4] Coordinatore eventi Dennis Jackson Riepilogo della manutenzione e portale di rilevamento Fornisce istruzioni supplementari sullo stato di riparazione della piattaforma e del software, sull’ammissione al test, sui materiali della catena di certificati pubblici e su ambienti come Windows/macOS. I risultati dei test rappresentano solo i percorsi di verifica effettivi testati. eMudhra Intermediate CA Compromise

[5] Mozilla Avviso ai gestori della distribuzione e del truststore Descrive 6 TLS e 2 intermediari di firma del codice CA, Sectigo limiti di firma incrociata, revoca e elaborazione del trust root ed elenca l’esatto certificato e l’identificazione della chiave pubblica. oss-security eMudhra Intermediates Compromise

[6] eMudhra Dichiarazione ufficiale dell’evento Fornire la spiegazione preliminare del produttore del processo di generazione della chiave; l’esatta causa principale sarà comunque soggetta alla conclusione dell’indagine completata. eMudhra Statement on Recent Certificate Security Incident

[7] Cloudflare Istruzioni ufficiali per incidenti e riparazioni Copre WARP, Cloudflare Tunnel, verifica del sito di origine, dipendenze di runtime, aggiornamenti delle immagini e metodi di verifica. 8 eMudhra certificates are compromised Here is what you need to know

Sistemi operativi e distribuzioni

[8] Ubuntu Annuncio ufficiale di riparazione Elenca i pacchetti di correzioni ca-certificates, i canali di supporto e i passaggi di aggiornamento mirati per ciascuna versione. eMudhra CA compromise fixes available

[9] Debian Registro ufficiale dei problemi e delle riparazioni Il record delle correzioni del manutentore e il corrispondente pacchetto di rilascio dovrebbero essere presi come standard, e i primi suggerimenti temporanei nella discussione del problema non dovrebbero essere considerati come la soluzione finale. Debian bug 1151413 eMudhra Intermediate CA key compromise

[10] Red Hat Bollettino ufficiale di sicurezza RHSB 2026 012 Elenca gli impatti relativi ai prodotti e ai contenitori da RHEL 6 a 10 e corregge le voci relative al rilascio e allo smaltimento temporaneo. Certificate compromise eMudhra

[11] FreeBSD Bollettino ufficiale di sicurezza Fornire i rami di sistema interessati, le versioni di riparazione e i requisiti di riavvio del servizio. FreeBSD SA 26 73 caroot

Runtime e protocolli

[12] Python Descrizione ufficiale dell’evento Fornisce linee di base di riparazione per pip, certifi, uv, ecc., spiega il problema del vecchio trust store indipendente pip e fornisce il metodo di aggiornamento iniziale con la verifica SHA-256. Information for Python users regarding eMudhra emSign CA certificate security incident

[13] Node.js 24.22.1 Versione ufficiale Contiene gli aggiornamenti dell’archivio radice NSS e rifiuta le modifiche contenenti catene di certificati a chiave pubblica bloccate. Node.js 24.22.1 security release

[14] Go Rilascio di sicurezza ufficiale Descrizione crypto/x509 Aggiornamento del filtraggio della catena di certificati per Go 1.27.3/1.26.10. Go 1.27.3 and Go 1.26.10 are released

[15] Oracle JDK Istruzioni ufficiali per lo smaltimento Spiegare la patch critica JDK e le relative misure di configurazione quando non è possibile aggiornarla immediatamente. Distrusting eMudhra Intermediate Certificates in Oracle JDK

[16] TLS 1.3 Protocollo standard RFC 8446 Vedere l’appendice E.1 per istruzioni sull’autenticazione dell’identità, sullo scambio di chiavi temporanee e sulla segretezza in avanti. The Transport Layer Security Protocol Version 1.3

[17] Certificato root correlato all’evento e dati sulla relazione di emissione Utilizzato per comprendere l’emittente diretto e la relazione di firma incrociata; lo stato di inclusione dell’archivio root non può sostituire l’ultimo stato di revoca o di blocco del client. Root certificate relationships JSON