Ultimo aggiornamento: 5 gennaio 2025

SINTESI ESECUTIVA: La PKI di Internet (Public Key Infrastructure) è un ecosistema delicato e talvolta fragile. Dal 1995, quando Netscape ha progettato il nucleo della fiducia digitale, la comunità globale della sicurezza si è impegnata a comprendere le minacce e, nel tempo, a sviluppare varie misure di mitigazione, mentre il mondo continuava a funzionare intorno ai cambiamenti. Red Sift è stata coinvolta attivamente in questo settore, esplorando lo stato dell’arte della protezione PKI e lavorando per tutelare i propri clienti.

Questo whitepaper offre un'analisi approfondita delle lezioni apprese durante lo sviluppo 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 propri obiettivi di sicurezza. Infine, presentiamo il Monitoraggio della Certificate Transparency ad Alto Livello di Garanzia, una tecnica imperdibile per le organizzazioni che richiedono la massima sicurezza PKI pubblica.

Negli ultimi 15 anni la sicurezza del livello di trasporto su Internet ha compiuto grandi passi avanti. Dopo decenni di trascuratezza, si è avviato un impegno determinato per realizzare una crittografia efficace, uno sforzo che continua ancora oggi. È servito molto tempo, ma la comunità degli ingegneri ha lavorato per aggiornare il Transport Layer Protocol (TLS), modernizzando la crittografia, eliminando componenti obsolete e mantenendo la compatibilità all’indietro. Un grande successo.

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

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

A peggiorare la situazione, questi certificati sono stati poi utilizzati contro circa 300.000 utenti, tramite un attacco di rete attivo progettato per compromettere la crittografia e sottrarre segreti e password. Un attacco di tale portata non si era mai visto prima né si è più verificato da allora.

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

La Public Key Infrastructure (PKI) indica l’insieme di tecnologie, policy e procedure utilizzate per gestire le identità digitali. Ad esempio, ogni sito web necessita di un’identità digitale che possa essere verificata dai consumatori per garantire un accesso criptato sicuro. Queste identità sono costruite attorno a chiavi di crittografia private che possono essere verificate tramite le chiavi pubbliche corrispondenti. In pratica, queste chiavi pubbliche vengono incluse nei certificati che contengono tutte le informazioni necessarie alla validazione. Dal punto di vista dell’utente finale, i certificati sono dettagli tecnici che garantiscono la sicurezza, ma dietro le quinte esiste un ecosistema complesso che assicura che i certificati forniscano la sicurezza necessaria.

Nonostante la parola "public" nel nome, le PKI non devono per forza essere pubbliche. Chiunque può creare la propria PKI privata e applicare qualunque regola desideri. Tuttavia, solo le PKI pubbliche, costruite su regole ben definite e che consentono a chiunque di partecipare, possono dare sicurezza su scala globale. La Web PKI è un esempio di PKI pubblica: è fortemente regolamentata e gestita da grandi vendor di browser, utilizzata per proteggere i siti web. Esiste anche la Internet PKI, meno definita, a volte integrata nella Web PKI e a volte no. In questo contesto, la distinzione è raramente critica, salvo casi specifici che verranno evidenziati.

Come già accennato, a livello superficiale, usiamo i certificati digitali per autenticare l’accesso ai siti web. Questa parte è semplice: prima di poter accedere alla destinazione, il sito deve presentare un certificato valido e dimostrare il possesso della chiave privata corrispondente. Tuttavia, il processo mediante cui rilasciamo i certificati è molto articolato.

In primo luogo, si scelgono organizzazioni fidate chiamate Certification Authorities (CA). Di queste si verifica la competenza in termini di sicurezza e capacità generale, e si forniscono istruzioni precise riguardo l’aspetto che i certificati devono avere. Il requisito principale è garantire che i certificati digitali siano rilasciati solo ai legittimi proprietari, tramite un processo chiamato validazione.

Qui viene il difficile: validare su scala mondiale non è facile, perché bisogna creare relazioni di fiducia da zero. L’approccio dominante oggi è la prova di controllo dell’infrastruttura. In pratica, ciò significa che se desideri un certificato per "google.com", basta dimostrare un certo controllo su quel dominio, ad esempio pubblicando un file speciale sul sito stesso.

