← Tutti gli articoli

Circa 30.000 certificati TLS devono essere trasferiti dopo la scoperta di CA keys deboli

Circa 30.000 certificati TLS devono essere trasferiti dopo la scoperta di CA keys deboli

I certificati TLS che coprono circa 30.000 siti web devono essere trasferiti dopo che le key di otto intermediate CA sono risultate facilmente intuibili. Il consiglio di amministrazione di eMudhra ha deciso di ritirarsi dall'attività globale dei certificati Secure Sockets Layer e Transport Layer Security (SSL/TLS), che fornisce le credenziali digitali utilizzate dai browser per stabilire connessioni affidabili e cifrate con i siti web.

Il 17 ottobre, un ricercatore ha riferito di aver recuperato le private key di otto certificati intermediate CA di eMudhra. Una intermediate CA si colloca tra un trusted root e i certificati dei siti web emessi sotto di essa. La sua private key è il valore segreto utilizzato per firmare certificati e record correlati. Secondo la segnalazione, ciascuno degli otto valori era inferiore a 256, anziché essere un numero casuale molto grande, e risultava quindi individuabile quasi immediatamente. Sei delle otto intermediate CA erano destinate ai certificati TLS.

Il ricercatore ha informato Apple, Google, Microsoft, Mozilla ed eMudhra. Chrome e Firefox hanno bloccato le sei intermediate CA TLS nel giro di poche ore. Google ha dichiarato che, prima dell'intervento di Chrome, nessun certificato per siti web emesso da tali intermediate CA era apparso nei Certificate Transparency (CT) logs pubblici. I CT logs sono record pubblici dei certificati emessi per i siti web; pertanto, prima del blocco, i software che richiedono la presenza dei certificati al loro interno non avrebbero potuto accettare certificati provenienti da tali intermediate CA. eMudhra ha affermato che le otto intermediate CA non avevano mai emesso certificati per siti web o utenti e che i suoi sistemi non erano stati violati.

L'impatto più ampio deriva dall'intervento dei browser contro emSign ECC Root CA - G3, il trusted root sovrastante le intermediate CA interessate. Il 20 ottobre Mozilla ha deciso di smettere di considerare affidabile tale root in Firefox. La rimozione da Chrome dovrebbe raggiungere gli utenti la mattina del 27 ottobre, ora del Pacifico. La rimozione di un root invalida anche certificati TLS altrimenti legittimi che risalgono a esso; gli operatori dei siti web devono quindi sostituire tali credenziali anche se i loro sistemi non sono stati compromessi.

Al 21 ottobre, Chrome aveva contato nei CT logs pubblici circa 30.800 certificati non scaduti collegati al root. Ha dichiarato che il 99,9% era stato emesso tramite InCommon, il servizio di certificati creato da Internet2 per la comunità dell'istruzione superiore. Tra aprile e luglio, InCommon ha trasferito tale servizio sulla piattaforma CertiNext di eMudhra. Google ha ordinato agli operatori interessati di ottenere e installare un nuovo certificato TLS da una diversa gerarchia di public key infrastructure che continui a essere presente nel Chrome Root Store.

eMudhra ha stimato che debbano essere trasferiti circa 30.000 certificati e ha dichiarato che approssimativamente il 97% era stato emesso tramite Automated Certificate Management Environment (ACME), un protocollo utilizzato dai server per richiedere e rinnovare automaticamente i certificati. Chrome ha avvertito che, in genere, i normali ACME client non sostituiscono un certificato prima della consueta finestra di rinnovo, a meno che non supportino ACME Renewal Information (ARI) o intervenga manualmente un amministratore. Il passaggio dalla gerarchia ECC interessata alla gerarchia RSA separata potrebbe inoltre richiedere modifiche alle impostazioni dei client.

Cornell ha consigliato ai titolari dei propri certificati di richiedere certificati RSA, poiché questi utilizzano attualmente il root di eMudhra non interessato dal problema. L'università ha individuato oltre 300 propri certificati interessati. Analogamente, la University of Michigan ha dichiarato che i certificati RSA di InCommon non erano al momento interessati, pur avvertendo che anche il loro root potrebbe perdere la fiducia. Per ora ha indicato Let's Encrypt come principale alternativa.

