Monitoraggio della Certificate Transparency ad Alta Garanzia

SINTESI ESECUTIVA: La PKI di Internet (Public Key Infrastructure) è un ecosistema sensibile e talvolta fragile. Da quando Netscape ha progettato il nucleo della sua fiducia nel 1995, la comunità globale della sicurezza ha lavorato per comprendere le minacce e, col tempo, sviluppare varie mitigazioni, mentre il mondo continuava a funzionare attorno a questi cambiamenti. Red Sift è stata fortemente coinvolta in questo settore, esplorando lo stato dell'arte della protezione PKI e lavorando per proteggere i nostri clienti.

Questo whitepaper offre un’analisi approfondita delle lezioni apprese durante la realizzazione di Red Sift Certificates, la nostra soluzione di punta per il monitoraggio della postura PKI. Iniziamo con una panoramica su come il mondo gestisce la fiducia e introduciamo concetti e tecnologie sempre più complessi, fino a esplorare le tecniche che abbiamo implementato per aiutare i nostri clienti a raggiungere i loro obiettivi di sicurezza. Infine, presentiamo il Monitoraggio della Certificate Transparency ad Alta Garanzia, una tecnica indispensabile per quelle organizzazioni che richiedono la massima sicurezza PKI pubblica.

Gli ultimi 15 anni sono stati straordinari per Internet in termini di sicurezza del livello di trasporto. Dopo decenni di trascuratezza, si è assistito a un deciso impegno per ottenere la crittografia giusta, uno sforzo che continua tuttora. Ci sono voluti molti anni, ma la comunità di ingegneri ha lavorato per aggiornare il Transport Layer Protocol (TLS), migliorandolo con la crittografia moderna, eliminando il superfluo e garantendo comunque la compatibilità retroattiva. Un successo clamoroso.

Eppure, le PKI pubbliche restano essenzialmente sicure quanto lo sono sempre state.

Nel 2011, una piccola Certification Authority (CA) olandese chiamata DigiNotar è stata colpita e la sua sicurezza completamente compromessa. Nei giorni successivi, sono stati emessi centinaia di certificati per alcune delle proprietà più importanti al mondo. Google, Microsoft, Mozilla, Twitter… scegli pure: sono stati emessi certificati fraudolenti per tutte loro.

Per peggiorare la situazione, questi certificati sono stati usati contro circa 300.000 utenti in un attacco attivo sulla rete progettato per compromettere la crittografia e raccogliere i loro segreti e password. Un attacco di quella portata era senza precedenti; non si era mai visto prima e non è stato più visto da allora.

La stessa cosa potrebbe succedere oggi, perché le debolezze fondamentali nel nostro modello di fiducia restano.

La Public Key Infrastructure (PKI) si riferisce all’insieme di tecnologie, politiche e procedure utilizzate per gestire le identità digitali. Ad esempio, ogni sito web necessita di un’identità digitale verificabile dagli utenti per garantire un accesso criptato sicuro. Queste identità ruotano attorno a chiavi private di crittografia che possono essere verificate tramite le corrispondenti chiavi pubbliche. In pratica, raggruppiamo queste chiavi pubbliche in certificati che contengono tutte le informazioni necessarie per effettuare la validazione. Dal punto di vista dell’utente finale, i certificati sono un dettaglio tecnico che assicura la sicurezza, ma dietro le quinte esiste un ecosistema complesso che garantisce l’efficacia dei certificati.

Nonostante la parola “pubblica” nel nome, le PKI non devono per forza essere pubbliche. Chiunque può creare una propria PKI privata e applicare le regole che desidera. Tuttavia, la sicurezza a livello globale può essere garantita solo da PKI pubbliche costruite con regole ben definite e che consentono la partecipazione di chiunque. La Web PKI è una di queste PKI pubbliche; è strettamente regolata e gestita dai grandi fornitori di browser ed è usata per proteggere i siti web. Esiste anche la Internet PKI, meno definita e talvolta funzionante in ambito Web PKI, talvolta al di fuori. Ai fini di questa trattazione, la distinzione non è spesso fondamentale, ma verrà sottolineata nei casi rilevanti.

Come già accennato, in superficie usiamo i certificati digitali per autenticare l’accesso ai siti web. Questa parte è semplice: prima di accedere alla destinazione, il sito web deve presentare un certificato valido e dimostrare di possedere la chiave privata corrispondente. Tuttavia, il processo di emissione dei certificati è estremamente articolato.

