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.
Termini correlati
- 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.
- Attacco man in the middle (MitM) · Un attaccante si inserisce fra due parti in comunicazione e ne legge o altera il traffico senza essere notato.
- HSTS (HTTP Strict Transport Security) · L'header che impone al browser il solo HTTPS verso un sito, chiudendo la finestra lasciata aperta da un semplice redirect.
- CBOM (Cryptography Bill of Materials) · Il CBOM è l'inventario machine-readable degli asset crittografici di un sistema: algoritmi, certificati, chiavi.
- Crypto-agility (agilità crittografica) · Progettare i sistemi in modo che gli algoritmi crittografici si sostituiscano senza riscrivere tutto: NIS2 e DORA la presuppongono già.
Se è un rischio per la tua azienda, ti dico da dove partire senza venderti paura.
VEDI SICUREZZA E CONFORMITÀ