2026-10-20 · RESEARCH · Il team di Offensive Technology

La regola dei certificati a 200 giorni è già entrata in vigore?

Risposta breve: sì, ma solo esattamente quanto richiesto. Il limite del CA/Browser Forum sulla validità dei certificati TLS pubblici è sceso da 398 giorni a 200 giorni il 15 marzo 2026, sette mesi fa. Abbiamo esaminato la cronologia pubblica di Certificate Transparency di 702 domini principali, 1,359,618 certificati deduplicati registrati dal 2013 a oggi, e abbiamo confrontato la finestra di validità di ciascun certificato prima e dopo tale data. Nei due anni precedenti al passaggio, 75.3% dei certificati avevano già una durata pari o inferiore a 200 giorni. Nei sette mesi successivi, il dato è salito a 99.91%, una conformità praticamente totale. Tuttavia, la vera storia sta in dove si posiziona ciascuna certificate authority sotto questo nuovo massimale. Gli emittenti gratuiti e automatizzati, tra cui Let’s Encrypt e Google Trust Services, si attestano su una mediana di 90 giorni, del tutto invariata rispetto alla regola, poiché erano già anni avanti rispetto ad essa. Le grandi CA commerciali, DigiCert, Amazon, Microsoft, GlobalSign, sono scese da una mediana compresa tra 324 e 397 giorni direttamente a 198 o 199 giorni: il limite inferiore consentito dalla norma, non un giorno di meno. Uno di essi, Sectigo, ha rotto questo schema. Ecco tutti i dati, come li abbiamo misurati e cosa cambierà di nuovo a marzo 2027.

La tabella di marcia, e a che punto siamo

Il ballot SC-081v3, “Introduce Schedule of Reducing Validity and Data Reuse Periods,” è stato approvato dal CA/Browser Forum l'11 aprile 2025: gli emittenti di certificati hanno votato 25-0-5 (cinque astensioni), e il gruppo dei browser, Apple, Google, Microsoft e Mozilla, ha votato a favore per 4-0-0. È stato proposto da Apple. Stabilisce una riduzione graduale del periodo massimo di validità per i certificati TLS pubblici e una riduzione parallela, ancora più marcata, del periodo in cui una CA può riutilizzare una precedente domain-control validation:

• Fino al 14 marzo 2026: validità massima di 398 giorni, riutilizzo della validazione per 398 giorni.
• 15 marzo 2026: validità massima di 200 giorni, riutilizzo della validazione per 200 giorni. Questa fase è già avvenuta.
• 15 marzo 2027: validità massima di 100 giorni, riutilizzo della validazione per 100 giorni.
• 15 marzo 2029: validità massima di 47 giorni, riutilizzo della validazione per 10 giorni.

A oggi, il passaggio ai 200 giorni risale a sette mesi fa, quello ai 100 giorni dista circa cinque mesi e quello ai 47 giorni è a circa due anni e mezzo di distanza. Questo articolo si concentra su cosa abbia effettivamente cambiato la prima fase, non sulla tabella di marcia in sé: la knowledge base di ogni registrar e CA spiega già le date. Volevamo sapere se le emissioni sul campo siano cambiate quando la regola imponeva che lo facessero, e avevamo a disposizione tredici anni di nostri dati CT passivi da verificare.

Due livelli, un'unica scadenza

Guardiamo prima il quadro generale. Considerando complessivamente tutti gli emittenti, la quota di certificati appena emessi con durata pari o inferiore a 200 giorni è passata dal 75.3% nei due anni precedenti al limite al 99.91% nei sette mesi successivi. Si tratta di un allineamento alla conformità quasi universale, esattamente ciò che una scadenza rigida dei Baseline Requirements dovrebbe produrre: se non la rispetti, un browser smette di fidarsi del tuo certificato. Questa parte ha funzionato come previsto.

Analizzando più a fondo, l'ecosistema si divide in due gruppi che non si sono mossi nello stesso modo, o non si sono mossi affatto:

• Già allineati. Let’s Encrypt e Google Trust Services, i due emittenti con il volume più elevato nel nostro campione con ampio margine, utilizzano un'impostazione predefinita di 90 giorni da molto prima dell'introduzione di questa regola, poiché la loro emissione è gratuita, automatizzata e concepita fin dal primo giorno attorno a rinnovi frequenti. La loro mediana post-mandato è di 90 giorni. La loro mediana pre-mandato era di 90 giorni. Anche i certificati emessi tramite ACME da Apple e dalla più recente CA Certainly, orientata all'automazione, mostrano lo stesso andamento, rispettivamente a 86 e 30 giorni, invariati lungo tutto il passaggio. Per questo gruppo, il 15 marzo 2026 non ha cambiato nulla, perché la regola ha semplicemente raggiunto la posizione in cui si trovavano già.
• Posizionati esattamente sul limite. DigiCert, Amazon, Microsoft e GlobalSign sono scese tutte bruscamente, ma ciascuna di esse si è attestata a 198 o 199 giorni, un giorno sotto il nuovo tetto di 200 giorni, senza scendere in modo significativo al di sotto. Prima del limite, il loro certificato tipico durava tra 180 e 397 giorni. Dopo di esso, tutte e quattro convergono a un solo giorno di distanza dal massimo consentito. Questa è la conformità alla lettera di una regola che era stata esplicitamente concepita per spingere il settore verso certificati con cicli di vita più brevi, senza però accoglierne lo spirito.