Per prima cosa, selezioniamo un gruppo di organizzazioni di fiducia che chiamiamo Certification Authorities (CA). Ci assicuriamo che siano competenti in materia di sicurezza di rete e capacità operativa, e forniamo loro istruzioni precise su come devono essere fatti i certificati. Il requisito principale è garantire che i certificati digitali vengano emessi solo ai legittimi proprietari, attraverso il processo detto di validazione.

Qui arriva la parte difficile: eseguire la validazione su scala mondiale non è facile, perché bisogna creare relazioni di fiducia da zero. L’approccio dominante è la prova di controllo dell’infrastruttura. In pratica, significa che, se vuoi un certificato per "google.com", devi solo dimostrare di avere un certo controllo su quel dominio, ad esempio pubblicando un file speciale sul relativo sito web.

Questo sistema, creato da Netscape agli albori di Internet, ha favorito la crescita esponenziale del Web, grazie alla sua semplicità d’uso. Purtroppo, presenta due debolezze intrinseche:

• La validazione avviene su reti pubbliche senza autenticazione crittografica. Un avversario che riesca ad attaccare l’instradamento di rete o il DNS, o a dirottare le comunicazioni di rete, può sovvertire l’emissione e ottenere certificati fraudolenti.
• I proprietari dei domini non hanno alcun controllo su quali certificati vengono emessi per le loro proprietà. In altre parole, ci si fida che le CA facciano sempre il loro lavoro correttamente. Sebbene vengano sottoposte ad audit per verificarne la competenza, nella pratica ci sono molte cose che possono andare storte e che sono già successe. Come abbiamo visto con DigiNotar, la loro stessa sicurezza può essere violata. Possono commettere errori operativi o cadere vittime dell’ingegneria sociale. Oppure possono essere costrette legalmente dai governi ad agire contro le regole.

Comprendere queste debolezze è essenziale per poter elaborare strategie atte a rilevare e prevenire gli attacchi, e per minimizzare i danni, qualora si verifichino.

Come già discusso, i certificati vengono emessi solo dopo una dimostrazione di controllo sulla parte rilevante dell’infrastruttura di rete. Per i nomi a dominio, il processo è pressappoco il seguente:

1. Un certificato per example.com viene richiesto a una CA
2. La CA genera un lungo numero casuale e lo invia indietro
3. L’iniziatore pubblica il numero casuale sul sito example.com in chiaro
4. La CA verifica che il numero casuale sia osservabile tramite HTTP
5. La CA emette il certificato

Cosa si può dedurre? Il processo di validazione si basa su alcune componenti fondamentali di Internet, come la risoluzione DNS, l’instradamento degli indirizzi IP (tramite protocollo BGP), e presuppone che la comunicazione non venga dirottata. Oggi, nessuno di questi elementi opera in modo sicuro e sono possibili una varietà di attacchi. Ad esempio, un attacco BGP può reindirizzare il traffico di un indirizzo IP verso l’attaccante invece che al legittimo proprietario. Un attacco di spoofing DNS può reindirizzare il traffico di un sito verso un indirizzo IP sotto controllo dell’attaccante. Un attacco attivo sulla rete contro uno dei due estremi della comunicazione (il sito o la CA) può ottenere lo stesso risultato.

Ora che abbiamo compreso quanto le CA siano importanti per la sicurezza di Internet, cosa sappiamo su di loro? I fornitori di browser si affidano a un sistema chiamato Common CA Database (CCADB) per tracciare le CA e i loro certificati digitali che hanno poteri speciali di emissione di certificati per utenti finali. Questo database è accessibile pubblicamente e quindi di recente ho dato uno sguardo ai dati. Ecco cosa ho scoperto:

• Ci sono 94 organizzazioni CA nel database che sono considerate affidabili da almeno uno dei quattro principali fornitori (Apple, Google, Microsoft o Mozilla).
• Fra queste, 39 organizzazioni sono considerate affidabili da tutti e quattro i fornitori.
• Le 94 organizzazioni sono distribuite in 42 paesi.
• Il gruppo ristretto di 39 organizzazioni è distribuito in 22 paesi.

