Checklist per l'Infrastruttura di Redirect per l'Era del Certificato di 45 Giorni

Le durate dei certificati SSL stanno per essere dimezzate. Let's Encrypt — che alimenta il 60% di tutti i certificati web — sta passando da una durata massima di 90 giorni a 45 giorni. La proposta del Google CA/Browser Forum segue questa direzione. L’intero settore dei certificati sta spingendo verso durate più brevi come standard di sicurezza e la tempistica non è più teorica.

Per i team che gestiscono infrastrutture di redirect su centinaia o migliaia di domini, non si tratta di un semplice aggiustamento — è un moltiplicatore operativo. Ciò che richiedeva 4 cicli di rinnovo per dominio all’anno richiederà presto 8. I processi manuali che a 90 giorni funzionavano a malapena falliranno completamente a 45.

Questa checklist è pensata per aiutare i team di infrastruttura a valutare la propria prontezza in sei aree critiche: automazione, monitoraggio, tempistiche di rinnovo, alerting, strategia wildcard e disaster recovery. Ogni sezione include una domanda di autovalutazione e uno stato target. Alla fine avrai un quadro chiaro di dove si trova la tua infrastruttura — e di cosa deve cambiare prima dell’arrivo dell’era dei 45 giorni.

1. Automazione: Ciclo di vita dei certificati a zero interventi#

La domanda singola più importante nella tua valutazione di prontezza: ogni certificato emesso e rinnovato avviene senza intervento umano?

Se la risposta è qualsiasi cosa diversa da un inequivocabile “sì”, hai un problema. Con durate di 45 giorni, le operazioni manuali sui certificati diventano insostenibili anche su scale sorprendentemente piccole. Un portafoglio di soli 50 domini richiede 400 operazioni sui certificati all’anno — più di una al giorno, ogni giorno, inclusi weekend e festività.

Autovalutazione dello stato attuale: come gestisce il tuo team il provisioning dei certificati oggi? Se la risposta include promemoria di calendario, fogli di calcolo, generazione manuale di CSR o “di solito se ne occupa qualcuno”, sei nella fascia manuale. Anche se hai automatizzato parti del flusso, chiediti se lo script copre ogni dominio, gestisce ogni caso limite e recupera da ogni guasto senza escalation umana.

Stato target: ogni hostname nella tua infrastruttura di redirect esegue automaticamente il provisioning di SSL tramite ACME non appena il DNS è configurato. L’emissione, l’installazione e il rinnovo dei certificati avvengono senza alcuna azione umana. Il sistema rileva i nuovi domini, valida la proprietà tramite la challenge DNS-01, richiede il certificato, lo installa sui nodi di edge e pianifica il prossimo rinnovo — tutto entro pochi secondi dall’aggiunta dell’hostname.

Una piattaforma di redirect che gestisce SSL per hostname — invece di richiederti di gestire i certificati per server — elimina completamente il gap di automazione. Quando il DNS viene delegato alla piattaforma, SSL diventa una proprietà dell’infrastruttura, non un’attività nella lista di cose da fare di qualcuno.

2. Monitoraggio: saperlo prima che si rompa#

Chiediti: Hai un monitoraggio attivo della scadenza dei certificati su tutti i domini?

Il monitoraggio è la rete di sicurezza sotto l’automazione. Anche con il rinnovo basato su ACME, possono andare storte le cose: cambia un record DNS, scatta un rate limit, una CA va in outage. Senza monitoraggio, scopri i certificati scaduti nello stesso modo in cui lo fanno i tuoi utenti — tramite un avviso del browser.

Ma il monitoraggio non riguarda solo il controllo delle date di scadenza. Un monitoraggio efficace per l’infrastruttura di redirect significa controlli di salute (health check) da più posizioni globali, perché un certificato che sembra valido dalla tua sede potrebbe fallire dalla posizione di un utente a causa di ritardi di propagazione ai bordi o della cache della CDN.

Autovalutazione dello stato attuale: Hai una dashboard o un sistema di alerting che mostri le date di scadenza dei certificati per ogni dominio? Viene aggiornato in tempo reale quando i certificati vengono rinnovati? Puoi vedere al volo quali domini si stanno avvicinando alla scadenza e quali hanno già fallito?

Stato target: Monitoraggio continuo della salute dei certificati da più posizioni globali ai bordi (edge). Il sistema esegue controlli attivi di handshake TLS — non solo ricerche della data di scadenza — per verificare che ogni certificato sia valido, attendibile e servito correttamente. La dashboard mostra lo stato in tempo reale su tutti i domini. Il monitoraggio è automatico: quando viene aggiunto un nuovo hostname, il monitoraggio parte senza configurazione.

3. Tempistiche di rinnovo: la Zona cuscinetto#

La domanda: I rinnovi vengono tentati abbastanza presto da superare outage di più giorni?

