Certificati Let's Encrypt di 45 giorni: Cosa devono sapere i team aziendali

Introduzione#

Il panorama dei certificati SSL sta per affrontare il cambiamento più significativo degli ultimi anni. Let's Encrypt, la più grande autorità di certificazione al mondo, sta passando da durate dei certificati di 90 giorni a 45 giorni. Per i team enterprise che gestiscono centinaia o migliaia di domini, non si tratta di una semplice modifica — è un cambiamento fondamentale nel modo in cui deve funzionare la gestione dei certificati SSL.

Se il tuo team gestisce ancora manualmente i rinnovi SSL, a breve sentirai la pressione. Quattro cicli di rinnovo all’anno diventano otto. Un’attività trimestrale gestibile diventa un onere operativo continuo. La tempistica è già in movimento e i team di infrastruttura che si preparano ora affronteranno la transizione in modo fluido. Chi non lo farà dovrà affrontare un rischio maggiore di interruzioni e un aumento dell’impegno operativo.

Questo articolo analizza l’annuncio, le motivazioni alla base, come si presenta la tempistica della transizione e cosa dovrebbero fare i team enterprise per prepararsi.

L’annuncio: Let's Encrypt passa da durate di 90 giorni a 45 giorni per i certificati#

Let's Encrypt ha annunciato a metà 2026 la propria intenzione di ridurre le durate massime dei certificati da 90 giorni a 45 giorni. La modifica riguarda tutti i nuovi certificati emessi dopo la data di transizione. I certificati esistenti continueranno a essere validi fino alla loro naturale scadenza, ma i rinnovi saranno soggetti alla nuova durata di 45 giorni.

Non è una decisione improvvisa. Let's Encrypt ha progressivamente accorciato le durate dei certificati sin dal suo lancio. Hanno iniziato con 90 giorni quando la maggior parte delle CA commerciali offriva certificati annuali. Il passaggio a 45 giorni prosegue una tendenza verso certificati a vita più breve, verso cui l’intera industria si sta muovendo.

L’impatto pratico è semplice: ogni dominio protetto da Let's Encrypt dovrà rinnovare il certificato il doppio delle volte. Per le organizzazioni che hanno già automatizzato il processo di rinnovo, la transizione potrebbe essere senza intoppi. Per i team che si affidano a processi manuali o a flussi di lavoro semi-automatizzati, l’impatto operativo sarà significativo.

Perché sta succedendo: best practice di sicurezza — limitare la finestra di compromissione#

Durate dei certificati più brevi sono, in sostanza, un miglioramento della sicurezza. Ogni certificato TLS rappresenta un potenziale vettore di attacco. Se la chiave privata di un certificato viene compromessa, un attaccante può impersonare il dominio legittimo fino alla scadenza del certificato o fino alla sua revoca. Più lunga è la durata del certificato, più a lungo rimane aperta quella finestra di compromissione.

I certificati di durata di quarantacinque giorni riducono quella finestra della metà rispetto allo standard attuale di 90 giorni. Se una chiave viene compromessa il primo giorno, l’esposizione massima è di 45 giorni invece che di 90. Nella pratica, l’esposizione è in genere più breve, ma il limite massimo conta — soprattutto per le organizzazioni che potrebbero non rilevare una compromissione subito.

C’è anche un argomento sulla revoca. La revoca dei certificati tramite CRL e OCSP è storicamente stata poco affidabile. I browser non sempre controllano lo stato di revoca in modo coerente e i certificati revocati a volte continuano a essere considerati attendibili. Durate più brevi riducono la dipendenza dall’infrastruttura di revoca. Se un certificato dura solo 45 giorni, revocarlo diventa meno critico — scade comunque a breve.

La community della sicurezza sostiene da tempo durate dei certificati più brevi. La scelta di Let’s Encrypt rende operativo ciò che i ricercatori di sicurezza raccomandano da anni.

Proposta del Parallel CA/Browser Forum di Google — Non è solo Let’s Encrypt#

Let’s Encrypt non sta agendo da solo. Google sta facendo avanzare una proposta parallela tramite il CA/Browser Forum per ridurre a livello di settore le durate massime dei certificati a 45 giorni. Questo riguarderebbe tutte le autorità di certificazione, non solo Let’s Encrypt — incluse CA commerciali come DigiCert, Sectigo e GlobalSign.

