Salta al contenuto

Cos'è un'autorità di certificazione (CA)?

Un'autorità di certificazione (CA) firma i certificati digitali e garantisce di chi è una chiave: ogni sistema che la accetta dipende dalla sua affidabilità.

Un'autorità di certificazione (CA, dall'inglese certificate authority) è l'organizzazione che rilascia i certificati digitali e, firmandoli, garantisce che una chiave crittografica appartenga a un dominio, a un'azienda o a una persona. Funziona come un notaio: quando il browser apre un sito in HTTPS non conosce quel server, ma riconosce la firma della CA sul suo certificato e si fida di quella. In cima alla catena c'è la CA radice (root CA), la cui chiave, per le regole del settore, non firma i certificati dei siti; sotto ci sono le CA intermedie, che la radice autorizza e che emettono i certificati di tutti i giorni. Quali radici accettare, il software lo legge nel proprio trust store, l'elenco delle CA considerate affidabili, che browser, sistemi operativi e alcuni linguaggi di programmazione tengono ciascuno per conto suo. Per questo una CA non è un fornitore qualsiasi: è una dipendenza di fiducia, e se tradisce quella fiducia trascina con sé ogni sistema che la riconosce.

Leggi anche: Certificato SSL/TLS · Il file digitale che cifra il traffico di un sito e ne autentica il dominio, ma non certifica che il sito sia affidabile.

Chi decide di quali CA fidarsi

Le regole comuni le scrive il CA/Browser Forum, che riunisce autorità di certificazione e produttori di browser: i suoi Baseline Requirements fissano come una CA pubblica verifica i richiedenti e protegge le proprie chiavi. Ad ammettere o escludere una CA sono però i root program di Mozilla, Google, Apple e Microsoft, i cui elenchi fanno da base a molti altri. Il punto debole è strutturale: ogni CA accettata può emettere certificati per qualunque dominio.

Quando una CA perde la fiducia: eMudhra ed Entrust

Il 17 ottobre 2026 un ricercatore ha segnalato che le chiavi private di otto CA intermedie di eMudhra si potevano ricostruire: con quelle chiavi chiunque avrebbe potuto emettere certificati validi per qualsiasi sito e intercettare il traffico con un attacco man in the middle. eMudhra ha revocato le otto CA il giorno dopo e attribuisce l'errore a un difetto nella generazione delle chiavi, sfuggito a due audit (eMudhra). Mozilla ha bloccato i certificati in Firefox in meno di tre ore (Mozilla) e i root program hanno escluso la radice ECC di eMudhra. Ma chi non verifica le revoche resta esposto finché qualcuno non aggiorna il trust store: Go e Python hanno inserito nei propri linguaggi un elenco di certificati da rifiutare (CVE-2026-111943, CVE-2026-115557) e Red Hat ha chiesto di ricostruire i container (RHSB-2026-012). La fiducia si perde anche senza compromissione: nel 2024 Chrome ha smesso di accettare i nuovi certificati Entrust dopo sei anni di violazioni delle regole, e chi visitava i siti coinvolti vedeva un avviso a schermo intero (Google).

Un esempio enterprise

Immagino un'azienda con una ventina di microservizi in container e un'integrazione Python con il gestionale di un fornitore. Quando una CA viene esclusa, i browser dei dipendenti si aggiornano da soli. I container no: costruiti su un'immagine di base di due anni fa, si portano dentro il trust store di allora e accettano la CA esclusa finché qualcuno non li ricostruisce. Intanto i servizi cloud già aggiornati, da cui passa l'integrazione, rifiutano il certificato del fornitore, emesso proprio da quella CA, e l'integrazione si ferma. Due guasti opposti con la stessa causa: nessuno sapeva dove stessero gli elenchi di fiducia né chi li aggiornasse.

Perché conta per chi decide

Il primo controllo è un inventario di dove stanno gli elenchi di fiducia, dalle immagini container ai servizi cloud, e di chi li aggiorna, da tenere nel CBOM. Il secondo è un record CAA nel DNS (RFC 8659), che elenca le CA autorizzate a emettere certificati per i domini dell'azienda: dal 2017 le CA pubbliche devono controllarlo, perché il sistema è forte quanto la sua CA più debole (CA/Browser Forum). Il record CAA non ferma però chi firma con una chiave rubata. Il terzo controllo è una seconda CA già provata, per cambiare senza improvvisare. Il quarto è una CA privata per i servizi interni, che li sottrae alle decisioni dei root program ma fa della sicurezza della sua chiave un problema dell'azienda: il caso eMudhra mostra quanto pesi.

Vedi nell'universo

Se è un rischio per la tua azienda, ti dico da dove partire senza venderti paura.

VEDI SICUREZZA E CONFORMITÀ

Oppure scrivimi.