Questa soluzione, ideata da Netscape nei primi giorni di Internet, è ciò che ha consentito la rapida crescita del Web perché è semplice da utilizzare per chiunque. Purtroppo, presenta due debolezze intrinseche:

• La validazione avviene su reti pubbliche senza autenticazione crittografica. Un aggressore che riesca ad attaccare il routing di rete, il DNS o intercettare la comunicazione può sovvertire il rilascio e ottenere certificati fraudolenti.
• I titolari dei domini non hanno alcun controllo su quali certificati vengano rilasciati per le proprie proprietà. In altre parole, le CA vengono considerate fidate nello svolgimento del proprio ruolo. Anche se vengono auditati per verificarne la competenza, nella pratica possono verificarsi diversi errori o incidenti, come già visto con DigiNotar: la loro sicurezza può venire compromessa, possono commettere errori operativi, cadere vittime di ingegneria sociale, oppure essere obbligati dai governi a comportamenti non consentiti.

Comprendere queste debolezze è essenziale per poter sviluppare strategie di rilevamento e prevenzione degli attacchi, e minimizzare i danni se accadono.

Come discusso, i certificati vengono rilasciati solo dopo aver dimostrato il controllo sulla parte rilevante di infrastruttura di rete. Per i nomi di dominio, grosso modo il processo è il seguente:

1. Si richiede un certificato per example.com a una CA
2. La CA genera un lungo numero casuale e lo invia indietro
3. L’iniziatore pubblica il numero casuale sul sito in chiaro example.com
4. La CA verifica che il numero casuale sia visibile via HTTP
5. La CA rilascia il certificato

Cosa ne deduciamo? Il processo di validazione si basa sulla “plumbing” dell’Internet, come la risoluzione DNS, il routing IP (tramite BGP), e presuppone l’assenza di intercettazioni. Ad oggi, nessuno di questi componenti è del tutto sicuro e possono essere eseguiti diversi attacchi. Ad esempio, un attacco BGP può deviare il traffico di un indirizzo IP verso l’attaccante anziché il vero proprietario; il DNS spoofing può dirottare il traffico web verso un IP controllato dall’attaccante. Un attacco attivo ai danni di uno degli estremi della comunicazione (sito o CA) può produrre lo stesso risultato.

Ora che abbiamo compreso l’importanza delle CA per la sicurezza di Internet, cosa sappiamo esattamente su di loro? I vendor di browser utilizzano un sistema chiamato Common CA Database (CCADB) per tracciare le CA e i certificati digitali che hanno il potere di emettere certificati per gli utenti finali. Questo database è pubblico e lo abbiamo esaminato recentemente. Ecco cosa è emerso:

• Nel database figurano 94 organizzazioni CA affidate da almeno uno dei quattro grandi vendor (Apple, Google, Microsoft, Mozilla).
• Di queste, 39 sono riconosciute da tutti e quattro i vendor.
• Le 94 organizzazioni sono distribuite in 42 paesi diversi.
• Il gruppo più piccolo di 39 CA è distribuito in 22 paesi diversi.

Da questi dati si deduce un’estesa superficie d’attacco solo per il numero di organizzazioni coinvolte. Per mantenere la sicurezza, tutte devono tutelarsi e non commettere errori operativi. Inoltre, in un mondo di complesse relazioni politiche, avere CA dislocate in tanti paesi apre a rischi teorici e pratici di abusi politici.

Queste debolezze non sono solo teoriche. Tutte si sono verificate in diverse occasioni.

• Nel 2011, la sicurezza della CA DigiNotar è stata completamente compromessa e sono stati emessi centinaia di certificati falsi.
• Nel 2021 è stato scoperto che il dominio .cd aveva un nameserver configurato male, permettendo di reindirizzare il 50% del traffico DNS .cd (sottodomini inclusi).
• Nel 2022, un attacco BGP ai danni di KLAYswap, exchange crypto coreano, ha comportato un furto di 2 milioni di dollari in criptovalute.
• Nel 2023, l’accesso di rete al server "jabber.ru" è stato dirottato, presumibilmente dalla polizia tedesca, permettendo l’emissione di un certificato per decriptare tutto il traffico criptato.
• Nel 2024 si sono scoperte attività di spionaggio del gruppo Salt Typhoon; si ritiene abbia compromesso la connettività di rete di 60 organizzazioni in 80 paesi.
• Nel 2025 la CA Fina è stata scoperta aver emesso dodici certificati per l’indirizzo IP 1.1.1.1 (di proprietà Cloudflare) senza autorizzazione, in un periodo di 16 mesi.