Con certificati di 90 giorni, rinnovare 7-14 giorni prima della scadenza offriva un margine confortevole. Con certificati di 45 giorni, lo stesso margine consuma il 15-30% della durata totale utilizzabile del certificato. I conti impongono un compromesso: rinnovi troppo presto e stai continuamente facendo rotazione dei certificati; rinnovi troppo tardi e un temporaneo outage della CA diventa un incidente in produzione.

I rate limit di Let's Encrypt aggiungono un’ulteriore dimensione. Il limite Duplicate Certificate consente 5 certificati a settimana per lo stesso insieme di hostname e il limite Certificates per Registered Domain è fissato a 50 per settimana. Con cicli di rinnovo di 45 giorni, grandi portafogli di domini possono avvicinarsi a questi limiti più velocemente del previsto — soprattutto se stai anche provisioning di certificati per nuovi domini.

Autovalutazione dello stato attuale: Qual è la tua finestra di rinnovo? Se il tuo team rinnova i certificati manualmente, i rinnovi vengono avviati almeno 15 giorni prima della scadenza? Riesci a superare un outage di 5 giorni della CA senza che scada alcun certificato? Hai testato cosa succede quando un tentativo di rinnovo fallisce — il sistema riprova automaticamente o aspetta un intervento umano?

Stato target: I rinnovi automatici iniziano 30 giorni prima della scadenza con una logica di retry a backoff esponenziale. Se il primo tentativo fallisce, il sistema riprova a intervalli crescenti — 1 ora, 4 ore, 12 ore, 24 ore — finché il rinnovo riesce. Le limitazioni di velocità vengono tracciate e rispettate automaticamente. Il sistema può sopravvivere a un’interruzione della CA per più giorni senza che nessun dominio raggiunga la data di scadenza, perché i rinnovi partono abbastanza presto da garantire sempre almeno 15 giorni di margine.

4. Avvisi: Prima, non dopo#

La domanda: Le persone giuste vengono avvisate prima — non dopo — la scadenza del certificato?

L’avvisistica fa la differenza tra un non-evento e un incidente. Quando un rinnovo del certificato fallisce, devono accadere due cose: il sistema riprova automaticamente (vedi sezione 3) e la persona giusta ne viene informata. Se il tuo monitoraggio rileva un certificato scaduto senza avvisare nessuno, c’è comunque un vuoto — stai solo venendo a saperlo più velocemente.

L’avvisistica dovrebbe essere scalata in base a gravità e pubblico. Un rinnovo fallito che riesce dopo 30 minuti non ha bisogno di una chiamata alle 2:00 — ma dovrebbe comparire in un riepilogo giornaliero. Un certificato che si avvicina alle ultime 72 ore senza un rinnovo riuscito è un avviso critico che deve raggiungere immediatamente l’ingegnere in reperibilità.

Auto-valutazione dello stato attuale: Chi viene avvisato quando un certificato sta per scadere? Esiste un sistema di avvisi scalato con livelli di gravità diversi? Gli avvisi vanno ai canali giusti (Slack, email, PagerDuty) in base all’urgenza? Se la persona primaria in reperibilità non è disponibile, l’avviso viene inoltrato/escalato?

Stato target: Avvisistica su tre livelli: Info (tentativo di rinnovo, riepilogo giornaliero), Warning (rinnovo fallito, finestra di 7 giorni, Slack/email), Critical (rinnovo fallito ripetutamente, finestra di 72 ore, escalation PagerDuty/in reperibilità). Gli avvisi includono il nome del dominio, la data di scadenza del certificato, l’ora dell’ultimo tentativo di rinnovo e il motivo del fallimento. Ogni dominio nel portafoglio è coperto — nessuna eccezione, niente “lo monitoreremo manualmente quello”.

5. Certificati wildcard: comodità vs. rischio#

La domanda: I certificati wildcard vengono gestiti correttamente o creano punti singoli di fallimento?

I certificati wildcard sono allettanti: un certificato per *.example.com copre ogni sottodominio. Un solo rinnovo. Una sola data di scadenza. Una sola cosa da gestire. Ma quella “singola cosa da gestire” è anche una singola cosa che può fallire — e quando succede, ogni sottodominio va giù simultaneamente.

Per l’infrastruttura di redirect in particolare, i wildcard creano un altro problema: le challenge DNS-01 per i certificati wildcard richiedono l’accesso alla zona DNS del dominio apex. Se i tuoi domini di redirect sono distribuiti tra più registrar e provider DNS — cosa comune in portafogli di grandi dimensioni — gestire le challenge DNS-01 per un singolo wildcard diventa significativamente più complesso che gestire certificati per singolo hostname.

Autovalutazione dello stato attuale: Stai usando certificati wildcard per i domini di redirect? Se il certificato wildcard non riesce a rinnovarsi, a quanti domini è impattato? Hai un piano di rollback testato? I wildcard sono gestiti dallo stesso team che gestisce i certificati per dominio, oppure sono processi separati con responsabili diversi?