Cosa si può concludere da questi dati? Innanzitutto, il solo numero di organizzazioni rappresenta una considerevole superficie di attacco. Per mantenere la sicurezza, tutte devono agire correttamente ed evitare errori operativi. In secondo luogo, in un mondo con rapporti politici complessi, avere CA in così tanti paesi crea possibilità teoriche e pratiche di abusi politici.

Queste debolezze non sono solo teoriche. Infatti, tutte si sono già verificate in vari momenti.

• Nel 2011, la sicurezza della CA DigiNotar è stata completamente compromessa ed emessi centinaia di certificati falsi.
• Nel 2021, il dominio di primo livello .cd è stato trovato con un nameserver mal configurato, permettendo a un ricercatore di reindirizzare il 50% di tutto il traffico DNS .cd (inclusi i sottodomini).
• Nel 2022, attaccanti hanno eseguito un attacco BGP contro KLAYswap, un exchange crypto coreano, rubando 2 milioni di dollari in criptovaluta.
• Nel 2023, l’accesso di rete al server web “jabber.ru” è stato dirottato, presumibilmente dalle forze dell’ordine in Germania, consentendo l’emissione di un certificato poi usato per decifrare tutti gli accessi criptati.
• Nel 2024, è stata scoperta l’attività del gruppo di spionaggio Salt Typhoon; si ritiene abbia compromesso la connettività di rete di 60 organizzazioni in 80 paesi.
• Nel 2025, la CA Fina è stata scoperta a emettere dodici certificati per l’indirizzo IP 1.1.1.1 (di proprietà di Cloudflare) senza permesso, nell’arco di 16 mesi.

Questi problemi sono solo un campione rappresentativo di quanto conosciamo. Ogni esempio è stato selezionato per dimostrare uno specifico vettore d’attacco. È probabile che si siano verificati altri attacchi simili rimasti ancora sconosciuti.

In seguito all’attacco DigiNotar del 2011, sono state proposte molte soluzioni per migliorare la sicurezza delle PKI pubbliche. I tentativi di cambiamenti sostanziali nelle modalità di emissione dei certificati sono falliti. Gli interventi di miglioramento incrementale hanno, invece, avuto successo, tra questi la Certificate Transparency (CT). Ciò è stato agevolato dal fatto che tale iniziativa è partita da Google, che poteva esercitare notevole influenza tramite il browser Chrome.

L’obiettivo di CT, come suggerisce il nome, è estendere la Web PKI con sistemi che consentano visibilità completa sull’emissione dei certificati. Se non possiamo modificare i fondamenti della fiducia (nessun controllo tecnico sulle attività delle CA), possiamo almeno concentrarci sulla possibilità di osservare ciò che fanno.

Con CT, la Web PKI si arricchisce di registri CT che fungono da auditor. Prima che un certificato possa essere emesso, le sue informazioni essenziali devono essere registrate su diversi registri CT operati indipendentemente. Per ogni certificato osservato in fase di emissione, i registri CT restituiscono conferme sotto forma di firme digitali. Come passo finale, queste firme vengono incorporate direttamente nei certificati.

Ed è questo ultimo passo che fa funzionare il sistema: ora tutti i certificati includono le prove di inclusione nei registri CT, i browser possono estendere la validazione dei certificati e rifiutare tutti i certificati senza registrazione CT verificabile. Oggi, solo i certificati pubblicati pubblicamente sono utilizzabili per i siti web.

Nota: Qui la distinzione tra Web PKI e Internet PKI conta. La Certificate Transparency è oggi implementata solo nella sfera Web PKI ed è applicata dai browser. I certificati privi di dati CT restano perfettamente validi; possono essere usati per Internet PKI, ma non per siti web. In futuro la situazione potrebbe cambiare.

CT è di fatto obbligatoria dal 2018. Chrome è stato il primo browser a imporla, e già da solo bastava vista la sua quota di mercato. Poi si sono adeguati Apple, Microsoft e Mozilla. La visibilità offerta da CT è stata preziosissima perché ha permesso il monitoraggio su scala mondiale dell’emissione dei certificati, consentendo continui miglioramenti e perfezionamenti, tuttora in corso.

Nota: Le specifiche tecniche che regolano l'emissione dei certificati sono gestite da un organismo di settore chiamato CA/Browser Forum. Browser e CA lavorano insieme per decidere le modalità di validazione e di emissione dei certificati. Il rapporto non è simmetrico: i browser controllano quali CA vengono considerate affidabili, il che dà loro la posizione dominante nel processo decisionale.