Questi esempi sono solo una selezione rappresentativa. Ogni caso è stato scelto per illustrare un particolare vettore d’attacco. Probabilmente esistono altri episodi simili tuttora non scoperti.

Dopo l’attacco DigiNotar nel 2011, molte proposte sono state avanzate per migliorare la sicurezza delle PKI pubbliche. Quelle che puntavano a cambiamenti sostanziali di emissione dei certificati sono fallite; quelle improntate a miglioramenti incrementali hanno avuto successo, tra cui la Certificate Transparency (CT). Ha sicuramente contribuito il fatto che questa iniziativa sia nata in Google, che ha potuto imporsi grazie a Chrome.

Lo scopo della CT è, come suggerisce il nome, estendere la Web PKI con sistemi che garantiscano completa visibilità sull’emissione dei certificati. Se non si può cambiare il funzionamento fondamentale della fiducia (assenza di controlli tecnici sull’operato delle CA), perlomeno ci si può concentrare sull’osservare ciò che fanno.

Con la CT, la Web PKI viene estesa con i CT log, che fungono da auditor. Prima che un certificato venga emesso, le sue informazioni essenziali devono essere registrate su diversi CT log gestiti in modo indipendente. Ogni CT log, per ogni certificato osservato in emissione, restituisce conferme sotto forma di firme digitali. Come ultimo passaggio, queste firme vengono incorporate nei certificati stessi.

Questo step finale è cruciale: ora che tutti i certificati portano prova della presenza nei CT log, i browser possono estendere la validazione e rifiutare i certificati la cui inclusione non sia dimostrata. Di fatto soltanto i certificati pubblicamente registrati possono essere utilizzati dai siti web.

Nota: Qui la differenza tra Web PKI e Internet PKI conta. Al momento la Certificate Transparency è implementata solo nella Web PKI e applicata dai browser. I certificati senza dati CT sono perfettamente validi altrove, ad esempio per usi Internet PKI, ma non per siti web. Questa situazione potrebbe cambiare in futuro.

Dal 2018 la CT è sostanzialmente obbligatoria. Chrome è stato il primo browser a imporla, e ciò è stato sufficiente grazie alla sua quota di mercato. Apple, Microsoft e Mozilla hanno poi seguito l’esempio. La visibilità acquisita tramite la CT è stata di valore inestimabile perché ha consentito un monitoraggio globale sistemico delle emissioni di certificati, permettendo miglioramenti e ottimizzazioni continui.

Nota: Le specifiche tecniche che regolano l’emissione dei certificati sono gestite dall’ente di settore CA/Browser Forum. Browser e CA collaborano per decidere come si svolge la validazione e l’emissione dei certificati. Ma il rapporto non è paritetico: i browser scelgono quali CA fidarsi, perciò hanno la posizione dominante nei dialoghi.

Come visto, la Certificate Transparency è uno strumento utile per il monitoraggio globale dell’ecosistema, ma offre anche ai proprietari di domini la possibilità di monitorare l’emissione di certificati che riguardano le proprie proprietà. Le debolezze operative delle PKI pubbliche consentono a terzi, malicious o meno, di emettere certificati per domini che non possiedono. Con la CT, chiunque può monitorare i certificati su qualsiasi dominio.

Le organizzazioni preoccupate da attività non autorizzate possono implementare dei CT monitor per analizzare in tempo reale il flusso globale di certificati e individuare quelli a esse riferibili. Questa attività apre due possibilità interessanti:

• I titolari di dominio possono monitorare i propri certificati per comprendere gli enti emittenti e i pattern, nonché capire quali CA vengono utilizzate e da chi.
• Inoltre, è possibile individuare certificati non autorizzati. In altre parole, la CT rende possibile rilevare certificati rilasciati erroneamente.

