Ritardo dei log di Certificate Transparency: cosa mostrano 1.3M di certificati
Risposta breve: Abbiamo analizzato lo storico pubblico di Certificate Transparency (CT) di circa 700 domini ad alto traffico e confrontato l'inizio di validità dichiarato di ciascun certificato (NotBefore) con il momento in cui è effettivamente apparso in un log CT. Su 1.29 milioni di certificati registrati dal 2013 a metà 2026, il 19.6% ha impiegato più di due giorni interi per apparire in CT e il 15.0% ha impiegato più di una settimana. Abbiamo poi suddiviso i dati al 15 giugno 2026, data in cui il Root Program di Chrome ha iniziato a richiedere che il certificato finale emesso, e non solo il precertificato, contenesse un record di log CT valido. Dopo tale data, la quota oltre le 48 ore scende a 1.7% e la quota oltre la settimana scende a 0.8%, nella stessa popolazione, misurata nello stesso modo. Il certificato mediano era già rapido prima del mandato; ciò che è cambiato è la coda, ovvero i certificati che rimanevano non registrati per giorni, settimane o mesi. Ogni dato qui riportato proviene da una lettura passiva di un log pubblico. Nessun host è stato contattato, nulla è stato scansionato. Ecco esattamente come lo abbiamo misurato, quali emittenti hanno colmato il divario più rapidamente e cosa questo dimostra e non dimostra.
Due numeri, un cambio di policy
Certificate Transparency è stata creata per rendere l'emissione dei certificati un registro pubblico di tipo append-only: ogni CA pubblicamente attendibile registra i certificati che emette, consentendo a chiunque, proprietario di un dominio, browser o ricercatore, di vedere cosa è stato emesso per un dato nome. Il problema è sempre stato legato al termine "prima o poi". A una CA è stato richiesto di registrare un precertificato e incorporare i relativi timestamp firmati prima di emettere il certificato finale fin dal 2018, e un Maximum Merge Delay standard di settore delimita il tempo massimo entro cui un log deve incorporare un precertificato inviato, in genere circa 24 ore. Ma fino a quest'anno, non esisteva alcuna scadenza equivalente per la registrazione del certificato finale vero e proprio. Un certificato poteva essere firmato, datato e già in produzione mentre la relativa voce di log rimaneva indietro di giorni, settimane o, in almeno un caso segnalato in modo indipendente, mesi.
Osservate attentamente la mediana: si è mossa a malapena, da 1.0 ora prima del mandato a 0.975 ore dopo. Non si tratta di un errore nei dati, è la forma reale della distribuzione. La maggior parte dei certificati, della maggior parte degli emittenti, veniva già registrata entro un'ora molto prima che esistesse qualsiasi mandato. Ciò che il mandato ha visibilmente colmato è la coda: la minoranza di certificati che rimaneva per giorni o settimane senza alcun record di log pubblico. Il ritardo medio racconta questa storia in modo più netto, scendendo da circa 64 giorni prima del cutoff a 6.7 ore dopo, poiché la media viene trascinata esattamente da quegli outlier che la mediana nasconde.
Il meccanismo: una scadenza per i precertificati, e nessuna scadenza per il resto
Il design originale di Certificate Transparency prevede la registrazione di un precertificato, un segnaposto con poison extension che consente a una CA di raccogliere i Signed Certificate Timestamps prima di firmare il certificato reale. Diversi log CT pubblici devono accettare e incorporare tale precertificato entro un Maximum Merge Delay vincolato, nell'ordine di un giorno, e i browser impongono ai log di rispettarlo fin dal 2018. Quella parte della pipeline è sempre stata tempestiva, motivo per cui il settore poteva considerare ampiamente vera l'affermazione "CT è obbligatoria".
La lacuna riguardava l'altra metà: nulla obbligava la CA a inviare a un log il certificato finale, emesso secondo una tempistica precisa. Una CA poteva ottenere i propri SCT dal precertificato, incorporarli, emettere il certificato e metterlo in produzione, il tutto correttamente, mentre la voce di log CT del certificato finale rimaneva in attesa. Un caso segnalato in modo indipendente descrive un certificato wildcard emesso da DigiCert per un'importante piattaforma con un divario di circa tre mesi tra l'emissione dichiarata e la comparsa in CT (non abbiamo verificato in modo indipendente questo caso specifico; consideratelo un aneddoto illustrativo, non autorevole). I nostri dati mostrano lo stesso andamento su scala aggregata: prima del mandato, una quota significativa di certificati di diverse grandi CA rimaneva per più di una settimana senza alcun record di log pubblico, esattamente la scappatoia a cui punta la policy di Chrome di giugno 2026 richiedendo che il certificato finale stesso contenga un record di log valido.
Quali emittenti hanno colmato il divario, e di quanto
Qui nominiamo le Certificate Authority, non i domini di cui abbiamo conteggiato i certificati. La prassi di logging di una CA è un'informazione di pubblico interesse riguardante la CA stessa, allo stesso modo in cui un nostro precedente studio analizzava quali CA vengono autorizzate dai domini a emettere per loro conto. Per ogni emittente con un campione concreto da entrambi i lati del cutoff, ecco la percentuale di certificati registrati più di 48 ore dopo NotBefore, prima e dopo il 15 giugno 2026:
| Emittente | Prima (n) | Prima | Dopo (n) | Dopo |
|---|---|---|---|---|
| DigiCert Inc | 160,949 | 27.9% | 290 | 6.2% |
| Amazon | 95,508 | 20.0% | 863 | 2.9% |
| Google Trust Services | 66,473 | 10.3% | 2,249 | 3.1% |
| Sectigo Limited | 24,430 | 0.02% | 60 | 0.0% |
| Let’s Encrypt | 532,280 | 0.06% | 5,523 | 0.0% |
Due elementi risaltano. Primo, Let’s Encrypt e Sectigo erano già vicini allo zero prima dell'introduzione del mandato, coerentemente con la gestione di pipeline di emissione su larga scala e fortemente automatizzate, in cui "emetti e registra" è quasi un'unica operazione atomica. Secondo, le CA che avevano i margini di miglioramento maggiori, DigiCert, Amazon e Google Trust Services, sono migliorate nettamente, riducendo la quota di registrazioni tardive di circa quattro-sette volte. Non è stato possibile costruire una riga prima/dopo affidabile per ogni emittente: GlobalSign, il marchio legacy di COMODO e ZeroSSL avevano troppo pochi certificati post-mandato nel nostro campione per essere inclusi (meno di qualche decina) oppure nessuno dei domini monitorati ha rinnovato con loro dopo il 15 giugno 2026. Si tratta di un limite del nostro campione di domini, non di una constatazione su quegli emittenti.
Come lo abbiamo misurato
Chiunque abbia un approccio scettico dovrebbe poter ricostruire il processo da zero, quindi ecco l'intera metodologia senza nulla di nascosto.
- La popolazione. Circa 700 domini dalla top Tranco 1,000, raccolti attraverso diversi dei nostri recenti studi su DNS passivo. Per ogni dominio abbiamo analizzato l'intero storico di Certificate Transparency su crt.sh, che restituisce ogni certificato registrato per quel dominio e i suoi sottodomini, a partire dal 2013.
- La metrica. Per ogni certificato registrato, abbiamo confrontato il campo
not_before(l'inizio di validità dichiarato del certificato) conentry_timestamp(il momento in cui crt.sh ha registrato la voce di log). La differenza rappresenta il ritardo che riportiamo. Abbiamo deduplicato in base all'ID voce interno di crt.sh e scartato una manciata di voci con un divario non plausibile (superiore a cinque anni), interpretate come artefatti di clock o di parsing piuttosto che come reale comportamento di emissione. - La suddivisione. Abbiamo raggruppato ogni certificato a seconda che il relativo NotBefore cadesse prima oppure a partire dal 15 giugno 2026, data di entrata in vigore del requisito del Root Program di Chrome secondo cui il certificato finale emesso deve contenere un record di log CT valido. I nostri dati in cache arrivano fino al 24 luglio 2026, quindi la finestra post-mandato corrisponde a circa le prime sei settimane con la nuova regola, non a un anno intero; considerate i dati post-mandato come una rilevazione preliminare che prevediamo di consolidare, non come un trend consolidato.
- Cosa non abbiamo fatto. Non abbiamo mai richiesto un certificato, effettuato connessioni a server web né scansionato nulla. La lettura di un log CT pubblico è una consultazione, non una scansione attiva, lo stesso principio che guida ogni nostro incarico.
- Cosa abbiamo conservato. Conteggi aggregati, mediane e percentili, per emittente e per periodo. Nessun nome di dominio o sottodominio è presente nell'output e non abbiamo raccolto dati personali; i nomi di dominio e i metadati pubblici dei certificati non sono dati personali.
Cosa questo non dimostra
Limiti oggettivi, perché un numero privo di precisazioni è solo marketing.
- La finestra post-mandato è breve. Sei settimane di dati sono sufficienti a mostrare la forma del cambiamento, non a certificarlo come permanente. Parte del miglioramento potrebbe riflettere una conformità iniziale scrupolosa che potrebbe allentarsi nel tempo; prevediamo di verificare nuovamente questo aspetto.
- Non tutti gli emittenti hanno un quadro post-mandato affidabile. Alcune grandi CA avevano semplicemente troppo pochi certificati post-mandato nel nostro campione specifico di 700 domini per poter stilare un report affidabile. Un campione di domini più ampio colmerà questo aspetto.
- NotBefore non è un indicatore perfetto del momento in cui "il certificato è stato effettivamente firmato". Una CA può impostare NotBefore leggermente nel passato per tollerare il clock skew. Questa pratica aumenterebbe leggermente il nostro valore di ritardo anche per una CA che registra tempestivamente; tuttavia, non spiega divari misurati in giorni o settimane.
- Si tratta di una misurazione del ritardo, non di una constatazione di errata emissione. Un certificato registrato in ritardo non è una prova di emissione errata, ma solo del fatto che l'audit trail pubblico è rimasto indietro rispetto al suo utilizzo. Il rischio risiede proprio in questa lacuna di visibilità: per tutto il tempo in cui un certificato non viene registrato, chiunque monitori CT per il proprio dominio non sarà in grado di vederlo.
- La popolazione è sbilanciata verso domini ad alto traffico. La top 1,000 di Tranco si concentra su organizzazioni dotate di ampie risorse e importanti CDN; il comportamento di emissione per la lunga coda di siti più piccoli, che spesso utilizzano le stesse grandi CA ma tramite diverse automazioni, potrebbe differire.
Perché questo è importante
L'intera proposta di valore di Certificate Transparency per il proprietario di un dominio risiede nella possibilità di monitorare il log pubblico per il proprio nome e individuare un certificato inatteso prima che venga utilizzato a proprio danno. Questo funziona solo se la registrazione avviene a ridosso dell'emissione. Un certificato che rimane non registrato per un mese è un certificato che è stato attivo, ritenuto attendibile da ogni browser e invisibile a chiunque monitorasse CT esattamente per quel periodo. Il divario colmato da questo mandato non è insolito; è la semplice differenza tra "siamo tecnicamente conformi a Certificate Transparency" e "è possibile vedere effettivamente ciò che abbiamo emesso, tempestivamente, ogni volta". I dati dimostrano che gli emittenti più rapidi del settore, tra cui Let’s Encrypt e Sectigo, trattavano già questa procedura come una singola operazione atomica ben prima che qualsiasi policy lo imponesse. Gli altri stanno visibilmente recuperando terreno ora che il Root Program di Chrome lo ha reso un requisito obbligatorio anziché una best practice, esattamente la stessa dinamica riscontrata quando abbiamo analizzato chi fa effettivamente da witness per i log CT di produzione: le parti di questo ecosistema in cui le regole vengono applicate rigorosamente si muovono rapidamente, mentre quelle semplicemente incoraggiate no.
Ritardo dei log di Certificate Transparency: risposte rapide
Cos'è il ritardo dei log di Certificate Transparency?
Il divario tra l'inizio di validità dichiarato di un certificato TLS (NotBefore) e il momento in cui appare effettivamente in un log CT pubblico. Un intervallo breve indica che l'audit trail pubblico tiene il passo con l'emissione; un intervallo lungo indica che un certificato valido e utilizzabile è esistito per un certo periodo senza alcuna traccia pubblica.
Chrome richiede che tutti i certificati siano registrati in CT?
La policy del Root Program di Chrome richiede che il certificato finale emesso, e non solo il precertificato, contenga un record di log CT valido per i certificati emessi a partire dal 15 giugno 2026; i certificati emessi dopo tale data senza tale record non sono considerati attendibili da Chrome. La registrazione del precertificato era già obbligatoria dal 2018.
Perché un certificato poteva essere valido prima di essere registrato?
CT richiede la registrazione di un precertificato prima dell'emissione del certificato finale, e le regole del Maximum Merge Delay (circa 24 ore) ne delimitano i tempi. Fino alla policy di Chrome di giugno 2026, non esisteva alcuna scadenza equivalente per la registrazione del certificato finale stesso, quindi poteva essere firmato, datato e utilizzato mentre la relativa voce di log rimaneva indietro, a volte di mesi.
Come è stato misurato?
In modo passivo. Abbiamo analizzato lo storico pubblico di CT, tramite crt.sh, di circa 700 domini della top 1,000 di Tranco, confrontando il campo NotBefore di ciascun certificato con il timestamp della voce di log. Nessun host è stato contattato, risolto o scansionato. Il risultato comprende 1.29 milioni di voci di log dal 2013 a metà 2026, suddivise alla data del mandato del 15 giugno 2026.