La gerarchia RSA G1 separata continuerà a servire i clienti durante la transizione. Il 20 ottobre Mozilla ha dichiarato che, in quel momento, non stava rimuovendo emSign Root CA - G1. Chrome stava ancora valutando se i restanti certificati CA di eMudhra dovessero rimanere nel suo root store. A Stanford, i certificati InCommon si collegano a G1 attraverso una certificate authority di eMudhra denominata emSign Root TLS CA - G1.

Sono emersi dubbi anche su una certificate revocation list (CRL) pubblicata il 14 ottobre per emSign Root TLS CA - G1. Una CRL è un record firmato dalla CA che identifica i certificati non più validi. Nel rapporto pubblico sull'incidente di Mozilla, il ricercatore ha dichiarato che non era possibile verificare la firma di questo elenco con la key della CA stessa. Il 22 ottobre, un altro partecipante ha riferito che l'elenco sembrava essere stato firmato utilizzando un certificato Online Certificate Status Protocol (OCSP) di eMudhra, che normalmente firma le risposte sullo stato di revoca dei singoli certificati. Il partecipante ha valutato la discrepanza come un apparente utilizzo della signing key sbagliata, anziché come prova dell'esistenza di un'altra key debole.

Chrome ha incluso l'elenco non valido tra le 12 domande pubblicate il 21 ottobre. Ha chiesto quale key avesse firmato l'elenco, se eMudhra mantenesse più key pair per quella CA o per qualsiasi root, dove venissero trasferiti i clienti e quando sarebbe terminata la migrazione. Il 20 ottobre eMudhra aveva dichiarato che G1 era l'unica alternativa disponibile, per poi affermare il giorno successivo che i clienti statunitensi interessati stavano ricevendo nuovi certificati da un'altra gerarchia CA pubblicamente affidabile e gestita in modo indipendente.

Le domande tornano inoltre su sei CRL non valide pubblicate da eMudhra nel 2025 per le stesse intermediate CA. Nel rapporto sull'incidente dell'epoca, l'azienda aveva dichiarato che gli elenchi erano stati rigenerati utilizzando la private key appropriata per ciascuna intermediate CA. Il 19 ottobre, eMudhra ha comunicato a Mozilla che gli elenchi erano stati inizialmente firmati con le key previste, ma erano poi stati firmati nuovamente utilizzando le key difettose dopo che le prime firme erano risultate non valide. Chrome ha affermato che ciò sollevava serie preoccupazioni riguardo alla trasparenza e alla gestione dell'incidente del 2025, compreso il motivo per cui il precedente rapporto non avesse rivelato l'esistenza di due key pair per ogni CA interessata. Alle 13:31 UTC di giovedì, eMudhra non aveva risposto pubblicamente alle domande di Chrome nella segnalazione del bug e il suo commento visibile più recente risaliva al 20 ottobre.

eMudhra ha dichiarato che i clienti interessati avrebbero ricevuto gratuitamente certificati sostitutivi dai partner, senza però identificare tali partner né stabilire una data di uscita. Continuerà a gestire i servizi di revocation e status fino a quando ogni certificato SSL/TLS da essa emesso non sarà scaduto o sostituito. L'annuncio non ha specificato se, durante il ritiro, nuovi certificati continueranno a essere emessi attraverso G1. Le attività relative ai certificati di firma digitale, a eSign e a CertiNext proseguiranno.

L'azienda ha dichiarato che i servizi SSL/TLS globali rappresentano circa l'1% dei suoi ricavi. Tra i fattori alla base dell'uscita ha citato il costo e la complessità dei requisiti di sovranità dei dati e conformità, la concorrenza dei grandi fornitori che offrono certificati gratuiti e l'attenzione ricevuta in seguito all'incidente.

I proprietari di siti web dovrebbero individuare chi ha emesso ogni certificato TLS attivo, verificare quale root utilizza e sostituire le credenziali interessate anziché attendere un rinnovo automatico. Per gli operatori WordPress che esaminano le modifiche ai certificati insieme alla sicurezza del proprio hosting, AEU Hosting offre hosting WordPress gestito e protetto end to end.

Disponibile anche in: EnglishDeutschShqip