La Certificate Transparency, per come è oggi implementata, non offre visibilità perfetta sulle emissioni certificate a livello mondiale. Questo perché non tutti i vendor richiedono la pubblicazione CT nelle proprie root store policy. La situazione attuale:

• Apple richiede la CT per tutti i certificati (browser inclusi e qualsiasi codice che usi le librerie ufficiali)
• Chrome di Google la impone per tutti i siti web
• Edge di Microsoft si basa su Chromium e la impone a sua volta
• Firefox di Mozilla la richiede anch’esso

Poiché la CT non è obbligatoria tra i requisiti fondamentali e le root store policy non impongono a tutte le CA di registrare ogni emissione, esistono scappatoie sfruttabili. Quindi, tecnicamente, la pubblicazione CT non è richiesta. Anche se normalmente le CA registrano su CT per default, alcune offrono la possibilità di opt-out. Inoltre, potrebbero essere obbligate legalmente a pubblicare fuori dalla CT.

Evidentemente, questi certificati non saranno validi per siti web, ma possono superare la validazione in diversi casi:

• Richieste API (eccetto dalle piattaforme Apple)
• Comunicazioni server-to-server, ad esempio per email o XMPP

Prevediamo che la copertura CT si estenda in futuro a tutti i certificati pubblici. Nel frattempo, considerate le sue limitazioni e aggiornate i vostri modelli di rischio di conseguenza.

La Certification Authority Authorization (CAA) è uno standard che consente ai proprietari di domini di controllare l’emissione di certificati sulle proprie proprietà. Le policy CAA sono salvate nel Domain Name System (DNS), sfruttando il record CAA. Sono supportate diverse funzionalità:

• Controllo su quali CA possono rilasciare
• Controlli separati per l’emissione di certificati standard, wildcard, oltre che email e BIMI
• Possibilità di comunicare policy molto dettagliate per ogni CA
• Supporto alla comunicazione di recapiti qualora sorgano problemi

Considerate questo 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"

Il controllo CAA è applicato appena prima dell’emissione del certificato. Non è imposto tramite controllo forte, ma tutte le CA sono obbligate a rispettarlo attraverso i requisiti di base del settore. Ogni emissione che non rispetta la policy CAA del titolare è considerata emissione errata.

La funzione chiave di CAA è limitare quali CA possono emettere quali tipi di certificati. In assenza di una policy CAA su un dominio, tutte le CA e tutti i tipi di certificato sono ammessi. Se però vi è almeno una direttiva per un tipo (es. "issue" per cert standard o "issuemail" per S/MIME), solo le CA elencate possono emettere; se invece si trova un semplice punto e virgola, nessuna emissione è permessa.

Analizziamo la configurazione esempio precedente:

• Let's Encrypt può emettere certificati standard
• DigiCert e Sectigo possono emettere certificati wildcard
• Nessuno può rilasciare 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 "issue", sia i certificati standard che wildcard sono ammessi. Se c’è "issuewild", controlla esclusivamente i wildcard.

Il CAA è flessibile nel posizionamento: ogni dominio può avere una configurazione distinta. Inoltre, se una sottodirectory non ha una configurazione CAA, viene usata quella della radice se disponibile.

Nella sezione precedente abbiamo visto la meccanica della restrizione delle CA autorizzate; ma in cosa consiste il vantaggio? Questa attività riduce efficacemente la superficie d’attacco: come visto, esistono molte CA che possono rilasciare certificati per le vostre proprietà, e tutte devono comportarsi correttamente ogni volta.

Nella pratica, la maggior parte delle organizzazioni lavora con poche CA e le altre diventano una potenziale vulnerabilità. Usando il CAA, questa vulnerabilità residua viene minimizzata.

Il metodo raccomandato è questo:

1. Redigere l’elenco esaustivo dei domini posseduti
2. Utilizzare la CT per inventariare tutti i certificati pubblici
3. Monitorare per un periodo la CT e identificare le CA osservate
4. Distribuire una policy CAA che consenta l’emissione solo all’elenco ristretto delle CA rilevate