Sectigo è l'unico emittente nel nostro campione che non rientra chiaramente in nessuno dei due modelli. La sua mediana pre-mandato era di 366 giorni, pienamente nel campo legacy, ma la sua mediana post-mandato è scesa a 90.4 giorni, con il 55.6% dei suoi certificati post-mandato già a 90 giorni o meno. Si tratta di un reale cambiamento verso il comportamento del gruppo automatizzato, non di un semplice adeguamento al nuovo tetto. Non possiamo determinarne la ragione basandoci sui soli metadati CT; il dato è coerente con un cambiamento nella pipeline di emissione o nell'integrazione ACME utilizzata dai clienti Sectigo nel nostro campione, ma non possiamo confermare il meccanismo.

Microsoft merita una nota a parte perché, sulla carta, il suo dato si è mosso nella direzione opposta: una mediana pre-mandato di 180 giorni salita a 198 giorni post-mandato. Interpretiamo questo dato come indicazione che Microsoft operasse già con durate inferiori rispetto al vecchio limite di 398 giorni, per poi riposizionarsi appena sotto la nuova soglia dei 200 giorni, adottando lo stesso comportamento di aderenza al limite delle altre CA enterprise, partendo semplicemente da una baseline leggermente più bassa. Ciò non dimostra che i certificati di Microsoft siano diventati meno sicuri; il periodo di validità e la postura di sicurezza non sono la stessa cosa, tema che approfondiremo nella sezione successiva.

Chi, numeri alla mano

Ciascun emittente sopra indicato ha rispettato il limite dei 200 giorni su quasi il 100% dei propri certificati post-mandato nel nostro campione; non abbiamo riscontrato violazioni dei Baseline Requirements, esattamente quanto ci si aspetterebbe da root program che eseguono audit attivi a tale scopo. La conclusione non riguarda una mancata conformità. Riguarda il fatto che la conformità assume due forme distinte, e il divario tra “automatizzato, già breve” ed “enterprise, ora attestato sul limite” è ancora di circa un fattore due in termini di giorni effettivi, da 90 a 198, all'interno di una singola regola soddisfatta equamente da entrambi i gruppi.

Come abbiamo effettuato la misurazione

Uno scettico dovrebbe poter replicare questa analisi da zero.

• La popolazione analizzata. Le cronologie Certificate Transparency degli stessi circa 700 domini principali Tranco, lette tramite crt.sh, che abbiamo riutilizzato per il nostro censimento dei ritardi di registrazione CT e per il nostro censimento sui leak di hostname interni. Non abbiamo generato alcuna nuova richiesta di rete per questo articolo; l'intero dataset era già presente in cache dal lavoro precedente.
• La metrica. Per ciascun certificato deduplicato e registrato, il periodo di validità è not_after meno not_before, arrotondato al giorno intero più vicino prima della suddivisione in bucket, poiché un certificato nominalmente da “90 giorni” dura spesso 90 giorni più qualche ora di scostamento grezzo del timestamp legata all'ora di emissione.
• La suddivisione. Abbiamo suddiviso i certificati a seconda che not_before cadesse prima o a partire dal 15 marzo 2026. Per il confronto tra singoli emittenti, abbiamo utilizzato una finestra di due anni direttamente precedente al passaggio (dal 15 marzo 2024 al 14 marzo 2026) anziché l'intera cronologia storica, per evitare che certificati legacy risalenti a un decennio prima penalizzassero ingiustamente il valore “prima” di una CA.
• Cosa non abbiamo fatto. Non abbiamo mai richiesto un certificato, effettuato connessioni a server web o scansionato nulla. La lettura di un log CT pubblico è una consultazione, non una scansione attiva.
• Cosa abbiamo conservato. Conteggi aggregati, mediane e percentili per emittente e per periodo. Nessun nome di dominio o sottodominio è presente nell'output.

Cosa questo non dimostra

Limiti oggettivi, perché un dato senza i suoi caveat è solo marketing.