Come abbiamo visto, la Certificate Transparency è uno strumento molto utile per il monitoraggio globale dell’ecosistema, ma consente anche ai proprietari di un domain name di monitorare l’emissione di certificati collegati alle loro proprietà. Se ricordiamo le debolezze evidenziate precedentemente sul funzionamento delle PKI pubbliche, è possibile per terzi — anche malintenzionati — emettere certificati per nomi a dominio che non possiedono. Con la CT, chiunque può monitorare i certificati per qualsiasi dominio.

Le organizzazioni che temono attività non autorizzate possono adottare monitor CT per esaminare il flusso di certificati globale e individuare quelli che riguardano loro direttamente. Questa attività apre due possibilità molto interessanti:

• I proprietari dei domini possono monitorare i propri certificati, osservando i centri di emissione e i modelli di utilizzo, oltre che capire quali CA vengono impiegate e da chi.
• Inoltre, è possibile scoprire certificati non autorizzati. In altre parole, la CT permette di individuare i certificati emessi erroneamente.

La Certificate Transparency, così come implementata oggi, non garantisce una visibilità perfetta sull’emissione mondiale di certificati. Questo perché non tutti i fornitori prevedono la pubblicazione su CT all’interno della loro root store policy. Ecco la situazione attuale:

• Apple richiede CT su tutti i certificati, sia per il proprio browser che per qualsiasi altro codice basato sulle proprie librerie ufficiali
• Chrome di Google richiede CT per tutti i siti web
• Edge di Microsoft, essendo basato su Chromium, richiede CT
• Firefox di Mozilla richiede anch’esso CT

Poiché CT non è previsto dai Baseline Requirements e le root store policy non impongono a tutte le CA affidabili di registrare tutto in CT, ci sono delle lacune che potrebbero essere sfruttate. Quindi tecnicamente pubblicare su CT non è obbligatorio. Sebbene le CA normalmente registrino su CT per impostazione predefinita, alcune forniscono la possibilità di opt-out. Inoltre, potrebbero essere costrette per legge a pubblicare al di fuori di CT.

Ovviamente, tali certificati non saranno validi per siti web, ma potrebbero superare la validazione in vari casi:

• Richieste API (tranne dai dispositivi Apple)
• Comunicazione server-to-server, ad esempio per lo scambio di email o XMPP

Ci aspettiamo che l’ambito di CT si allarghi in futuro e comprenda tutti i certificati pubblici. Per ora, occorre tenere a mente i suoi limiti e aggiornare di conseguenza i modelli di rischio.

La Certification Authority Authorization (CAA) è uno standard che consente ai proprietari dei domini di controllare l’emissione dei certificati per le loro proprietà. Le policy CAA sono archiviate nel Domain Name System (DNS), utilizzando il record risorsa CAA. Sono supportate varie funzionalità:

• Controllo su quali CA possono emettere
• Controlli separati per l’emissione di certificati standard, wildcard, email e BIMI
• Possibilità di comunicare policy dettagliate per ciascuna CA
• Distribuzione di informazioni di contatto in caso di problemi

Consideriamo il seguente esempio di configurazione:

example.com.  CAA     0 issue "letsencrypt.org"
example.com.  CAA     0 issuewild "digicert.com"
example.com.  CAA     0 issuewild "sectigo.com"
example.com.  CAA     0 issuemail ";"
example.com.  CAA     0 issuevmc ";"
example.com.  CAA     0 iodef "pki@example.com"

L’CAA rappresenta un controllo applicato immediatamente prima dell’emissione di certificati. Non è un controllo rigido, ma l’utilizzo è obbligatorio per tutte le CA secondo i Baseline Requirements. Un’emissione che non rispetti la configurazione CAA del proprietario è considerata errata.

La capacità più importante del CAA è limitare quali CA possono emettere quali tipi di certificati. In assenza di una policy CAA sul dominio, tutte le CA e tutti i tipi di certificati sono consentiti. Se invece è presente almeno una direttiva per un tipo di certificato (ad esempio “issue” per certificati standard o “issuemail” per S/MIME), potranno emetterli solo le CA elencate. Se è presente solo un punto e virgola, nessuno può emettere alcun certificato.

Decifriamo ora l’esempio di configurazione precedente:

• Let's Encrypt può emettere certificati standard
• DigiCert e Sectigo possono emettere certificati wildcard
• Nessuno può emettere certificati S/MIME o BIMI
• L’indirizzo “pki@example.com” può essere usato per segnalare problemi

