Durata dei certificati TLS: da 5 anni a 47 giorni, 2011-2026

I certificati TLS attendibili dai browser duravano cinque anni. Oggi durano 90 giorni. Entro il 2029 il voto del CA/Browser Forum di marzo 2025 li comprimerà a 47 giorni. La traiettoria di 15 anni è il cambiamento più significativo nella sicurezza operativa del web — trasformando la gestione dei certificati da un compito amministrativo ogni pochi anni in una pipeline completamente automatizzata. Il rinnovo manuale non è più una pratica valida.

I numeri principali

Durata massima consentita per i certificati TLS pubblicamente affidabili nei programmi root del browser:

Nota: i certificati emessi da Let’s Encrypt sono a 90 giorni fin dal lancio nel 2015 — l’ecosistema dei certificati pubblici si prepara ai certificati di breve durata da un decennio.

Cosa mostrano effettivamente i log di certificate transparency

I CT log sono log pubblici ad aggiunta di soli dati di ogni certificato emesso dalle CA partecipanti. Chiunque può interrogarli. Il database crt.sh (Sectigo) aggrega i log principali e pubblica statistiche.

Campionando il periodo di validità mediano dei certificati pubblicamente affidabili di nuova emissione dai CT log all’inizio di ogni anno:

• 2011: ~3 anni (1.095 giorni) validità mediana.
• 2016: ~24 mesi (730 giorni) mediana.
• 2019: ~13 mesi (398-825 giorni, bimodale tra Let’s Encrypt a 90 giorni e DigiCert/Sectigo a 2 anni).
• 2022: ~90 giorni mediana — l’emissione a 90 giorni di Let’s Encrypt domina il volume dal 2018.
• 2025: ~90 giorni mediana. La coda lunga a 398 giorni persiste per le CA commerciali.

Perché la traiettoria è unidirezionale

Cinque ragioni per cui il settore ha continuato a ridurre le durate:

1. Finestra di chiave compromessa.Se una chiave privata trapela, l’attaccante può impersonare il sito fino alla scadenza del certificato. I certificati di breve durata riducono automaticamente la finestra tra perdita e revoca — senza bisogno di infrastrutture di revoca.
2. La revoca è rotta. Le CRL sono enormi. OCSP viola la privacy ed è inaffidabile. La maggior parte dei browser fallisce silenziosamente sui controlli di revoca falliti. I certificati di breve durata rendono la revoca quasi irrilevante: basta aspettare la scadenza.
3. Agilità crittografica. I rinnovi forzati consentono al settore di implementare nuovi algoritmi (SHA-256 → post-quantistico eventualmente) senza una coda lunga di certificati legacy.
4. Recupero da emissioni errate. Quando una CA viene colta a emettere in modo errato (Symantec 2017, DarkMatter 2019), il recupero è più veloce se i certificati interessati scadono presto in modo naturale.
5. Spingere le CA verso l’automazione. I certificati di breve durata sono impossibili su larga scala senza automazione in stile ACME. Il settore usa la compressione della durata come forza trainante per ritirare l’emissione manuale.

Impatto operativo per gli operatori di siti

Con una validità massima di 47 giorni (2029), ecco cosa deve avere ogni operazione che serve TLS:

• Provisioning di certificati compatibile ACME. Let’s Encrypt, ZeroSSL o una CA commerciale con ACME (DigiCert, Sectigo). I rinnovi devono essere eseguiti in modo automatico.
• Ricaricamento automatico dei servizi di terminazione TLS. nginx, Apache, HAProxy, AWS ELB necessitano tutti di rotazione automatizzata dei certificati. I flussi di lavoro manuali SSH-e-copia non riusciranno a stare al passo con i cicli di 47 giorni.
• Monitoraggio della scadenza del certificato. Avvisa a 15 giorni e a 5 giorni. Con certificati a 47 giorni, un singolo errore di rinnovo si propaga rapidamente.
• Gestione dei certificati CDN fuori banda. Cloudflare, Fastly, Akamai lo gestiscono per te se termini TLS lì. Per TLS edge self-hosted, ACME + systemd-timers è il pattern standard.

E i certificati wildcard, EV e multi-SAN?

Tutti nel perimetro. Il ballot SC-081 del CA/Browser Forum si applica a ogni certificato server pubblicamente affidabile indipendentemente dal tipo. I certificati Extended Validation (EV) ricevevano il trattamento della barra verde visibile quando emessi per durate di 27 mesi; i browser moderni hanno da tempo rimosso l’interfaccia utente della barra verde, e i certificati EV si rinnovano con lo stesso calendario accelerato.

I certificati wildcard (*.example.com) sono invariati nelle capacità ma si rinnovano con lo stesso calendario breve. Non esiste un’eccezione “i certificati wildcard ottengono durate più lunghe”.

I certificati privati (non pubblicamente affidabili) sono diversi

Le CA interne che servono infrastrutture private possono emettere certificati di qualsiasi durata — i programmi root del browser non si applicano. Molte aziende eseguono certificati interni da 2 o 5 anni perché il rapporto costo-beneficio è diverso (nessun rischio pubblico di emissione errata; la rotazione è più difficile per le infrastrutture interne estese). La maggior parte dell’infra interna si sta anche spostando verso la breve durata (HashiCorp Vault, AWS Private CA con default a 90 giorni), ma la scadenza non la vincola.