La proposta del CA/B Forum è ancora in discussione, ma il coinvolgimento di Google indica che le durate di 45 giorni probabilmente diventeranno uno standard di settore, non solo una policy di Let’s Encrypt. Quando il più grande produttore di browser e la più grande autorità di certificazione si allineano su una policy di sicurezza, l’adozione tende a seguire.

Per i team enterprise, questo significa che l’era dei certificati da 45 giorni non è una preoccupazione specifica di Let’s Encrypt. Se oggi usi certificati commerciali con durate di un anno, dovresti aspettarti che anche quelle durate si riducano. L’intero ecosistema dei certificati SSL si sta spostando verso certificati a vita breve e la transizione è già in corso.

Timeline: quando avviene il cambiamento e che aspetto ha il periodo di transizione#

Let’s Encrypt ha segnalato un rollout a fasi. Le date esatte sono ancora in fase di definizione, ma la tempistica prevista segue un modello simile alle loro precedenti riduzioni di durata:

**Fase di annuncio (attuale):** Comunicazione pubblica, aggiornamenti della documentazione e preparazione degli strumenti. Software client come Certbot e le librerie ACME ricevono aggiornamenti per gestire le nuove durate.

**Distribuzione a fasi:** Il periodo di validità di 45 giorni si applica inizialmente a un sottoinsieme di nuove emissioni di certificati, consentendo a Let's Encrypt di monitorare eventuali problemi e raccogliere dati sui modelli di rinnovo.

**Applicazione completa:** Tutti i nuovi certificati emessi da Let's Encrypt includono la durata massima di 45 giorni. I certificati esistenti con validità di 90 giorni continuano fino alla loro scadenza naturale.

Per i team enterprise, la scadenza pratica coincide con il momento in cui la tua automazione attuale raggiunge il suo ciclo di rinnovo dopo la transizione. Se oggi i tuoi certificati si rinnovano ogni 60 giorni, hai circa un ciclo di rinnovo dopo le modifiche di policy prima di iniziare a emettere certificati da 45 giorni.

Cosa significano davvero 45 giorni: 8 cicli di rinnovo all’anno rispetto agli attuali 4#

I conti sono semplici, ma l’impatto operativo non lo è. Passare da certificati da 90 giorni a certificati da 45 giorni significa:

**La frequenza di rinnovo raddoppia.** Invece di quattro cicli di rinnovo all’anno per dominio, ne gestisci otto. Per un team che gestisce 100 domini, sono 800 eventi di rinnovo all’anno invece di 400. Per i team che gestiscono migliaia di domini, i numeri diventano ingestibili senza una piena automazione.

**Le finestre di rinnovo si riducono.** Con certificati da 90 giorni, la maggior parte dei sistemi di rinnovo automatici inizia a tentare il rinnovo 30 giorni prima della scadenza, lasciando un cuscinetto confortevole di 30 giorni. Con certificati da 45 giorni, quello stesso anticipo di 30 giorni lascia solo 15 giorni di margine. La logica di rinnovo deve essere più aggressiva e più affidabile.

**La tolleranza ai guasti diminuisce.** Con certificati da 90 giorni, un fallimento del rinnovo ti dà settimane per indagare e risolvere il problema prima della scadenza. Con certificati da 45 giorni, hai giorni. Ogni fallimento del rinnovo è più urgente e il tuo monitoraggio deve essere più reattivo.

**Il rate limiting diventa un problema.** Let's Encrypt applica limiti di velocità sull’emissione dei certificati. Raddoppiare la frequenza di rinnovo significa consumare il doppio del budget di rate limit. I team che sono vicini ai loro limiti con certificati da 90 giorni potrebbero raggiungerli con certificati da 45 giorni e devono adeguare i loro modelli di emissione.

In sintesi: i processi di rinnovo manuali o semi-automatizzati che funzionavano appena a 90 giorni falliranno a 45 giorni. La piena automazione non è più un’opzione.

Chi è maggiormente colpito: team che gestiscono 100+ domini con processi SSL manuali#

L’era dei certificati di 45 giorni non colpisce tutti allo stesso modo. Ecco chi avverte il maggiore impatto:

**Investitori di domini e responsabili di portafoglio.** I team che gestiscono centinaia o migliaia di domini parcheggiati, reindirizzati o monetizzati affrontano il carico operativo più pesante. Ogni dominio richiede il proprio certificato. Il rinnovo manuale a questa scala era già doloroso a 90 giorni. A 45 giorni non è fattibile.

