HTTPS a rischio? Il caso eMudhra e 7 controlli sul tuo certificato

HTTPS può smettere di essere considerato affidabile anche prima della scadenza del certificato. Il caso eMudhra mostra perché: ecco 7 controlli pratici per verificare catena, issuer e Root CA del proprio sito prima del 27 ottobre.

HTTPS può smettere di essere considerato affidabile anche quando il certificato del sito non è ancora scaduto. È esattamente il tipo di problema emerso con eMudhra, dove la compromissione di alcune autorità di certificazione intermedie ha costretto Chrome, Firefox e altri componenti dell’ecosistema WebPKI a intervenire rapidamente.

Per chi gestisce un sito la domanda diventa immediata: se oggi compare normalmente il lucchetto del browser, posso essere sicuro che il mio certificato HTTPS continuerà a funzionare anche domani?

La risposta dipende dalla catena di certificazione.

Un certificato HTTPS non vive da solo: viene considerato attendibile perché collega il dominio a una o più autorità di certificazione intermedie e infine a una root certificate authority presente nell’archivio di fiducia del browser o del sistema operativo.

Se quella catena perde fiducia, anche un certificato formalmente valido può diventare inutilizzabile.

Il caso eMudhra è quindi molto più interessante di una semplice notizia su una Certification Authority. Mostra in modo concreto perché HTTPS dipende da un’intera infrastruttura di fiducia e perché il controllo della sola data di scadenza non basta.

In questa guida vediamo cosa è successo, perché la situazione è seria, cosa cambia con la rimozione di emSign ECC Root CA – G3 dal Chrome Root Store e soprattutto quali sono i 7 controlli da fare sul proprio certificato HTTPS prima che un problema di fiducia diventi un errore visibile ai visitatori.

Perché il caso eMudhra riguarda anche chi non usa direttamente eMudhra

Quando apriamo un sito HTTPS, il browser non controlla soltanto che il certificato riporti il nome corretto del dominio e che la sua data di scadenza non sia stata superata.

Deve anche riuscire a costruire una catena di fiducia valida.

In forma semplificata:

certificato del sito → CA intermedia → Root CA attendibile

La Root CA è il punto finale della catena. Chrome, Firefox, Windows, Android e altri sistemi mantengono propri archivi di autorità considerate affidabili e applicano regole precise per stabilire quali certificati possano essere utilizzati.

È il meccanismo che sta dietro al lucchetto del browser e che avevamo già introdotto anni fa nel nostro approfondimento dedicato alla navigazione HTTPS e alla protezione delle connessioni sul Web.

La differenza importante è che la fiducia non è permanente.

Un certificato HTTPS può smettere di funzionare se viene revocata una CA intermedia, se una Root CA viene eliminata dal trust store oppure se il browser decide che quella gerarchia non soddisfa più i requisiti richiesti.

Ed è proprio ciò che rende il caso eMudhra interessante anche per chi non aveva mai sentito nominare questa società.

Il problema non riguarda semplicemente “un certificato difettoso”. Riguarda il sistema attraverso il quale Internet decide quali identità digitali meritano fiducia.

Cosa è successo ai certificati eMudhra

Il 17 ottobre 2026 è stata segnalata la compromissione delle chiavi private associate a otto certificati di autorità di certificazione subordinate eMudhra.

Il punto critico non è stato il classico scenario nel quale un attaccante entra in un server e ruba una chiave privata.

Le chiavi coinvolte erano state generate con un livello di casualità insufficiente.

Per chi controlla un certificato HTTPS, questa distinzione è importante: il problema era nella qualità crittografica delle chiavi stesse.

Google ha spiegato nel proprio approfondimento tecnico sull’incidente eMudhra che l’entropia utilizzata durante la generazione era così debole da permettere la ricostruzione delle chiavi private.

In termini pratici significa che una chiave che avrebbe dovuto essere impossibile da prevedere poteva essere derivata dalle informazioni pubblicamente disponibili.

È un problema estremamente serio quando la chiave appartiene a una Certification Authority.

