Preparatevi a un accorciamento della validità dei certificati

La validità massima dei certificati TLS pubblici si ridurrà gradualmente negli anni seguenti:

• Fino al 15 marzo 2026 la validità massima del certificato TLS è di 398 giorni.
• Dal 15 marzo 2026 la validità massima del certificato TLS sarà di 200 giorni.
• Dal 15 marzo 2027 la validità massima del certificato TLS sarà di 100 giorni.
• Dal 15 marzo 2029 la validità massima del certificato TLS sarà di 47 giorni.

Si riduce anche la durata massima per la quale è possibile riutilizzare le informazioni di verifica del dominio e dell'indirizzo IP:

• Fino al 15 marzo 2026 la durata massima di riutilizzo delle informazioni di verifica è di 398 giorni.
• Dal 15 marzo 2026 la durata massima di riutilizzo delle informazioni di verifica sarà di 200 giorni.
• Dal 15 marzo 2027 la durata massima di riutilizzo delle informazioni di verifica sarà di 100 giorni.
• Dal 15 marzo 2029 la durata massima di riutilizzo delle informazioni di verifica sarà di 10 giorni.

La validità massima del certificato indica il numero massimo di giorni per cui il certificato è considerato valido. Per emettere un certificato, l'autorità di certificazione (CA) deve verificare che il richiedente controlli effettivamente il dominio o l'indirizzo IP indicato nel certificato.

Se oggi hai un certificato e lo rinnovi una volta l'anno (secondo le regole attuali), la verifica del controllo sul dominio avviene ad ogni rinnovo.

Ma cosa succede se devi sostituire il certificato prima del rinnovo, ad esempio nel caso di compromissione della chiave privata? In questo caso, la CA può riutilizzare la verifica effettuata all'ultimo rinnovo, evitando così la necessità di una nuova convalida. Ciò è possibile perché non è ancora trascorsa la massima durata di riutilizzo della verifica del dominio.