Questo approccio permette di ridurre i rischi PKI senza rischiare di interrompere i rapporti di emissione già in essere. La policy CAA desiderata deve essere impostata su ogni dominio registrato. A seconda del livello di sicurezza preferito, si può adottare una lista unica di CA per tutte le proprietà o restringere a CA differenti per ogni dominio.

Nota: Il DNS viene spesso usato per delegare controllo parziale a terzi, ad esempio per attivare un servizio gestito sul proprio dominio tramite record CNAME. Impostare una policy CAA sul dominio principale non interrompe l’emissione anche se terzi usano una CA non autorizzata. Questo perché il CNAME delega ogni aspetto del DNS, inclusa la policy CAA. L’unica avvertenza è che il terzo scelto deve essere a conoscenza del CAA ed emettere la propria policy CAA idonea.

Lo standard CAA è un buon punto di partenza ma non basta alle organizzazioni che gestiscono proprietà di alto valore. Un "punto debole" è che il CAA restringe le CA autorizzate ma non può impedire che terzi usino le stesse CA autorizzate per ottenere certificati indesiderati. Il problema è accentuato dal fatto che praticamente tutte le organizzazioni usano Let's Encrypt per certificati gratuiti e automazione, abbassando la barriera di ingresso.

Qui entrano in gioco le estensioni CAA di ACME. ACME, ovvero Automatic Certificate Management Environment, è lo standard industriale per l’emissione automatizzata di certificati, lanciato da Let's Encrypt nel 2015 e oggi adottato da tutte le CA. L’RFC 8657 standardizza due funzionalità che fanno da ponte tra ACME e CAA:

• Limitare i customer account CA autorizzati all’emissione
• Limitare i metodi di validazione ACME utilizzabili

Al momento della stesura, RFC 8657 non è obbligatorio, ma si prevede che venga adottato nel prossimo futuro. Attualmente, Let's Encrypt è l'unica CA che lo supporta ufficialmente. La natura di queste estensioni è tale che, a differenza della CAA di base, non devono essere supportate da tutte le CA per risultare utili. Devono essere supportate solo dalle CA con cui si hanno rapporti commerciali. In caso di dubbi, parlare con la propria CA: alcune dispongono di funzionalità proprietarie che possono essere utilizzate in modo simile.

Con RFC 8657 è possibile consentire l'emissione per un nome di dominio da parte di una CA, ma in modo che nessun altro cliente di quella stessa CA possa emettere per lo stesso nome. Ecco come potrebbe apparire questa configurazione quando si lavora con Let's Encrypt:

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

Per tutto il tempo in cui il frammento di configurazione sopra rimane attivo, solo l'account "1726001367" potrà ottenere certificati da Let's Encrypt per il dominio "example.com". Se è necessario emettere da più account, è possibile configurare più tag CAA, ognuno dei quali consente un account cliente diverso.

L'altra funzionalità di RFC 8657 è il supporto alla limitazione dei metodi di validazione che possono essere utilizzati da ACME prima dell'emissione di un certificato. ACME offre una varietà di metodi e di solito i clienti possono scegliere quello che preferiscono al momento della richiesta di un certificato. Il metodo di validazione più popolare è la prova di proprietà, che richiede che una risposta alla challenge della CA venga pubblicata sul sito web per cui il certificato è richiesto.

Questo approccio è spesso conveniente perché consente a qualsiasi server di comunicare direttamente con una CA e ottenere certificati autonomamente. Tuttavia, dal punto di vista della sicurezza, consentire ai server di ottenere i propri certificati spesso non è l'ideale; chiunque abbia controllo su un server può ottenere certificati per qualunque dominio che punti a quel server.

Un modo per sfruttare una tale disposizione è tramite una errata configurazione DNS pendente. Affinché un nome di dominio funzioni, è necessario apportare modifiche di configurazione in due luoghi. Prima nel DNS, dove i record A e AAAA vengono utilizzati per aggiungere rispettivamente indirizzi IPv4 e IPv6. Poi, un server deve essere configurato su quegli stessi indirizzi IP per fornire risposte. Si crea un problema di DNS pendente quando un server viene dismesso, ma le sue voci DNS restano attive. Immagina che gli indirizzi IP siano forniti da un servizio cloud, come spesso accade. Ora, chiunque ottenga quegli indirizzi IP può ottenere certificati per il dominio DNS pendente. Questo è un esempio; esistono altri vettori di attacco nel DNS che possono portare allo stesso risultato.