La chiave privata di una CA intermedia non protegge infatti soltanto un singolo sito. Può essere utilizzata per firmare altri certificati.

Se un aggressore riesce a ricostruirla, può teoricamente creare certificati fraudolenti apparentemente emessi da un’autorità legittima.

Google ha verificato rapidamente la segnalazione e ha distribuito un aggiornamento CRLSet per bloccare le chiavi interessate.

Firefox ha adottato un intervento analogo attraverso OneCRL.

Le otto CA coinvolte non erano però tutte equivalenti: sei potevano essere utilizzate per TLS, mentre due erano limitate al code signing.

Questo dettaglio è importante perché il browser non avrebbe potuto costruire una normale catena HTTPS attraverso le due CA destinate esclusivamente alla firma del codice.

eMudhra: nessuna intrusione nei server, ma il problema resta grave

eMudhra ha dichiarato che la propria infrastruttura non è stata compromessa e che non si è verificato un data breach.

Secondo la ricostruzione pubblicata dalla stessa eMudhra, le autorità interessate erano state create durante una Key Generation Ceremony svolta il 30 aprile 2025.

Un problema nel processo di wrap/unwrap avrebbe generato un secondo insieme di chiavi deboli accanto a quelle correttamente generate.

Le chiavi deboli sarebbero poi finite nell’infrastruttura pubblica.

eMudhra ha inoltre dichiarato che soltanto una delle CA coinvolte era stata utilizzata in produzione e che nessuna delle autorità interessate aveva emesso certificati end-entity.

Anche i dati di Certificate Transparency esaminati pubblicamente non hanno mostrato normali certificati TLS emessi attraverso le sei CA interessate prima dell’intervento.

Questo è un elemento rassicurante sul piano dell’abuso effettivamente osservato.

Non significa però che l’incidente sia trascurabile.

Una Certification Authority pubblicamente riconosciuta deve mantenere un livello di affidabilità estremamente elevato proprio perché la sicurezza di milioni di connessioni può dipendere dalle sue chiavi.

Una chiave CA prevedibile è incompatibile con quel modello di fiducia, anche quando non ci sono prove che sia stata utilizzata per colpire concretamente un sito.

Perché una CA compromessa può mettere a rischio HTTPS

Un certificato HTTPS svolge due funzioni fondamentali.

La prima è permettere la cifratura della connessione.

La seconda è consentire al browser di verificare che il server con cui sta comunicando sia autorizzato a rappresentare quel dominio.

Quando una Certification Authority firma un certificato, sta sostanzialmente affermando che quella chiave pubblica può essere associata al dominio indicato.

Se viene compromessa la chiave privata dell’autorità che firma, questa garanzia può essere falsificata.

Un aggressore che fosse anche in grado di intercettare o dirottare il traffico potrebbe tentare di presentare un certificato fraudolento e impersonare il sito originale.

Naturalmente una chiave CA compromessa non significa automaticamente che chiunque possa intercettare qualsiasi connessione HTTPS.

Per un attacco reale sono necessarie ulteriori condizioni.

Il problema è che viene meno una delle barriere fondamentali sulle quali si basa l’autenticazione del Web.

È per questo che browser e root store reagiscono con grande severità quando una chiave di certificazione viene compromessa.

La sicurezza di un certificato HTTPS non può basarsi soltanto sulla speranza che nessuno abbia ancora sfruttato il problema.

Chrome ha già bloccato le CA: cosa cambia il 27 ottobre

Per gli utenti Chrome la prima protezione è già stata distribuita.

Google ha bloccato tramite CRLSet gli hash SPKI delle sei autorità intermedie interessate utilizzabili per TLS.

Il blocco è stato progettato per proteggere gli utenti senza richiedere un aggiornamento manuale o un riavvio di Chrome.

Ma per chi gestisce un certificato HTTPS, il passaggio successivo è ancora più importante.

Google ha deciso di rimuovere emSign ECC Root CA – G3 dal Chrome Root Store.

