Verificare i certificati TLS con Certificate Transparency: log, emittenti e ambito

La validità è più di una semplice data di scadenza

Chi verifica la validità di un certificato si concentra rapidamente sulla data di scadenza e sulla firma. Per accertare se l'emissione sia stata registrata in modo tracciabile e verificabile, entrano in gioco tre assi: il registro in cui l'emissione è annotata; l'emittente, ovvero l'autorità di certificazione che ha apposto la firma; e l'ambito, ossia i nomi di dominio coperti, la durata e lo scopo d'uso.

Per i certificati TLS sul Web, Certificate Transparency (CT) funge da registro. CT registra e monitora l'emissione dei certificati TLS, consentendo a chiunque di verificarne l'avvenuta emissione. Questa registrazione non è un dettaglio marginale: Chrome accetta esclusivamente i certificati registrati in un log CT.

I tre assi hanno portata diversa. La voce nel registro attesta la sottomissione, non l'esercizio effettivo. L'emittente chiarisce se l'ente previsto ha effettivamente rilasciato il certificato. L'ambito definisce se nomi, durata e scopo corrispondono all'utilizzo previsto. I paragrafi seguenti li trattano in quest'ordine.

Certificate Transparency: il registro pubblico per i certificati TLS

Elemento centrale sono i log pubblici di Certificate Transparency, gestiti da organizzazioni come Google, Cloudflare o da autorità di certificazione commerciali. Durante la creazione di un certificato, viene solitamente scritto in uno di questi log un precertificato contenente tutti i dati rilevanti, rendendolo pubblicamente consultabile. I log sono pubblicamente accessibili e strutturati tramite hash concatenati (alberi di Merkle), il che li protegge dalle manipolazioni. Poiché le voci sono visibili a terzi indipendenti, un'emissione non può essere modificata successivamente senza lasciare traccia.

La prova che un certificato sia stato sottomesso a un log risiede nel certificato stesso: tramite il campo della firma è possibile verificare se la sottomissione è avvenuta. Il campo contiene il Signed Certificate Timestamp (SCT), la conferma del log sull'avvenuta ricezione. Uno strumento di verifica legge l'SCT e lo confronta con il log.

In pratica, questo significa che un certificato privo di un SCT valido proveniente da un log autorevole non è utilizzabile nei browser che impongono CT, anche se firma e periodo di validità sono corretti. Oggi si può presumere che praticamente ogni certificato server emesso a livello mondiale con ancoraggio nei browser compaia nei log.

Quali log contano – e quando un SCT non prova nulla

Non esiste un unico registro, ma un panorama di log concorrenti e complementari. Let's Encrypt invia tutti i certificati emessi ai log CT e gestisce direttamente due log pubblici denominati Oak e Sapling. Oak è integrato nei programmi CT di Apple e Google, e l'ambiente ACME di produzione di Let's Encrypt vi trasmette i certificati. Ciò che conta non è un log qualsiasi, bensì uno accettato dal rispettivo browser: in un contributo del 2021, la DFN-PKI elencava 30 log accettati da Chrome.

Oltre ai log di produzione esistono log di test, i cui SCT non hanno lo stesso valore. Let's Encrypt sottolinea che gli SCT provenienti da questi log di test non devono essere inseriti in certificati pubblicamente attendibili. Sapling riceve certificati sia dall'ambiente ACME di produzione sia da quello di staging, ma l'ambiente di produzione non utilizza gli SCT risultanti; Sapling può essere utilizzato da altre autorità di certificazione a fini di test. Lo stesso vale per i log basati su Sunlight testati da Let's Encrypt. Twig rimane come log di test e accetta le stesse CA di Sapling. Willow e Sycamore accettano le stesse CA di Oak e dovrebbero diventare log di produzione.

Ne consegue, per la verifica, che un SCT da solo non attesta che un certificato sia pubblicamente attendibile – potrebbe provenire da un log di test. È necessario verificare se il log figura nell'elenco attualmente accettato. I cicli di vita dei log cambiano; Let's Encrypt rimanda a una propria panoramica per informazioni sul ciclo di vita dei suoi log. Chi definisce regole di verifica dovrebbe aggiornare periodicamente l'elenco accettato, invece di utilizzare una lista copiata una tantum.

Log di produzione o di test: non tutti gli SCT hanno lo stesso valore

Interrogare invece di leggere autonomamente

Per verifiche puntuali basta un aggregatore. crt.sh interroga continuamente tutti i log CT rilevanti e prepara i dati in formato facilmente fruibile; il servizio è gestito da Sectigo, un fornitore di CA. crt.sh offre una semplice API per ottenere i certificati emessi per un dominio e fornisce i risultati, su richiesta, in formato JSON. Altre offerte che interrogano ed elaborano i log CT provengono da Censys.io, Cloudflare, sslmate, Google e Facebook, in parte a pagamento.