Un'organizzazione che desidera prevenire questo tipo di problema può centralizzare l'emissione dei certificati e utilizzare l'opzione di validazione ACME basata su DNS. Tuttavia, affinché ciò sia efficace, occorre assicurarsi che tutti gli altri metodi di validazione vengano disabilitati. Ecco come potrebbe apparire questa configurazione utilizzando RFC 8657:

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

                                  dns-01"

Con questa configurazione, l'emissione dei certificati può essere approvata solo tramite modifiche alla configurazione DNS del nome di dominio per cui vengono richiesti i certificati.

I due metodi di restrizione specificati in RFC 8657 prevedono limitazioni tra loro in parte simili, ma con differenze chiave che possono influenzare quale scegliere e quando.

• La restrizione del metodo di validazione non richiede l'autenticazione della richiesta. Quando l'emissione è limitata a un metodo come "dns-01", solo chi controlla il tuo DNS (o le relative sezioni) può soddisfare la configurazione CAA. Questo riduce la superficie d'attacco, ma in questo caso la richiesta di emissione non è comunque autenticata. Ad esempio, sarebbe ancora possibile sfruttare un'errata configurazione DNS.
• La restrizione sull'account impone una forte autenticazione. Quando l'emissione è limitata a uno specifico account cliente, questo, a sua volta, obbliga a una forte autenticazione della richiesta di emissione prima che qualunque validazione abbia luogo. Con ACME, ad esempio, gli account sono protetti tramite crittografia a chiave pubblica. La prima attività di un client ACME consiste nel creare un'identità crittografica unica, che verrà poi usata in tutte le emissioni. Quando vi è una restrizione per account, l'autenticazione della richiesta è il primo passo dell'interazione ACME, poiché il client deve dimostrare il suo collegamento all'account specificato nella configurazione CAA.

Nota: A giugno 2025, il CA/Browser Forum ha votato per adottare la Ballot SC-085v2, che introduce l'obbligo di validare DNSSEC durante le ricerche CAA e la DCV (domain control validation). Questi cambiamenti diventeranno obbligatori per tutte le CA da marzo 2026. Dopo tale data, i domini con DNSSEC non saranno suscettibili ad alcuna forma di DNS spoofing. 

Le estensioni definite in RFC 8657 permettono di implementare controlli di sicurezza più rigorosi per l'emissione dei certificati, ma farlo non è gratuito. Servono tempo e risorse per ristrutturare e organizzare i processi di emissione in modo compatibile e che al contempo offra una sicurezza superiore. Normalmente non è utile applicare questo approccio a tutti i domini posseduti da un'organizzazione, poiché non sarebbe conveniente. Invece, può essere usato per una piccola quantità di proprietà di alto valore. Per tutto il resto, l'approccio più semplice di limitare l'emissione a poche CA selezionate sarà sufficiente.

Per le tue proprietà di alto valore, considera il seguente approccio:

1. Scegli due o tre CA competenti con cui collaborare. Ne servono almeno due per evitare un singolo punto di errore. Normalmente, per proprietà di alto valore raccomanderei di avere sempre almeno un certificato di backup valido nel caso in cui si verifichino problemi con quello principale. Al minimo, le CA selezionate devono supportare RFC 8567 o possedere funzionalità proprietarie equivalenti.
2. Applica una configurazione CAA rigorosa sul dominio principale che limiti l'emissione solo alle CA selezionate e—cosa essenziale—solo a specifici account all'interno delle CA. Una tale configurazione abiliterà una forte validazione crittografica.
3. Monitora la tua configurazione DNS per a) assicurarti che non ci siano problemi di DNS pendente e b) comprendere se sono presenti deleghe a terze parti tramite CNAME (che potrebbero adottare la propria configurazione CAA superiore).

Come già visto, la Certificate Transparency ha rivoluzionato la possibilità di monitorare le attività delle autorità di certificazione. Tuttavia, il monitoraggio presenta delle sfide:

• È ancora possibile pubblicare certificati pubblici al di fuori di CT, come discusso in una sezione precedente di questo documento.
• Il monitoraggio CT non è ancora diffuso. Nonostante sia obbligatorio da diversi anni, la maggior parte delle organizzazioni non investe ancora risorse adeguate per il monitoraggio dell'emissione di certificati sulle proprie proprietà.
• Distinguere il segnale dal rumore è difficile. I certificati spesso non contengono informazioni sufficienti per distinguere le emissioni regolari da certificati ottenuti fraudolentemente da terzi. Farlo richiede strumenti di monitoraggio avanzati e la maggior parte delle organizzazioni ancora non li conosce.

Anche se l'obiettivo di questo documento è esplorare tutte le possibilità, riconosciamo che molte organizzazioni non hanno bisogno della sicurezza allo stato dell'arte. Anche chi ne ha bisogno, spesso non richiede il massimo livello di sicurezza su tutti i propri domini e siti web.

Ti consigliamo di suddividere il tuo patrimonio in tre gruppi in base al profilo di rischio:

• Rischio molto basso: inserisci in questo gruppo tutti i domini parcheggiati e non utilizzati. A seconda della dimensione dell'organizzazione potresti averne pochi o anche centinaia. A meno che tu non abbia un'automazione eccellente della configurazione DNS ovunque, probabilmente non vale la pena migliorare la sicurezza di questo gruppo. 
• Basso rischio: qui metti tutti i domini su cui hai effettivamente siti web o applicazioni. Dovrebbe essere la scelta predefinita. Per questo gruppo dovresti puntare a una semplice configurazione CAA che limiti l'emissione a poche CA selezionate, come già discusso nel documento. Queste proprietà è improbabile che siano attaccate e la CAA servirà soprattutto a rafforzare la tua policy di selezione CA.
• Alto rischio: in questo gruppo inserisci le proprietà critiche—cioè tutto ciò che ritieni realmente a rischio di attacco. Siti e applicazioni che gestiscono denaro, affari governativi, comunicazioni, e qualsiasi cosa possa essere esposta ad attacchi attivi in rete. Vorrai proteggere questo gruppo con tutte le misure tecniche disponibili.

Il monitoraggio CT ad alta affidabilità è un approccio che consente, con grande sicurezza, di monitorare il flusso di certificati pubblicati nella Certificate Transparency e distinguere i certificati sotto il tuo controllo da quelli sotto controllo di terzi non autorizzati.

Concettualmente, l'approccio è semplice e si basa sul validare ciò che si sa essere legittimo, considerando quindi tutto il resto potenzialmente pericoloso:

1. Mantieni un inventario dei certificati noti sotto il tuo controllo
2. Monitora la Certificate Transparency alla ricerca dei certificati sconosciuti

Tutto qui. Solo due passaggi, anche se il primo potrebbe richiedere parecchio lavoro pratico, a seconda della tua infrastruttura. Ricorda che questo andrà fatto solo per le proprietà ad alto rischio, non ovunque.

• Se usi uno strumento di Certificate Lifecycle Management (CLM) o ACME con una CA commerciale, probabilmente disporrai già di un inventario dei certificati integrato. Non dovrebbe essere troppo difficile esportare i certificati da lì, ma sarà necessario un po' di programmazione sulle loro API.
• Se usi ACME con una CA gratuita (es. Let's Encrypt), potrebbe non esserci un inventario integrato da cui attingere. In questo caso dovrai implementare un meccanismo per raccogliere i certificati emessi e trasferirli in una posizione centrale. Sarà più facile se tutti i certificati sono emessi dallo stesso server, ma non dovrebbe essere troppo complicato neanche in presenza di server multipli.

In pratica, più probabilmente sarà necessario mantenere un database separato in cui memorizzare i propri certificati. Questo perché l'emissione centralizzata è molto rara nella realtà, soprattutto su larga scala. Ci sono sempre situazioni particolari, ad esempio quando alcune parti della PKI pubblica sono delegate a terzi. La soluzione completa dovrà integrare diverse fonti di dati per avere una visione d'insieme.