La distribuzione della modifica è prevista per martedì 27 ottobre 2026, con arrivo anticipato nei canali prerelease come Chrome Beta e Chrome Canary.

La conseguenza è molto semplice: alcuni certificati legittimi che costruiscono la propria catena verso quella Root CA potranno smettere di essere accettati da Chrome anche se il certificato del sito non è ancora scaduto.

Questo è probabilmente il concetto più importante dell’intero articolo:

la data di scadenza non è l’unico elemento che determina se un certificato HTTPS sia realmente utilizzabile.

Se la catena termina su una Root CA che il browser non considera più attendibile, il certificato non riesce più a costruire una normale catena di fiducia.

Firefox è già intervenuto

Mozilla ha reagito allo stesso incidente attraverso OneCRL, il sistema centralizzato utilizzato da Firefox per distribuire informazioni di revoca.

La risposta tecnica pubblicata dal Mozilla Security Team indica che il blocco era stato distribuito agli utenti Firefox con configurazioni standard entro poche ore dalla segnalazione.

Mozilla ha inoltre pubblicato nuove versioni di Firefox e ha rimosso emSign ECC Root CA – G3 da NSS, la libreria utilizzata anche da altre applicazioni per la gestione della fiducia crittografica.

Questo mostra un altro aspetto poco visibile di HTTPS.

Non tutti i programmi ricevono le informazioni di fiducia nello stesso modo.

Chrome può usare CRLSet e il Chrome Root Store.

Firefox utilizza OneCRL e NSS.

Alcune applicazioni utilizzano invece il trust store del sistema operativo.

Per questo una modifica alla fiducia di una CA può manifestarsi in momenti differenti a seconda del browser, del sistema e del software utilizzato.

eMudhra lascia il business globale SSL/TLS

La vicenda ha avuto anche una conseguenza commerciale molto rilevante.

Il 22 ottobre 2026 eMudhra ha deciso di uscire volontariamente dal business globale dei certificati SSL/TLS.

La società continuerà le proprie altre attività legate a identità digitale, firme elettroniche e infrastrutture di trust, ma abbandonerà il settore dei certificati pubblici utilizzati dai siti Web.

La decisione è arrivata pochi giorni dopo la scoperta delle chiavi deboli ed è stata riportata anche nell’aggiornamento sull’uscita di eMudhra dal mercato globale SSL/TLS.

Questo non significa che ogni certificato HTTPS collegato a eMudhra abbia smesso improvvisamente di funzionare.

Significa però che per i clienti interessati diventa ancora più importante completare la migrazione verso una gerarchia PKI che continui a essere riconosciuta dai principali browser.

eMudhra ha dichiarato di stare collaborando con i clienti coinvolti per fornire certificati sostitutivi e ridurre il rischio di interruzioni.

1. Controlla chi ha emesso il tuo certificato HTTPS

Il primo controllo sul certificato HTTPS è semplice e non richiede competenze da amministratore di sistema.

Apri il tuo sito con Chrome, Edge o Firefox e visualizza le informazioni della connessione e del certificato.

Non fermarti alla scritta “Connessione sicura”.

Cerca il campo relativo all’emittente, normalmente identificato come Issuer.

Il nome che trovi non rappresenta necessariamente la Root CA finale. Molto spesso è una Certification Authority intermedia.

Annotalo.

Se il certificato HTTPS è stato emesso attraverso Let’s Encrypt, Sectigo, DigiCert, Google Trust Services, GlobalSign o un’altra gerarchia, hai già una prima indicazione sull’infrastruttura che stai utilizzando.

Se invece compaiono riferimenti a emSign o eMudhra, devi approfondire immediatamente il percorso di certificazione.

Il fatto che oggi Chrome non mostri alcun errore non significa automaticamente che la configurazione continuerà a essere considerata attendibile dopo il 27 ottobre.

2. Apri la catena completa e cerca emSign ECC Root CA – G3

Il secondo controllo sul certificato HTTPS è quello decisivo nel caso eMudhra.

Apri i dettagli del certificato e cerca il percorso di certificazione, che può essere indicato come Certificate Hierarchy, Certification Path o con un nome equivalente.