I tag “issue” e “issuewild” lavorano insieme. Se è presente solo il tag “issue”, l’emissione è consentita sia per i certificati standard che per i wildcard. Se è presente anche “issuewild”, il controllo sull’emissione dei wildcard è esclusivo di quest’ultimo.

L’CAA è flessibile quanto a collocazione. Ogni dominio può avere una configurazione diversa. Inoltre, se il CAA non è rilevato su un sottodominio, viene controllata, e adottata se presente, la configurazione del dominio padre.

Nella sezione precedente abbiamo parlato della meccanica di restringere le CA abilitate; ma a cosa serve concretamente? Questa attività è preziosa perché riduce la superficie di attacco. Come abbiamo visto, le debolezze strutturali delle PKI pubbliche sono molteplici. In particolare, molte CA possono emettere certificati per le tue proprietà e tutte devono sempre agire correttamente.

In pratica, la maggior parte delle organizzazioni collabora con un piccolo numero di CA; le restanti rappresentano una vulnerabilità. Usando il CAA, tale rischio viene ridotto.

L’approccio base consigliato è il seguente:

1. Compilare una lista esaustiva dei domini posseduti
2. Usare CT per costruire un inventario di tutti i certificati pubblici
3. Monitorare CT per un periodo e compilare una lista delle CA effettivamente rilevate
4. Implementare una configurazione CAA che limiti l’emissione solo alle CA osservate

Questa strategia riduce il rischio PKI con poche possibilità di rompere gli attuali flussi di emissione. La configurazione CAA desiderata deve essere impostata su ogni nome a dominio registrato. A seconda del livello di sicurezza desiderato, si può optare per un unico elenco CA per tutte le proprietà o restringere la lista CA ad ogni dominio.

Nota: Di solito, il DNS viene utilizzato per delegare un controllo limitato a terzi, ad esempio per offrire un servizio completamente gestito sul proprio dominio tramite record CNAME. La policy CAA impostata sul dominio principale non dovrebbe impedire l’emissione, anche se terzi usano una CA non presente nella nostra lista. Questo perché, con CNAME, tutte le impostazioni DNS — compresi i record CAA — vengono delegate. Unico accorgimento: i fornitori terzi devono conoscere il CAA e impostare una policy CAA propria che funzioni per loro.  

Lo standard base CAA è un buon punto di partenza, ma non è sufficiente per le organizzazioni che devono proteggere proprietà di alto valore. Una “falla” è che il CAA limita le CA autorizzate, ma non impedisce a terzi di usare quelle stesse CA per ottenere certificati. Il problema è amplificato dal fatto che praticamente tutte le organizzazioni usano Let's Encrypt, data la gratuità e l’automazione. Così la soglia per usare Let's Encrypt è bassissima.

Entrano qui in gioco le estensioni ACME CAA. ACME significa Automatic Certificate Management Environment: lo standard per l’emissione automatizzata dei certificati, lanciato da Let's Encrypt nel 2015 e oggi adottato da tutte le CA. La RFC 8657 standardizza due funzionalità aggiuntive in corrispondenza tra ACME e CAA:

• Limitare quali account cliente di CA possono richiedere certificati
• Limitare quali metodi di validazione ACME possono essere usati

Al momento della redazione, la RFC 8657 non è obbligatoria. Tuttavia, è previsto che lo diventi a breve. Oggi, Let's Encrypt è l’unica CA a supportarla ufficialmente. La natura di queste estensioni è tale che, a differenza del CAA base, non è necessario che tutte le CA le supportino perché risultino utili: basta che lo facciano le CA con cui si collabora. In caso di dubbio, chiedere alla propria CA. Alcune di loro offrono funzionalità proprietarie con effetto analogo.

Con RFC 8657, è possibile autorizzare l’emissione di certificati per un dominio da una CA ma solo a specifici account cliente di quella CA. Ecco come si presenterebbe lavorando con Let's Encrypt:

example.com.  CAA  0  issue "letsencrypt.org;
                             accounturi=https://acme-v02.api.
                             letsencrypt.org/acme/acct/1726001367"

Per tutta la durata di quella configurazione, solo l’account “1726001367” potrà ottenere certificati da Let's Encrypt per “example.com”. Se si desidera autorizzare più account, basta aggiungere ulteriori tag CAA, ognuno relativo a un account cliente differente.