• Una validità più breve del certificato non equivale a una vita più breve della chiave privata. Una CA o un subscriber possono rinnovare indefinitamente un certificato sulla stessa coppia di chiavi ogni 90 o 200 giorni; i metadati di base delle voci di crt.sh non espongono l'impronta della chiave pubblica del subject, quindi non possiamo determinare da questi dati se il materiale crittografico della chiave venga effettivamente ruotato insieme al certificato. Il vantaggio in termini di sicurezza offerto da una validità più breve dipende proprio da questa rotazione; in questo studio non l'abbiamo misurata.
• Sette mesi di dati post-mandato rappresentano una lettura preliminare. È sufficiente per evidenziare la forma della risposta iniziale di conformità, ma non per certificarla come equilibrio definitivo del settore sotto il tetto dei 200 giorni. Prevediamo di riverificare questi dati al passaggio successivo, a marzo 2027.
• Non tutti gli emittenti offrono un quadro prima e dopo affidabile. Diverse CA nella nostra cache, tra cui GoDaddy e vari emittenti minori o regionali, avevano un campione post-mandato troppo ridotto nel nostro panel di 700 domini per poter essere riportate con certezza; abbiamo inserito in tabella solo gli emittenti con un campione consistente per entrambi i periodi.
• Il campione analizzato è sbilanciato verso domini ad alto traffico. I livelli più alti dell'elenco Tranco si basano su organizzazioni con ampie risorse e importanti CDN. I comportamenti di emissione per la coda lunga dei siti più piccoli, spesso attestati sulle stesse grandi CA tramite strumenti di automazione differenti, potrebbero variare.
• Questa misurazione riguarda le certificate authority, non direttamente il rischio per l'attaccante. Un limite più breve riduce la finestra massima in cui un certificato rimane valido in caso di problemi, ma si tratta solo di uno dei fattori all'interno di una catena più ampia che comprende revoca, igiene delle chiavi e monitoraggio.

Perché è importante

L'intero fondamento della riduzione della durata dei certificati risiede nella finestra di esposizione: un certificato compromesso o emesso in modo errato che secondo la vecchia regola sarebbe rimasto valido per 398 giorni, ora dura al massimo 200 giorni, e durerà al massimo 100 e poi 47 giorni con il procedere della tabella di marcia. Questo ragionamento è efficace solo se l'ecosistema si sposta realmente verso durate più brevi, e non si limita ad attestarsi appena sotto la soglia di volta in volta legale. A sette mesi dall'entrata in vigore, i dati mostrano che entrambe le tendenze coesistono. La regola ha svolto il proprio compito di limite rigido: la conformità è passata da tre quarti alla totalità dei certificati, da un giorno all'altro per gli standard del settore. Tuttavia, la maggior parte dei volumi che si sono adeguati lo ha fatto solo nella misura minima richiesta dal nuovo limite, attestandosi a un giorno da quota 200 anziché avvicinarsi a 90. Gli emittenti che già operavano con durate brevi, quelli il cui modello operativo dipende da rinnovi economici, frequenti e automatizzati, non ne sono stati influenzati, perché avevano predisposto le loro infrastrutture anni prima che una votazione del Forum lo rendesse obbligatorio. È lo stesso schema che abbiamo riscontrato esaminando la rapidità con cui i certificati vengono registrati in CT: le componenti di questo ecosistema sottoposte a enforcement effettivo si muovono esattamente alla velocità richiesta dai controlli, non un attimo prima.

La regola dei certificati a 200 giorni è entrata in vigore: risposte rapide

Quando è entrata in vigore la regola dei certificati a 200 giorni?

Il 15 marzo 2026, in base al ballot SC-081v3 del CA/Browser Forum, approvato l'11 aprile 2025. Ha ridotto la validità massima dei certificati TLS pubblici da 398 a 200 giorni. La riduzione successiva, a 100 giorni, scatterà il 15 marzo 2027; l'ultima riduzione a 47 giorni entrerà in vigore il 15 marzo 2029.

I certificati esistenti devono essere riemessi con il nuovo limite?

No. Il limite si applica solo ai certificati emessi a partire dalla data di entrata in vigore. Un certificato emesso secondo la vecchia regola dei 398 giorni prosegue secondo la sua pianificazione originale.

Anche il periodo di riutilizzo della domain validation diventerà più breve?

Sì, secondo la stessa tabella di marcia: da 398 a 200 giorni in concomitanza con la fase di marzo 2026, poi 100 giorni a marzo 2027 e 10 giorni entro marzo 2029, imponendo una riverifica più frequente del controllo del dominio indipendentemente dalla validità del certificato stesso.

Quando entrerà in vigore la regola dei certificati a 47 giorni?

Il 15 marzo 2029, l'ultima fase della tabella di marcia SC-081v3: 398 giorni fino al 14 marzo 2026, 200 giorni dal 15 marzo 2026, 100 giorni dal 15 marzo 2027, 47 giorni dal 15 marzo 2029.

Come è stata condotta questa misurazione?

In modo passivo. Abbiamo esaminato la cronologia CT pubblica, tramite crt.sh, di circa 700 domini inclusi nella top 1,000 di Tranco, calcolando il periodo di validità di ciascun certificato come NotAfter meno NotBefore. Nessun host è stato contattato, risolto o scansionato. Il risultato consiste in 1,359,618 voci di log deduplicate dal 2013 a ottobre 2026.

Articoli correlati

• Ritardi nei log di Certificate Transparency: cosa mostrano 1.3M di certificati.
• Come i log di Certificate Transparency espongono i sottodomini interni.
• Cosa dimostrano i certificati.