Dovresti trovare più livelli.

In basso o all’inizio della catena compare il certificato associato al tuo dominio.

Sopra trovi una o più CA intermedie.

Alla fine trovi la Root CA.

Se la catena termina su:

emSign ECC Root CA – G3

non aspettare la naturale scadenza del certificato.

Google ha espressamente invitato gli operatori dei siti che utilizzano quella gerarchia a ottenere e installare un nuovo certificato TLS appartenente a una diversa PKI presente nel Chrome Root Store.

Il controllo deve essere effettuato sulla catena effettivamente utilizzata dal server.

Non basta ricordare da quale società hai comprato il certificato.

Il provider può utilizzare catene differenti, cross-signing e CA intermedie che non sono immediatamente evidenti dal nome commerciale del servizio.

3. Non guardare soltanto la data di scadenza

Molti amministratori controllano un certificato HTTPS osservando essenzialmente due dati:

dominio corretto e data di scadenza.

Sono entrambi importanti.

Ma non bastano.

Un certificato può essere perfettamente dentro il proprio periodo temporale di validità e diventare comunque non attendibile perché una CA intermedia viene revocata oppure una root viene eliminata dal trust store.

Il caso eMudhra lo dimostra perfettamente.

Quando controlli un certificato HTTPS, verifica almeno:

• dominio e SAN associati;
• data iniziale e finale;
• issuer;
• CA intermedie;
• Root CA;
• eventuali problemi di revoca;
• corretta costruzione della catena.

Il simbolo HTTPS mostrato dal browser è il risultato finale di queste verifiche.

Non è una proprietà permanente ottenuta una volta per tutte quando installi il certificato.

4. Prova il sito con browser e dispositivi diversi

Non tutti i client costruiscono la catena allo stesso modo e non tutti utilizzano lo stesso archivio di Root CA.

Chrome, Firefox, sistemi operativi, runtime e applicazioni possono ricevere gli aggiornamenti di fiducia attraverso meccanismi diversi.

Mozilla ha bloccato le CA interessate attraverso OneCRL.

Google ha utilizzato CRLSet e il Chrome Root Store.

Anche Go ha distribuito aggiornamenti di sicurezza al pacchetto crypto/x509 per respingere gli intermedi noti come non attendibili nei casi in cui il trust store del sistema non venga aggiornato automaticamente.

Questo significa che ogni certificato HTTPS importante dovrebbe essere provato almeno con Chrome e Firefox aggiornati e, quando il servizio è critico, anche da dispositivi differenti.

È la stessa ragione per cui conviene mantenere sempre aggiornato il browser: nel nostro approfondimento su Microsoft Edge e gli aggiornamenti realmente applicati abbiamo visto che una patch può essere disponibile senza essere ancora effettivamente in uso finché il processo interessato non ha completato l’aggiornamento.

Se un browser apre correttamente il sito e un altro restituisce un errore sul certificato, non considerarlo un semplice problema grafico.

È un segnale che la catena o l’archivio di fiducia meritano attenzione.

5. Verifica ciò che il server invia realmente

Un altro errore comune nel controllo di un certificato HTTPS consiste nel pensare che basti installare il certificato associato al dominio.

Il server deve fornire anche gli intermedi necessari affinché il client possa costruire correttamente il percorso di fiducia.

Una configurazione incompleta può funzionare apparentemente su alcuni dispositivi perché l’intermedio è già presente in cache e fallire su altri.

Per questo è utile controllare HTTPS dall’esterno, simulando il comportamento di un nuovo client.

Gli strumenti di analisi TLS permettono normalmente di verificare il certificato servito, la catena inviata, i protocolli TLS disponibili, eventuali errori di chain building e diversi problemi di compatibilità.

Il controllo esterno è particolarmente importante dopo una sostituzione.

Non dare per scontato che il pannello dell’hosting abbia installato automaticamente la catena corretta.

Un certificato HTTPS nuovo con una configurazione incompleta può creare problemi anche quando il file del certificato è perfettamente valido.