Stato target: I certificati per singolo hostname sono l’impostazione predefinita. Ogni dominio ha il proprio certificato, fornito e rinnovato in modo indipendente. Questo offre isolamento: un fallimento del rinnovo su un dominio non influisce su nessun altro. I wildcard vengono usati solo quando è esplicitamente necessario (ad es. servizi interni dietro un sottodominio condiviso), con monitoraggio e alerting separati — e una procedura di recupero documentata e testata.

6. Disaster Recovery: Quando la CA va giù#

La domanda: Se la tua Certificate Authority è indisponibile per 5 giorni, i tuoi certificati sopravvivono?

Let’s Encrypt ha già sperimentato blackout della durata di diverse ore. Con durate dei certificati di 90 giorni, un’interruzione di 2-3 giorni era gestibile — i certificati avevano abbastanza validità residua per superarla. Con 45 giorni, la stessa interruzione può spingere i certificati oltre la finestra di rinnovo prima che la CA torni online.

Il disaster recovery per SSL non riguarda solo la CA. Riguarda il DNS: se il tuo provider DNS ha un outage durante una finestra di challenge DNS-01, la challenge fallisce e il rinnovo viene bloccato. Riguarda anche la propagazione verso l’edge — se un certificato rinnovato non si propaga a tutti i nodi edge prima della scadenza del vecchio, alcuni utenti vedono errori. E riguarda anche la pipeline di rinnovo in sé — se la tua piattaforma di automazione ha un outage, i rinnovi vanno in coda o vengono scartati?

Autovalutazione dello stato attuale: Hai modellato cosa succede durante un outage della CA di 5 giorni? Qual è la tua finestra minima di validità del certificato nell’intero portafoglio? Hai una CA di fallback configurata, oppure tutti i certificati sono collegati a un singolo provider? La tua infrastruttura DNS può sopravvivere a un outage durante una finestra di challenge?

Stato target: I certificati vengono rinnovati in anticipo a sufficienza perché ogni dominio mantenga almeno 15 giorni di margine — abbastanza per superare un outage realistico della CA. La pipeline di rinnovo è resiliente: se un rinnovo fallisce a causa dell’indisponibilità della CA, il sistema riprova automaticamente quando la CA torna operativa. Il monitoraggio copre l’intera catena di dipendenze (DNS, CA, propagazione verso l’edge), non solo le date di scadenza dei certificati. Le CA di fallback sono configurate per i domini critici e il team dispone di un runbook documentato e testato per fornire manualmente i certificati durante outage prolungati della CA.

Autovalutazione: Valuta la tua prontezza#

Valuta la tua infrastruttura in ciascuno dei sei domini qui sotto. Sii onesto: un punteggio basso non è un fallimento, è una roadmap.

Punteggio: 1 = Manuale / Nessuna capacità, 2 = Parzialmente automatizzato / Mancanze presenti, 3 = Per lo più automatizzato / Piccole lacune, 4 = Completamente automatizzato / Nessuna lacuna, 5 = Completamente automatizzato + testato / Resiliente

Interpretazione del tuo totale:

24-30: Sei pronto. La tua infrastruttura è automatizzata, monitorata e resiliente. Concentrati sul mantenere questo stato e testare regolarmente le procedure di ripristino.

18-23: Hai solide basi, ma restano delle lacune. Dai priorità ai domini “Critici” per primi: automazione e tempistiche di rinnovo sono i miglioramenti con il miglior ritorno. Una timeline di 45 giorni metterà sotto stress la tua configurazione attuale.

12-17: La tua infrastruttura non è pronta per certificati di 45 giorni. I processi manuali che funzionano a 90 giorni si romperanno a 45. Inizia con l’automazione (dominio ①) — se devi sistemare una sola cosa, rendi automatico il provisioning e il rinnovo dei certificati.

6-11: Sei ad alto rischio. Ogni dominio nel tuo portafoglio è vulnerabile a un singolo promemoria di calendario mancato o a un’interruzione della CA. Valuta il passaggio a una piattaforma di redirect che gestisce l’automazione SSL come infrastruttura — non come un’attività — per colmare rapidamente il gap.

Il divario si allarga solo#

L’era dei certificati di 45 giorni non è una possibilità futura: è una traiettoria di settore con una tempistica definita. Let’s Encrypt, che rilascia certificati per oltre 360 milioni di domini, sta guidando il cambiamento. La proposta del CA/Browser Forum di Google segue la stessa direzione. Lo standard si sta spostando e il divario tra infrastrutture automatizzate e manuali aumenta solo mentre la durata dei certificati si riduce.

I team che automatizzano ora non sentiranno il cambiamento. Vedranno i loro dashboard completare i rinnovi in tempo — 30 giorni prima, ogni volta, su ogni dominio — mentre altri si affannano per aggiornare i fogli di calcolo. La checklist qui sopra non è solo uno strumento di valutazione. È una roadmap per un’infrastruttura pronta per qualsiasi durata del certificato su cui si stabilirà il settore — 45 giorni, 30 giorni o meno.

Valuta la tua infrastruttura. Colma le lacune. L’era dei certificati di 45 giorni sta arrivando — i tuoi domini di redirect dovrebbero essere l’ultima cosa di cui preoccuparsi.