I requisiti di base (Baselines Requirements, cioè le regole del CA/B Forum per l'emissione dei certificati) hanno sempre definito entrambi i limiti temporali, ma la maggior parte delle volte erano impostati sullo stesso valore.

La modifica nella fase finale delle nuove regole — quando la validità massima del certificato scende a 47 giorni, mentre la verifica del dominio può essere riutilizzata solo per 10 giorni — ha l'obiettivo di garantire che la verifica avvenga più frequentemente. Il CA/B Forum presume che le informazioni sul controllo dei domini invecchiano rapidamente.

Lo stesso calendario di verifiche del dominio varrà anche per i certificati OV ed EV. Sarà necessario effettuare la verifica del dominio con la stessa frequenza dei certificati DV, quindi ogni 200 / 100 / 10 giorni.

Tuttavia, le altre informazioni contenute nei certificati OV ed EV (ad esempio il nome e l'indirizzo dell'organizzazione) richiederanno rinnovi solo ogni 398 giorni. Sebbene la verifica del dominio possa e debba essere automatizzata, le altre informazioni non possono essere completamente automatizzate.

No, non proprio. Le limitazioni riguardano la tipologia di certificati che le autorità di certificazione (CA) possono emettere, non la tipologia di certificati che i browser possono accettare.

Il browser verifica solo se la data corrente rientra nel periodo di validità del certificato.

Una volta che le singole modifiche entreranno in vigore, le autorità di certificazione non potranno più emettere certificati TLS con validità superiore a 200 / 100 / 47 giorni.

Tuttavia, un certificato con validità di 398 giorni, emesso prima delle modifiche, rimarrà valido fino alla sua scadenza. Lo stesso vale per i certificati con validità di 200 giorni al momento della transizione al limite di 100 giorni e per i certificati con validità di 100 giorni nella transizione al limite di 47 giorni.

No, i requisiti di base vincolano solo le autorità di certificazione pubbliche.

Una PKI interna opera all'interno della tua rete o dei tuoi cloud. Include le autorità di certificazione, ma le politiche applicate dalle autorità di certificazione interna — inclusi i periodi di validità dei certificati — sono decise da te. Potrebbe essere appropriato scegliere un periodo di validità breve anche per una PKI interna, ma non è obbligatorio. Puoi gestire il software per una PKI interna da solo, ma è un compito complesso e soggetto a errori. DigiCert offre diverse soluzioni per PKI interne applicabili a contesti aziendali, cloud e produttivi.

No. Non ci sono costi aggiuntivi per il rinnovo o la sostituzione dei certificati durante la durata del contratto (in anni). Durante la validità del contratto, puoi effettuare numero illimitato di riregistrazioni (reissue).

No, riguardano solo i certificati finali (leaf) emessi dall'autorità di certificazione intermedia. Non ci sono norme del CA/B Forum o di altri organismi che limitano la durata dei certificati root e intermedi, ma ci sono buone pratiche riconosciute e i fornitori di software che utilizzano i certificati stabiliscono le proprie regole per i loro programmi di fiducia per i root, che possono variare notevolmente.

La Mozilla Root Store Policy (sezione 7.4) indica che Mozilla cesserà di fidarsi dei certificati root 15 anni dopo la generazione della chiave.

Le regole di validità nel programma root di Chrome, versione 1.6 (15 febbraio 2025), sono più complesse. Non c'è un limite di validità fisso, ma "qualsiasi certificato root CA con materiale chiave generato più di 15 anni fa sarà progressivamente rimosso dal Chrome Root Store". Le radici che contengono chiavi create prima del 16 aprile 2014 verranno rimosse secondo un calendario annuale definito nella Root Program Policy.

Il Microsoft Trusted Root Program stabilisce che "le nuove autorità di certificazione root (Root CA) devono avere una validità minima di otto anni e massima di 25 anni dalla data di presentazione". La differenza nelle regole tra la politica di Microsoft e le altre politiche deriva dalla varietà di applicazioni che Microsoft supporta nella sua PKI, un ventaglio molto più ampio rispetto ad altri browser.

Una delle buone pratiche di buon senso è che un certificato root CA non dovrebbe scadere prima di qualsiasi certificato CA intermedio a esso legato.

Una cattiva gestione del ciclo di vita dei certificati root e intermedi CA può avere conseguenze gravi, come si è visto di recente nel caso di un certificato intermedio apparentemente dimenticato di Google che è scaduto e ha lasciato molti dispositivi Chromecast senza servizio.

Per casi comuni e semplici, come i server web e i certificati TLS pubblici, l'automazione è gratuita per i clienti di CertCentral grazie agli standard ampiamente supportati Automated Certificate Management Environment (ACME) e ACME Renewal Information (ARI).

Ovviamente non tutti i certificati sono pubblici TLS e non tutte le tecnologie supportano ACME. In questi casi, il DigiCert Trust Lifecycle Manager offre opzioni di automazione avanzate e integrazioni.

Tuttavia, l'automazione tramite ACME non si riduce al semplice segno di un'apposita casella. Sono necessarie delle modifiche sul dispositivo o nell'applicazione (tipicamente sul server web) che richiede il certificato. Per la maggior parte degli amministratori, tuttavia, questo processo è semplice e ben documentato.

ACME è Automated Certificate Management Environment.
ARI è ACME Renewal Information.

ACME è uno standard supportato da tutte le principali autorità di certificazione attraverso il quale il software client per certificati (tipicamente un server web) richiede un certificato all'autorità di certificazione e lo installa sul dispositivo client. (In questo scenario, il server web è il client.)

Il software client deve supportare ACME. Il supporto è diffuso ma non universale. Il programma client ACME solitamente viene eseguito sul sistema client secondo una pianificazione utilizzando cron in Linux o il Task Scheduler in Windows, ma ci sono anche soluzioni che integrano la pianificazione in prodotti più grandi.

ARI è uno standard correlato attraverso il quale il server può raccomandare una pianificazione, in modo che il client sappia quando il certificato deve essere rinnovato prima che scada. Se configurato correttamente, ARI può ordinare il rinnovo anche in caso di revoca del certificato, prevenendo eventuali interruzioni.

Secondo le nuove regole per i certificati TLS, dal 15 marzo 2026 sarà possibile riutilizzare la verifica delle informazioni identitarie del soggetto (Subject Identity Information, SII) solo per 398 giorni, anziché 825 giorni come in precedenza.

Ciò significa che il principale impatto sui tuoi certificati OV ed EV sarà la necessità di verificare nuovamente le informazioni identitarie del soggetto (SII) — ovvero le informazioni nel certificato che identificano la tua organizzazione — ogni anno, non ogni due anni.

Secondo i requisiti di base TLS, ciò richiede una chiamata telefonica annuale con un rappresentante di DigiCert, pertanto questo processo non può essere completamente automatizzato.

Si noti che i certificati OV ed EV proteggono anche i nomi di dominio, quindi la loro durata cambierà secondo lo stesso calendario dei certificati DV: 200 giorni nel 2026, 100 giorni nel 2027 e 47 giorni nel 2029. Pertanto, la necessità di automatizzare la gestione di questi certificati è tanto essenziale quanto per i certificati DV.

Il numero 47 giorni può apparentemente sembrare arbitrario, ma deriva da una semplice sequenza:

• 200 giorni = 6 mesi massimi (184 giorni) + 1/2 di mese di trenta giorni (15 giorni) + 1 giorno di riserva
• 100 giorni = 3 mesi massimi (92 giorni) + circa 1/4 di mese di trenta giorni (7 giorni) + 1 giorno di riserva
• 47 giorni = 1 mese massimo (31 giorni) + 1/2 di un mese di trenta giorni (15 giorni) + 1 giorno di riserva

Questo modello di definizione di una durata di validità "dispari" con un margine aggiuntivo è una prassi standard del CA/B Forum da lungo tempo. Il limite attuale di 398 giorni è stato scelto come 1 anno massimo (366 giorni) + 1 mese massimo (31 giorni) + 1 giorno di riserva.

Sì, secondo le regole è possibile ottenere ulteriori 398 giorni se i certificati vengono rinnovati prima del 15 marzo 2026. Si tratta, tuttavia, di un'estensione unica — con il rinnovo successivo la durata massima sarà ridotta a 100 giorni. Ricorda di impostare l'automazione in tempo per essere preparato.

Se si deve ricreare un certificato con una nuova chiave (rekey) dal 15 marzo 2026 o oltre, DigiCert (così come qualsiasi altra autorità di certificazione pubblica) dovrà conformarsi alle regole vigenti a quel momento, il che ti darà, nel migliore dei casi, un certificato con una validità di 200 giorni.

Il miglior momento per automatizzare la gestione dei certificati è il prima possibile — in questo modo ci si assicura di essere pronti per il processo, evitando così rischi di interruzioni causate dalla scadenza dei certificati o da altri problemi.

Il mercato dei certificati TLS pubblici è in gran parte rivolto ai certificati utilizzati nei browser, tipicamente installati su un qualche server web, ma ci sono anche altri casi d'uso. Un buon esempio sono i gateway VPN e alcuni dispositivi Internet of Things (IoT).

Anche questi dispositivi dovranno accelerare la gestione del ciclo di vita dei certificati (CLM). Molti di loro supportano direttamente ACME o altri protocolli di automazione, quindi il cambiamento dei parametri potrebbe non essere un problema significativo. In altri casi, potrebbe esistere il supporto per un meccanismo di automazione alternativo oppure non esserci affatto — in tal caso è l'utente che deve assicurarsi l'automazione tramite la programmazione.

L'adattamento al nuovo calendario sarà un problema comune per questi dispositivi. È importante creare un inventario completo delle risorse interessate, e DigiCert può aiutare in questo.