6. Se compare eMudhra, prepara la sostituzione prima del 27 ottobre

Se dalla verifica emerge una catena verso emSign ECC Root CA – G3, la strategia corretta non è aspettare che Chrome inizi a mostrare eventuali problemi.

Contatta il provider, il registrar, il servizio di hosting o il soggetto che gestisce il tuo certificato HTTPS e chiedi la migrazione verso una gerarchia differente.

La sostituzione non significa necessariamente cambiare hosting.

Non significa neppure cambiare dominio.

Significa ottenere un nuovo certificato firmato attraverso una catena che continui a essere considerata attendibile dai principali browser.

Dopo l’installazione controlla nuovamente issuer, intermedi e root.

Se utilizzi un servizio completamente gestito può essere lo stesso provider a eseguire la sostituzione senza alcun intervento da parte tua.

Anche in questo caso è comunque opportuno verificare il risultato.

Per un e-commerce, un portale clienti, una webmail o un servizio con autenticazione, scoprire il problema quando gli utenti iniziano a ricevere una pagina di avvertimento del browser è lo scenario peggiore.

7. Dopo la sostituzione, controlla nuovamente HTTPS

La sostituzione del certificato HTTPS non conclude il lavoro.

Dopo la modifica apri una nuova sessione del browser, preferibilmente anche in modalità privata, e controlla il nuovo certificato.

Verifica che:

• il nuovo certificato sia effettivamente quello previsto;
• il dominio sia corretto;
• la nuova catena non utilizzi la Root CA interessata;
• gli intermedi siano presenti;
• il periodo di validità sia corretto;
• Chrome e Firefox non segnalino errori;
• tutte le risorse HTTPS della pagina vengano caricate normalmente.

Se utilizzi CDN, reverse proxy, load balancer o più server, verifica tutti gli endpoint.

È possibile aggiornare il certificato HTTPS sul server principale e dimenticare un nodo secondario, un sottodominio, una webmail o un altro servizio.

Una migrazione TLS può essere considerata conclusa soltanto quando ogni endpoint pubblico utilizza la nuova catena.

Come controllare velocemente HTTPS dal browser

In Chrome puoi aprire il sito e raggiungere le informazioni della connessione attraverso i controlli presenti accanto all’indirizzo.

L’interfaccia può cambiare con le diverse versioni, ma ciò che interessa è aprire i dettagli del certificato e individuare Issuer e catena.

Cerca il certificato associato al dominio e segui la gerarchia fino alla root.

In Firefox puoi effettuare un controllo analogo attraverso le informazioni della pagina e la visualizzazione del certificato.

Se utilizzi Linux o amministri direttamente un server puoi naturalmente andare oltre e utilizzare strumenti come OpenSSL per interrogare l’endpoint TLS e visualizzare la catena inviata dal server.

Per la maggior parte dei proprietari di siti che vuole verificare un certificato HTTPS, però, il browser è sufficiente per capire se compaiono riferimenti evidenti a eMudhra o emSign e decidere se è necessario approfondire.

HTTPS non significa che un sito sia sicuro in assoluto

Il caso eMudhra permette anche di correggere un equivoco molto diffuso.

Il lucchetto HTTPS non certifica che un sito sia privo di malware, vulnerabilità o truffe.

HTTPS protegge principalmente la comunicazione tra browser e server e permette di autenticare il server attraverso il sistema dei certificati.

Un sito malevolo può avere un certificato HTTPS perfettamente valido.

Allo stesso modo, un sito completamente legittimo può diventare temporaneamente irraggiungibile perché la sua catena non è più considerata attendibile.

La sicurezza di un sito richiede quindi più livelli: aggiornamenti, hardening, backup, autenticazione, protezione delle applicazioni e configurazione TLS corretta.

È lo stesso principio che abbiamo visto nel recente caso PHP2Shell e dei controlli necessari sui siti WordPress: una singola misura di sicurezza non sostituisce tutte le altre.

Un sito può avere HTTPS configurato perfettamente e contemporaneamente utilizzare un runtime vulnerabile.