Chi non vuole affidarsi a servizi esterni può esaminare direttamente i log. Con certspotter è disponibile software pronto per l'auto-gestione.

L'auto-gestione richiede tuttavia concetto e risorse. Data la quantità di certificati server emessi a livello mondiale, il fabbisogno, specialmente di banda, può essere considerevole. Alcuni log crescono di diverse centinaia di certificati al secondo, ma talvolta non erogano i dati alla stessa velocità, rendendo in parte impossibile monitorare continuamente i certificati presenti nel log. Anche gli aggregatori hanno limiti: crt.sh segnala limitazioni nella dimensione dei risultati. Per una query singola basta un aggregatore; per un esercizio continuativo su molti domini serve un'architettura propria e sufficiente capacità di trasmissione.

Tenere sotto controllo il proprio dominio

Il registro può essere utilizzato dalla propria organizzazione. Serve come ulteriore base dati per la gestione interna dei certificati e per individuare rapidamente certificati emessi erroneamente o fraudolentemente.

Inoltre, funge da monitoraggio centrale sulle CA impiegate nell'organizzazione. Aiuta a identificare certificati aggiuntivi legati a servizi CDN o cloud.

Proprio quest'ultimo punto è pratico: i certificati che arrivano tramite un servizio a monte spesso non compaiono nel proprio inventario, ma sì nel log.

La DFN-PKI utilizza questo sistema dal 2018. Poiché praticamente ogni certificato server emesso a livello mondiale con ancoraggio nei browser compare nei log, la copertura per i certificati pubblicamente attendibili è elevata.

L'individuazione di certificati emessi erroneamente è subordinata a una condizione: i meccanismi della CA per la scrittura nei log CT devono essere intatti, cioè non devono essere stati aggirati dall'attaccante. Se questa premessa è soddisfatta, l'interrogazione continua dei log relativi ai propri domini fornisce un segnale di allarme precoce, indipendente dalla comunicazione propria della CA.

Ambito: cosa la verifica non copre

I certificati delle CA interne, che non risultano attendibili per impostazione predefinita nel browser o nel sistema operativo, non sono registrati da Certificate Transparency. Per tali certificati – ad esempio all'interno di un'organizzazione, tra sistemi o in una PKI propria – il registro non fornisce alcuna prova; lì servono percorsi di verifica propri, come una panoramica delle emissioni e una lista di attendibilità interna.

Una voce valida nel log attesta la sottomissione del certificato, non il suo impiego. Non se ne può dedurre se il certificato venga effettivamente servito su un server, se la chiave privata corrisponda e se la configurazione sia corretta. A queste domande risponde solo la propria gestione operativa – tramite un inventario dei certificati utilizzati e un controllo della configurazione del server.

Anche l'affermazione del certificato stesso è limitata: i certificati garantiscono generalmente di comunicare con un determinato dominio, ma non con l'azienda o l'organizzazione corretta. Un certificato può essere falsificato e il server può spacciarsi per qualcuno che non è. CT rende più riconoscibili i certificati falsi o fraudolenti, ma non sostituisce la verifica dell'organizzazione dietro un dominio.

È necessario un controllo aggiuntivo per i certificati delle CA interne, per quelli di cui si vuole attestare l'effettivo impiego e ogni volta che l'indicazione del dominio non basta per la transazione commerciale. In questi casi si aggiungono prove esterne al registro, raccolte direttamente presso l'emittente o nella propria gestione operativa.

Tre passi di verifica che devono coincidere

Primo passo: verificare la voce nel registro. L'SCT nel campo della firma deve provenire da un log accettato dal browser – non da un log di test come Sapling, Twig o un log basato su Sunlight. Secondo passo: verificare l'emittente. L'autorità di certificazione firmataria deve essere quella prevista; emittenti inattese per i propri domini sono un segnale d'allarme. Terzo passo: verificare l'ambito. I nomi di dominio coperti, la durata e lo scopo d'uso devono corrispondere all'impiego previsto.

Questa sequenza può essere integrata come routine ricorrente nella gestione esistente dei certificati: l'interrogazione del registro per i propri domini in continuo, la verifica dell'emittente e dell'ambito ad ogni nuova emissione e ad ogni inventario. Puntualmente basta un'interrogazione presso un aggregatore come crt.sh; per l'esercizio continuativo serve una soluzione propria con banda sufficiente. Entrambe le vie forniscono lo stesso risultato: una voce nel registro che, insieme all'emittente e all'ambito, attesta la validità.