**Agenzie che gestiscono i domini dei clienti.** Le agenzie digitali spesso gestiscono SSL per decine o centinaia di domini dei clienti. Ogni cliente può utilizzare infrastrutture diverse, processi di rinnovo diversi e livelli di automazione diversi. La scadenza di 45 giorni amplifica ogni incoerenza nei loro flussi di rinnovo.

**Piattaforme e-commerce con più storefront.** Le operazioni e-commerce multi-brand gestiscono domini separati per ogni brand, per ogni area geografica e per ogni campagna. Il numero di certificati aumenta rapidamente, così come il carico di rinnovo.

**Piattaforme SaaS con domini personalizzati.** I prodotti SaaS che consentono ai clienti di portare i propri domini in genere gestiscono il provisioning SSL come parte dell’onboarding. Con certificati di 45 giorni, l’infrastruttura di rinnovo deve essere a prova di proiettile: un fallimento del rinnovo per il dominio di un cliente significa che il suo sito mostra un avviso di sicurezza.

I team con rinnovo completamente automatizzato basato su ACME potrebbero non percepire affatto il cambiamento. La durata del certificato viene gestita dall’infrastruttura che rinnova automaticamente. La linea di demarcazione è l’automazione: se il tuo processo di rinnovo prevede che una persona controlli una dashboard o esegua uno script, sei dalla parte sbagliata.

Il divario di prontezza per l’Enterprise#

I sondaggi di settore delineano un quadro preoccupante. Nonostante anni di disponibilità di Let’s Encrypt e la maturità dell’automazione ACME, una percentuale significativa di organizzazioni gestisce ancora i rinnovi SSL tramite processi manuali o semi-automatizzati.

Le lacune più comuni includono: certificati gestiti tramite fogli di calcolo invece che tramite monitoraggio automatizzato, script di rinnovo che richiedono l’attivazione manuale, avvisi di scadenza che finiscono in caselle di posta non monitorate e certificati wildcard distribuiti in tutta l’infrastruttura senza un coordinamento centralizzato del rinnovo.

Il divario di prontezza è più ampio nelle organizzazioni che hanno adottato Let's Encrypt in anticipo, ma non hanno mai automatizzato completamente la pipeline di rinnovo. Hanno configurato Certbot su alcuni server cinque anni fa, hanno aggiunto un cron job e non hanno più rivisto la configurazione. Questi cron job potrebbero essere eseguiti ogni 60 giorni, il che non è abbastanza frequente per certificati con validità di 45 giorni.

La raccomandazione dei team di infrastruttura che hanno già effettuato la transizione è coerente: valuta ora i tuoi processi di rinnovo. Mappa ogni certificato nella tua infrastruttura, verifica che il rinnovo sia automatizzato e monitorato e testa le procedure di ripristino in caso di guasto. L’era dei certificati di 45 giorni metterà in evidenza ogni lacuna nella tua pipeline di rinnovo.

Conclusione#

L’era dei certificati di 45 giorni sta arrivando e non si tratta solo di un cambiamento di policy di Let's Encrypt: è uno spostamento a livello di settore verso durate dei certificati più brevi, guidato dalle best practice di sicurezza. Per i team enterprise, la linea di demarcazione tra chi avverte l’impatto e chi no è semplice: l’automazione.

Se la tua pipeline di rinnovo SSL è completamente automatizzata tramite ACME — se i certificati si rinnovano, si installano e si verificano senza intervento umano — potresti non notare affatto il cambiamento, se non aggiornando un parametro di configurazione. Se invece il tuo processo di rinnovo prevede qualsiasi passaggio manuale, fogli di calcolo o script attivati da persone, la timeline di 45 giorni metterà in evidenza ogni lacuna nella tua infrastruttura.

I passaggi pratici sono semplici: verifica l’inventario dei certificati, controlla la copertura dell’automazione, testa gli scenari di fallimento del rinnovo e assicurati che il monitoraggio rilevi le scadenze prima che gli utenti vedano avvisi del browser. I team che lo fanno già — prima che la timeline si accorci — affronteranno la transizione senza incidenti.

Valuta ora il tuo processo di rinnovo SSL. L’era dei 45 giorni sta arrivando: scopri come funziona la gestione SSL automatizzata.