Oppure può essere completamente aggiornato ma avere una catena TLS errata.

La sicurezza reale nasce dall’insieme dei livelli.

Certificate Transparency ha ridotto il rischio dell’incidente

Nella vicenda eMudhra c’è anche un elemento positivo: Certificate Transparency.

Il sistema CT utilizza registri pubblici nei quali vengono inseriti i certificati destinati a essere pubblicamente attendibili.

Chrome applica requisiti di Certificate Transparency ai certificati pubblici e può rifiutare certificati che non rispettano tali regole.

Google ha comunicato che, prima del blocco delle CA interessate, nei log CT non risultavano certificati TLS concatenati alle sei autorità intermedie utilizzabili per HTTPS.

Questo significa che non sono emerse evidenze di normali certificati fraudolenti che sarebbero stati accettati da Chrome attraverso quelle CA prima dell’intervento.

Certificate Transparency non rende impossibile qualsiasi abuso.

Rende però molto più difficile emettere un certificato pubblico senza lasciare traccia.

Il caso eMudhra dimostra quindi non soltanto la fragilità potenziale del modello delle Certification Authority, ma anche l’utilità degli strumenti di sorveglianza introdotti negli anni per renderlo più trasparente.

Cosa deve fare chi naviga normalmente

Se sei semplicemente un utente e non amministri alcun sito, non devi sostituire certificati o modificare configurazioni.

Mantieni aggiornato il browser.

Chrome e Firefox hanno già distribuito protezioni contro le CA coinvolte.

Se dopo il 27 ottobre un sito mostra improvvisamente un errore HTTPS, non utilizzare scorciatoie per ignorare l’avviso soltanto perché “fino a ieri funzionava”.

Il sito potrebbe essere perfettamente legittimo e avere semplicemente una catena che il browser non considera più affidabile.

Ma dal punto di vista dell’utente il risultato non cambia: il browser non riesce più a stabilire la fiducia richiesta.

La scelta corretta è attendere che il gestore corregga il problema.

Un certificato HTTPS può quindi diventare non valido prima della scadenza?

Sì.

Ed è probabilmente la lezione più utile dell’intera vicenda.

La data di scadenza indica soltanto il periodo temporale nel quale il certificato HTTPS può essere utilizzato, a condizione che tutte le altre verifiche abbiano esito positivo.

Una revoca, la compromissione di una CA, una modifica dei trust store, un errore nella catena o un cambiamento delle policy dei browser possono rendere il certificato inutilizzabile prima della data finale.

Per questo chi gestisce servizi Web importanti non dovrebbe controllare HTTPS soltanto quando arriva l’avviso di rinnovo.

La gestione dei certificati è un processo continuo.

E nei prossimi anni diventerà ancora più importante, perché la durata massima dei certificati TLS pubblici continuerà a ridursi e l’automazione della loro gestione avrà un peso crescente.

Il controllo da fare oggi sul tuo sito

Se amministri un sito, dedica cinque minuti al controllo del certificato HTTPS.

Aprilo con un browser aggiornato, visualizza il certificato e controlla la catena.

Individua issuer e Root CA.

Se non compare alcun riferimento a eMudhra, emSign o emSign ECC Root CA – G3, il problema specifico analizzato in questo articolo non riguarda direttamente quella catena.

Se compare uno di questi riferimenti, verifica immediatamente con il provider la sostituzione del certificato prima della modifica prevista nel Chrome Root Store.

E indipendentemente dal caso eMudhra, conserva questa abitudine.

Non controllare soltanto quando scade il certificato HTTPS.

Controlla anche chi lo firma, quali CA intermedie utilizza e quale Root CA conclude la catena.

Il piccolo lucchetto che vediamo nella barra del browser sembra qualcosa di molto semplice.

Dietro quel simbolo esiste invece un’intera infrastruttura internazionale di fiducia crittografica.

Il caso eMudhra ci ricorda una cosa essenziale: anche la fiducia HTTPS può cambiare prima che il certificato scada.