La sfiducia verso Entrust: i punti chiave per le CA e le organizzazioni

L'utente medio del web non sempre è consapevole di quanto lavoro viene svolto dietro le quinte per mantenere sicuro il mondo digitale. Ma i siti web, le email, i server e i software sono attendibili perché garantiti dai certificati digitali emessi dalle autorità di certificazione (CA). Queste CA sono ritenute attendibili da organismi che definiscono gli standard come il Certificate Authority/Browser (CA/B) Forum.

A volte, a causa di errori umani o di bug nel codice, i certificati emessi non soddisfano i severi requisiti di conformità degli operatori del root store. In questi casi, la CA è tenuta a indicare con trasparenza quanto accaduto, revocare i certificati e aiutare la community ad apprendere dall'errore.

Ma come abbiamo visto con la sfiducia di Google Chrome verso Entrust, le conseguenze di una mancata mitigazione tempestiva del danno possono essere enormi sia per le CA che per i loro clienti.

Perché Google non si fida più di Entrust?

Nel giugno 2024, il Chrome Security Team di Google ha annunciato che non si sarebbe più fidato dei certificati TLS emessi da Entrust successivamente al 31 ottobre 2024. Pochi mesi prima, Entrust aveva riconosciuto di aver emesso in modo errato oltre 26.000 certificati TLS EV.

La tempistica di revoca dei certificati emessi in modo errato indicata nei Requisiti di base del CA/B Forum è molto breve: 24 ore o cinque giorni, a seconda della natura del problema. Di solito la CA può rimediare al problema con conseguenze minime per le organizzazioni, ma Entrust non ha provveduto a revocare o sostituire i certificati interessati.

Una mancata azione può portare a conseguenze come interruzioni operative, incertezza sullo stato della CA e perdita di fiducia dei clienti. Se una CA come Entrust non revoca o sostituisce i certificati emessi in modo errato, i browser web possono non considerare più affidabile la CA, come ha fatto Google nel 2024.

In che modo le aziende possono evitare le interruzioni operative dovute all'emissione di certificati errati

È normale che i software contengano bug, quindi le emissioni errate possono verificarsi anche con cicli di vita di sviluppo software molto sofisticati. Quando succede, l'obiettivo principale della CA dovrebbe essere capire dove si è verificato l'errore e assicurarsi che non si ripeta.

Nel 2023, DigiCert ha scoperto che 300 certificati emessi a un produttore di dispositivi globale non erano conformi ai rigidi requisiti di profilo stabiliti dai Baseline Requirements del CA/B Forum. In base a questi requisiti, avevamo cinque giorni di tempo per revocare i certificati e rimanere conformi agli standard, standard che tutte le CA accettano come parte del loro ruolo di entità pubblicamente attendibile.

C'era un solo problema: dopo aver discusso la questione con il cliente, fu chiaro che la revoca dei certificati entro cinque giorni avrebbe causato gravi interruzioni ai sistemi critici, con conseguenti problemi di sicurezza per i consumatori. Abbiamo lavorato a stretto contatto con il produttore e abbiamo stabilito che sarebbe stato necessario un mese per sostituire i certificati emessi erroneamente.

Non potevamo non rispettare le regole del CA/B. Ma non potevamo neanche revocare i certificati senza averli sostituiti in modo corretto. Ci siamo quindi consultati con la community e abbiamo lavorato con i nostri clienti 24 ore su 24 per far sì che i loro nuovi certificati fossero operativi per tempo.

Anche se questa esperienza è stata stressante per tutti i soggetti coinvolti, analizzare la causa degli errori ha permesso al nostro cliente di adottare le giuste misure per evitare che l'emissione di certificati errati diventasse un problema ricorrente.

Ecco alcuni consigli per tutte le organizzazioni che si affidano ai certificati per mantenere la sicurezza:

1. Utilizzare i certificati di fiducia privati quando opportuno.

Il CA/B Forum stabilisce solo gli standard per i certificati di fiducia pubblica. Non esiste una tempistica di revoca di cinque giorni per i certificati di fiducia privata. Nel caso del nostro cliente produttore di dispositivi, l'inserimento di certificati di fiducia pubblica su elementi che non lo richiedevano, come i dispositivi connessi, ha generato problemi evitabili.

Il nostro consiglio? Esamina l'utilizzo dei tuoi certificati ed elimina il rischio di revoche che potrebbero compromettere la tua attività cambiando i certificati di fiducia pubblica in certificati privati se questi ti sono sufficienti.

Ecco alcuni dei casi d'uso più comuni per i certificati di fiducia privata:

Dispositivi connessi: i dispositivi IoT connessi utilizzano i certificati per autenticare manualmente le connessioni a gateway, server, applicazioni o altri dispositivi. Queste comunicazioni avvengono di solito su reti private, non è quindi necessaria la fiducia pubblica.
App e siti web interni: dato che non è accessibile pubblicamente, la Intranet aziendale non necessita di fiducia pubblica.
Comunicazione interorganizzativa: le organizzazioni partner possono eliminare la necessità della fiducia pubblica configurando manualmente i loro sistemi in modo che accettino i rispettivi certificati privati.
VPN: l'utilizzo di certificati privati per l'autenticazione di client e server fa in modo che solo i dispositivi attendibili possano connettersi alla VPN aziendale.

Ti consigliamo inoltre di eseguire controlli di conformità automatici sui tuoi certificati con pkilint, il programma open-source gratuito di DigiCert.

2. Implementare una soluzione completa di gestione dei certificati.

Molte aziende utilizzano ancora fogli di calcolo per tenere traccia manualmente dei loro certificati. Con una soluzione di gestione del ciclo di vita dei certificati (CLM), rispettare la scadenza dei cinque giorni prevista dal CA/B Forum non è un problema. Ma senza questa soluzione, la sostituzione dei certificati emessi in modo errato può richiedere un complesso processo manuale che può durare anche settimane.

Se la tua organizzazione non utilizza ancora un CLM completo, implementa una soluzione come DigiCert Trust Lifecycle Manager, che fornisce:

Discovery dei certificati PKI
Un repository completo di tutti i certificati pubblici e privati
Visibilità granulare e controllo operativo
Notifiche per prevenire la scadenza dei certificati
Remediation delle vulnerabilità

L'importanza di collaborare con un'autorità di certificazione che dia priorità alla fiducia digitale

La fiducia digitale di cui tanto parliamo in DigiCert non è un concetto astratto: è oggettivo e misurabile. I siti web e i prodotti digitali delle organizzazioni sono protetti da certificati attendibili oppure non lo sono. Le CA aderiscono agli standard stabiliti da gruppi come il CA/B Forum, oppure no.

Quando una CA accetta di far parte di una community di fiducia, la sua attendibilità si misura in base alla sua trasparenza e alla sua volontà di rispettare le regole. Di per sé, un errore di emissione non porta automaticamente alla sfiducia. Ciò che conta è il motivo del problema, cosa ha appreso la CA da questa nuova situazione e come gestisce l'incidente.