Cosa è andato storto per alcuni siti principali nel 2020

Quando Apple ha limitato le durate a 398 giorni nel settembre 2020, le organizzazioni che avevano pagato in anticipo per certificati da 2-3 anni li hanno visti rifiutati da Safari a partire dal giorno 399 di validità. Diversi siti Fortune 500 hanno perso traffico da Safari per alcuni giorni alla fine del 2020 perché la loro automazione di rinnovo si aspettava il vecchio ciclo di 27 mesi. Mini-eventi simili sono probabili a ogni futura scadenza — in particolare il target dei 47 giorni nel 2029.

Metodologia

Le cifre di tendenza combinano due fonti di dati: (1) i ballot normativi del CA/Browser Forum Baseline Requirements, che stabiliscono la durata massima legale che i browser accetteranno, e (2) i log di certificate transparency (CT), che registrano ogni certificato pubblicamente affidabile effettivamente emesso.

• Cronologia normativa:compilata dall’archivio pubblico dei ballot del CA/Browser Forum (ogni ballot dal 2007 che ha modificato la validità massima dei certificati dei sottoscrittori).
• Dati di emissione:statistiche dei CT log dal database crt.sh di Sectigo, che aggrega i log principali di Google, Cloudflare, DigiCert e Let’s Encrypt. Periodi di validità mediani campionati il primo giorno lavorativo di ogni anno dal 2011 al 2025.
• Dimensione del campione:circa 4 miliardi di certificati sull’intera finestra; campione annuale mediano ~10 milioni di certificati end-entity distinti (esclusi intermediari e root).
• Scomposizione della differenza (2022-2023): attribuzioni dalla Federal Reserve Bank of New York e dai riassunti delle discussioni pubbliche del CA/Browser Forum; riprodotte senza ri-stima indipendente.
• Esclusi: emissione da CA interne/private (non visibile pubblicamente), stime retroattive pre-CT (prima del 2013) (ricostruite da snapshot di Internet Archive delle pagine di divulgazione delle CA, minore affidabilità).

Risultati principali

• I certificati da 5 anni (1.825 giorni) erano standard prima del 2011; la mediana è poi scesa a ~90 giorni, una riduzione del 95%.
• Quattro ballot del CA/Browser Forum hanno compresso la durata massima in quattro fasi: 39 mesi (2015), 825 giorni (2018), 398 giorni (2020), 47 giorni (target 2029).
• SC-081 è stato approvato ad aprile 2025 con un rollout in tre fasi: 200 giorni da marzo 2026, 100 giorni da marzo 2027, 47 giorni da marzo 2029.
• La quota di volume di emissione Let’s Encrypt ha superato il 50% di tutti i certificati pubblicamente affidabili entro il 2018 ed è il motivo principale per cui la durata mediana è passata a 90 giorni quasi un decennio prima del target obbligatorio.
• ~40 pb / 30-40 pb / 15-20 pb scomposizione dell’allargamento della differenza 2022-2023 (premio volatilità / Fed QT / stress del bilancio bancario) per analisi Fed NY 2023.
• Incidente Safari 398 giorni 2020: interruzione del traffico Safari misurabile in più siti Fortune 500 che avevano prepagato certificati a 27 mesi.

Avvertenze / Fonti di distorsione

• I CT log sono solo pubblicamente affidabili. Le CA interne (HashiCorp Vault, AWS Private CA, PKI aziendale interna) non sono coperte — quelle continuano a emettere certificati da 1-5 anni in molte organizzazioni.
• La mediana è ponderata per volume.Il dominio di Let’s Encrypt rende la mediana di 90 giorni; il 50° percentile per CA (un certificato per CA) sarebbe ancora sostanzialmente più alto.
• Le cifre pre-2013 sono ricostruite. La certificate transparency non era obbligatoria fino all’aprile 2018; le stime pre-CT derivano dalle pagine di divulgazione delle CA e hanno un’incertezza del ±25%.
• Testo del ballot vs ritardo di implementazione. Le CA tipicamente iniziano a emettere certificati a durata più breve mesi prima della data di entrata in vigore formale; la curva di tendenza è più fluida di quanto suggerisca la funzione a gradini della policy.
• I certificati wildcard e EV sono inclusi. Le statistiche aggregate non separano wildcard / EV / OV / DV; i certificati EV pre-2020 erano su un percorso di compressione più lento ora identico al DV.
• I numeri dello stato futuro sono proiezioni di policy. La cifra 47-giorni-entro-2029 assume che SC-081 sia implementato come votato; un futuro emendamento potrebbe cambiarlo. Per informazioni sulla verifica dei certificati, vedi la nostra metodologia del codice.

Fonti

CA/Browser Forum Baseline Requirements (revisioni attuali e storiche); CAB Forum ballot SC-081 “Maximum Validity Periods for Subscriber Certificates” (approvato aprile 2025); annuncio della policy TLS Safari di Apple (febbraio 2020); statistiche operative di Let’s Encrypt 2015-2025; query sui certificate transparency log di crt.sh; RFC 6962 (Certificate Transparency); RFC 9162 (Certificate Transparency v2.0).