L’altra funzionalità della RFC 8657 è la possibilità di specificare quali metodi di validazione ACME siano consentiti prima che venga emesso un certificato. ACME offre diversi metodi e i clienti scelgono normalmente quello che preferiscono al momento della richiesta. Il metodo più popolare è la prova di proprietà, che impone la pubblicazione di una risposta alla CA sul sito web per cui è richiesto il certificato.

Questo approccio è spesso conveniente perché permette a ogni server di interfacciarsi direttamente con una CA e ottenere certificati autonomamente. Tuttavia, dal punto di vista della sicurezza, consentire ai server di auto-emettersi i certificati non è sempre la soluzione ideale; chiunque controlli un server può ottenere certificati per qualsiasi dominio che vi punti.

Un modo per sfruttare una simile configurazione è tramite una misconfigurazione DNS dangling. Perché il dominio sia funzionante, servono modifiche sia in DNS (con record A o AAAA), sia su un server agli indirizzi IP coinvolti. Un problema di DNS dangling nasce quando un server viene smantellato ma le sue entry DNS non vengono rimosse. Immaginiamo che tali indirizzi IP provenissero da un servizio cloud, come spesso accade: chiunque venga assegnato a quegli IP può ottenere certificati per il dominio DNS dangling. Questo è solo un esempio: ci sono altri vettori di attacco simili.

Un’organizzazione che voglia evitare questo tipo di rischio può scegliere di centralizzare l’emissione dei certificati e usare il metodo di validazione ACME basato su DNS. Tuttavia, per farlo, è necessario disabilitare tutti gli altri metodi di validazione. Ecco come apparirebbe impostando la RFC 8657:

example.com.    CAA    0    issue "letsencrypt.org;
                                   validationmethods=

                                  dns-01"

Con questa configurazione, l’emissione dei certificati può essere approvata solo tramite la modifica diretta della configurazione DNS del dominio richiesto.

I due metodi di restrizione previsti dalla RFC 8657 regolano entrambi l’emissione dei certificati, ma presentano differenze cruciali che influiscono sulla scelta d’adozione.

• La restrizione sul metodo di validazione non richiede autenticazione della richiesta. Se l’emissione è limitata a metodi come “dns-01”, solo chi controlla il DNS (o una parte di esso) può soddisfare la configurazione CAA. Questo riduce la superficie di attacco, ma la richiesta di emissione resta non autenticata. Ad esempio, è ancora possibile sfruttare una misconfigurazione DNS.
• La restrizione sugli account impone un’autenticazione forte. Limitando l’emissione a specifici account cliente, si forza invece una autenticazione forte della richiesta di emissione, prima di qualsiasi validazione. Con ACME, ad esempio, gli account sono protetti tramite crittografia pubblica. La prima azione di qualsiasi client ACME è creare un’identità crittografica unica, utilizzata poi per ogni emissione. Se c’è restrizione d’account, l’autenticazione della richiesta è il primo passo nell’interazione ACME: il client deve dimostrare di essere associato all’account specificato nella configurazione CAA.

Nota: Nel giugno 2025 il CA/Browser Forum ha deciso di adottare la Ballot SC-085v2, che introduce l’obbligo di validare DNSSEC per le lookup CAA e le DCV (domain control validation). Questi cambiamenti saranno obbligatori per tutte le CA da marzo 2026. Dopo tale data, i domini con DNSSEC non saranno più vulnerabili a spoofing DNS di qualsiasi tipo. 

Le estensioni definite nella RFC 8657 consentono di applicare controlli rigorosi sull’emissione dei certificati, ma non sono gratuite: servirà tempo e impegno per ristrutturare i flussi di emissione in modo compatibile con i massimi livelli di sicurezza. Di solito, non conviene applicare l’approccio su tutti i domini posseduti, perché non sarebbe efficiente in termini di costo. Tuttavia, è perfetto per un ristretto insieme di proprietà di alto valore. Per tutto il resto, è sufficiente limitarsi a consentire l’emissione solo a poche CA.

Per le proprietà di alto valore, segui questo percorso:

1. Scegli due o tre CA affidabili. Ne servono almeno due per evitare un singolo punto di fallimento. Raccomando sempre di avere almeno un certificato di backup valido, in caso di problemi con il principale. Le CA selezionate devono almeno supportare la RFC 8567 o avere funzionalità proprietarie equivalenti.
2. Implementa una configurazione CAA rigorosa sul dominio principale, limitando l’emissione solo alle CA scelte e — fondamentale — solo agli account specifici presso quelle CA. In questo modo si ottiene una validazione crittografica forte.
3. Monitora la tua configurazione DNS per a) assicurarti che non ci siano problemi di DNS dangling e b) verificare eventuali deleghe a terzi tramite CNAME (che potrebbero avere una loro policy CAA prevalente).

Come abbiamo visto, la Certificate Transparency ha rivoluzionato il modo in cui monitoriamo l’operato delle CA. Tuttavia, il monitoraggio presenta ancora delle sfide:

• È ancora possibile pubblicare certificati pubblici fuori da CT, come discusso in precedenza.
• Il monitoraggio CT è ancora poco diffuso. Nonostante sia obbligatorio da anni, la maggior parte delle organizzazioni non investe abbastanza risorse nel monitoraggio dell’emissione dei certificati per le proprie proprietà.
• Distinguere il segnale dal rumore è difficile. Spesso nei certificati non ci sono abbastanza informazioni per distinguere tra le normali emissioni e quelle ottenute in modo fraudolento da terzi. Per farlo servono strumenti avanzati di monitoraggio, di cui la maggior parte delle organizzazioni ancora ignora l’esistenza.

Pur volendo esplorare qui lo stato dell’arte, riconosciamo che molte organizzazioni non necessitano delle soluzioni più avanzate. Anche quelle che lo richiedono difficilmente avranno bisogno dei massimi livelli di sicurezza su tutti i domini e siti.

Consigliamo di suddividere le vostre proprietà in tre gruppi, a seconda del profilo di rischio:

• Rischio molto basso: qui vanno messi tutti i domini “parcheggiati” o inutilizzati. A seconda delle dimensioni dell’organizzazione possono essercene pochi o centinaia. Salvo automazione DNS estesa, migliorarne la sicurezza probabilmente non sarebbe tempo ben speso. 
• Basso rischio: qui vanno domini con siti o applicazioni effettivamente attivi. Dovrebbe essere il gruppo predefinito. Implementate una semplice configurazione CAA per limitare l’emissione alle poche CA desiderate, come già discusso. Queste proprietà difficilmente saranno attaccate: il CAA servirà in pratica solo a rafforzare il policy aziendale di scelta CA.
• Alto rischio: qui vanno le proprietà critiche, ovvero quelle realmente a rischio di attacco. Siti e applicazioni che trattano denaro, faccende governative, comunicazioni o in genere soggette ad attacchi attivi reali. È su questo gruppo che vale la pena concentrare tutte le misure tecniche disponibili.

Il monitoraggio CT ad alta garanzia è un approccio che consente, con elevata sicurezza, di monitorare il flusso di certificati pubblicati su Certificate Transparency e distinguere i certificati sotto il proprio controllo da quelli ottenuti da terzi non autorizzati.

L’idea di base è semplice e si fonda sulla validazione di ciò che si sa essere affidabile, per poi classificare tutto il resto come sospetto:

1. Mantieni un inventario di certificati sotto il tuo controllo
2. Monitora la Certificate Transparency per individuare certificati sconosciuti

Tutto qui. Solo due passaggi, ma il primo può richiedere non poco lavoro a seconda dell’organizzazione. Ricorda che è un’attività da applicare solo alle proprietà ad alto rischio, non su tutto.

• Se usi un Certificate Lifecycle Management (CLM) o ACME con una CA commerciale, probabilmente hai un inventario integrato. In tal caso recuperare l’elenco dei certificati è semplice, ma serve comunque uno sviluppo via API.
• Se usi ACME con una CA gratuita (es. Let's Encrypt), potrebbe non esistere un inventario integrabile. In questo caso devi predisporre un meccanismo per raccogliere i certificati emessi e trasferirli in un luogo centrale. Sarà più facile se le emissioni sono tutte da un server unico, ma è fattibile anche con più server.

Nella pratica, è probabile che occorra mantenere un database separato con tutti i certificati di proprietà. L’emissione centralizzata è rara nella realtà, soprattutto su larga scala. Esistono sempre casi particolari, tra cui la delega parziale della PKI pubblica a terzi. Una soluzione completa dovrà integrare molteplici fonti dati per un quadro davvero completo.