Un processo affidabile per il rinnovo SSL senza interruzioni

Pubblicato il 18 ottobre 2026

Il processo di rinnovo SSL dovrebbe iniziare con largo anticipo rispetto alla scadenza del certificato, dopo aver già controllato l’inventario dei certificati, l’accesso DNS e il percorso di distribuzione. Il rinnovo di un certificato è solitamente una procedura di routine. Le interruzioni si verificano per ciò che gli sta intorno: un sottodominio dimenticato, un record di convalida aggiunto alla zona DNS sbagliata oppure un nuovo certificato installato su un server mentre il traffico continua a raggiungerne un altro.

Per un sito web in produzione, considera il rinnovo come una piccola modifica di manutenzione, con un piano di ripristino. Genera o richiedi il certificato sostitutivo, completa la convalida, installa l’intera catena di certificati, ricarica il servizio web interessato e verifica cosa ricevono effettivamente i visitatori esterni. Procedendo in questo modo, il servizio continua a funzionare senza problemi e i browser non hanno motivo di segnalare errori.

Cosa viene effettivamente rinnovato nel processo di rinnovo SSL

Un certificato SSL è il documento d’identità che il server presenta durante una connessione HTTPS. Conferma che i visitatori hanno raggiunto il dominio previsto e stabilisce una comunicazione crittografata tra il loro browser e il tuo sito.

Di norma, il rinnovo non comporta modifiche al sito web, all’applicazione o all’indirizzo IP del server. Significa sostituire il certificato esistente con uno nuovo prima della scadenza del precedente. I certificati TLS considerati attendibili pubblicamente hanno periodi di validità limitati, spesso non superiori a circa 398 giorni; molte organizzazioni scelgono durate più brevi o il rilascio automatizzato. La data indicata sul certificato non è un suggerimento del browser. Una volta superata, i visitatori possono visualizzare un avviso di scadenza anche se il sito funziona perfettamente.

Il metodo di rinnovo dipende dal tipo di certificato e dall’ente che lo rilascia. Un certificato a pagamento con convalida dell’organizzazione può richiedere una conferma tramite un’e-mail di approvazione, un record DNS o un file inserito nel sito web. I certificati automatizzati utilizzano comunemente la convalida ACME tramite HTTP o DNS. L’obiettivo operativo è lo stesso: dimostrare il controllo del dominio, ricevere il certificato e distribuirlo correttamente.

Inizia dall’inventario, non dall’e-mail di scadenza

Il primo compito consiste nell’individuare ogni endpoint che utilizza il certificato. Una singola azienda può avere il sito principale, la versione www, il portale clienti, l’API, il server di posta, l’ambiente di staging e il bilanciatore del carico che utilizzano certificati diversi. Un promemoria di scadenza relativo a un nome host non dimostra che anche tutti gli altri siano coperti.

Controlla i nomi alternativi del soggetto del certificato, solitamente chiamati SAN. Indicano i domini e i sottodomini inclusi nel certificato. Se `www.example.com` non è incluso, un certificato valido solo per `example.com` non lo proteggerà. I certificati jolly coprono i sottodomini di primo livello, come `shop.example.com`, ma non coprono automaticamente il dominio radice né nomi più profondi, come `eu.shop.example.com`.

Individua anche dove termina TLS. Per una VPS semplice, il certificato può risiedere direttamente in NGINX, Apache, Caddy o in un pannello di controllo dell’hosting. In una configurazione più articolata, il certificato potrebbe essere installato su un proxy inverso, una CDN, un bilanciatore del carico cloud, un controller di ingresso Kubernetes o diversi nodi dietro un bilanciatore del traffico. Rinnovare il certificato sul server applicativo non serve a nulla se il proxy che lo precede continua a presentare quello vecchio. A volte la configurazione DNS non è delle più eleganti, ma una volta mappato il percorso del traffico è tutto sotto controllo.

Imposta promemoria interni con un anticipo maggiore rispetto alla data di scadenza pubblica. Trenta giorni sono un intervallo ragionevole per un certificato semplice, mentre da 45 a 60 giorni offrono più margine quando sono coinvolti diversi team, provider DNS esterni o la convalida aziendale. Il monitoraggio dovrebbe inviare avvisi in più momenti, ad esempio a 30, 14, 7 e 3 giorni dalla scadenza. Un singolo promemoria via e-mail può finire nello spam, essere ignorato o essere inviato a qualcuno che ha lasciato l’azienda la primavera scorsa.

Scegli un metodo di convalida adatto alla tua infrastruttura

È durante la convalida del controllo del dominio che molti rinnovi si bloccano. L’autorità di certificazione deve avere la prova che controlli il dominio richiesto. Il metodo migliore è quello che il tuo team può ripetere in sicurezza.

La convalida HTTP richiede di inserire un file specifico in un URL pubblico specifico. È pratica quando il server web è direttamente raggiungibile sulla porta 80 e serve l’host virtuale corretto. Può non riuscire se il traffico viene reindirizzato in modo insolito, il sito si trova dietro un proxy restrittivo o un firewall blocca la richiesta di convalida.

La convalida DNS richiede un record TXT presso il provider DNS del dominio. Spesso è la scelta migliore per i certificati jolly e per i sistemi che non possono esporre un percorso di convalida HTTP. È adatta anche alle infrastrutture distribuite, ma occorre attendere la propagazione DNS. Alcune modifiche DNS diventano visibili in pochi secondi; altre richiedono più tempo a causa delle impostazioni TTL, del comportamento del provider e delle cache dei resolver. Non rimuovere un record di convalida finché il rilascio non è confermato.

La convalida tramite e-mail può funzionare in un ambiente piccolo e stabile, ma dipende maggiormente dall’accesso alla casella di posta e dagli indirizzi approvati. Se il contatto per la registrazione del dominio non è aggiornato o una casella di ruolo non viene più monitorata, il rinnovo si blocca a quel punto. Per i servizi critici per l’attività, la convalida DNS o ACME automatizzata riduce in genere i colli di bottiglia dovuti all’intervento umano.

Genera il certificato con attenzione

Per i certificati gestiti manualmente, genera una richiesta di firma del certificato, o CSR, usando il sistema in cui verrà conservata la chiave privata. La CSR contiene la chiave pubblica e i dettagli del dominio. La chiave privata deve rimanere privata. Non inviarla per e-mail, non inserirla nei ticket e non conservarla in un documento condiviso chiamato `final-final-use-this-one`.

Puoi riutilizzare una chiave esistente durante il rinnovo, ma in genere generare una nuova chiave privata è la scelta operativa più sicura. La rotazione delle chiavi limita l’impatto nel caso in cui una vecchia chiave sia stata esposta senza che nessuno se ne accorgesse. Il compromesso è semplice: una nuova chiave richiede una distribuzione attenta ovunque venga usato il certificato. Per la maggior parte delle installazioni su un singolo server, il lavoro aggiuntivo è minimo e ne vale la pena.

Dopo il rilascio, scarica il certificato del server e la catena dei certificati intermedi fornita dall’autorità di certificazione. I server web moderni richiedono spesso un file con la catena completa, che contenga il certificato finale e i certificati intermedi. La mancanza dei certificati intermedi è una causa classica degli errori di attendibilità del browser, soprattutto sui dispositivi meno recenti o con client meno diffusi.

I client ACME automatizzati possono gestire la generazione delle chiavi, la convalida, il rinnovo e gli hook di installazione. L’automazione è fortemente consigliata per i certificati che la supportano, ma richiede comunque monitoraggio. Un’attività di rinnovo automatico che non riesce ad accedere al DNS, scrivere nella directory dei certificati o ricaricare NGINX è automatica solo in un senso molto ottimistico.

Esegui la distribuzione senza interrompere l’esperienza dei visitatori

Prima di sostituire qualsiasi elemento, copia il certificato e la configurazione attuali in una posizione di backup protetta. Conserva il certificato precedente, il riferimento alla chiave e una configurazione sicuramente funzionante finché la nuova installazione non è stata verificata. In questo modo il team potrà ripristinare rapidamente la versione precedente se il file della catena, un’impostazione dei permessi o un dettaglio di sintassi non sono corretti.

Installa il nuovo certificato e la chiave privata corrispondente nella posizione prevista. Verifica che il processo del server web possa leggere i file senza rendere la chiave privata accessibile a tutti. Su Linux, la proprietà e i permessi restrittivi sono importanti. Un certificato è pubblico per definizione; la sua chiave privata no.

Convalida la configurazione del server web prima di ricaricarlo. Per NGINX, Apache, HAProxy e servizi simili, esegui prima il comando di test della configurazione del prodotto. Poi, quando possibile, ricarica il servizio invece di riavviarlo. Il ricaricamento applica l’aggiornamento del certificato e consente ai processi worker esistenti e alle connessioni attive di concludersi senza problemi. Un riavvio forzato può essere accettabile durante una finestra di manutenzione, ma non è necessario in molte configurazioni comuni.

Se il servizio è distribuito su più server, esegui la distribuzione in modo uniforme su tutti i nodi prima o durante una rotazione controllata. I bilanciatori del carico possono indirizzare richieste consecutive del browser verso backend diversi. Se solo un nodo ha il nuovo certificato, possono comparire avvisi intermittenti: un problema particolarmente fastidioso perché sembra immaginario, finché non si manifesta davvero.

Verifica dall’esterno del server

Non fermarti quando il pannello di controllo indica che l’installazione è riuscita. Verifica il certificato da una rete esterna e controlla il nome host utilizzato dai visitatori. Conferma il nome comune o la copertura SAN, l’ente che lo ha rilasciato, la data di scadenza e la catena di certificati. Se entrambi sono accessibili pubblicamente, controlla sia il nome host radice sia quello www.

Usa un browser come uno dei metodi di verifica, ma non affidarti solo a un browser. Potrebbe memorizzare nella cache le sessioni o le informazioni sulla catena. Esegui un test con un client TLS o un controllo di monitoraggio esterno che segnali il certificato presentato all’indirizzo IP pubblico. Negli ambienti avanzati, verifica che venga restituito il certificato corretto usando Server Name Indication, o SNI, per ciascun dominio ospitato.

Poi controlla il comportamento dell’applicazione: accedi, invia un modulo, chiama un endpoint API e verifica gli URL di callback di terze parti che usano HTTPS. Il rinnovo del certificato non dovrebbe modificare il comportamento dell’applicazione, ma le regole di convalida e del proxy a volte fanno emergere problemi di configurazione non correlati. Ora i log raccontano la stessa storia: sia il controllo esterno del certificato sia i test dell’applicazione hanno esito positivo.

Fai in modo che il prossimo rinnovo sia una routine

Il miglior processo di rinnovo SSL è quello che nessuno deve gestire in fretta. Documenta il responsabile del certificato, il metodo di rinnovo, il provider DNS, la posizione del servizio, i nomi host interessati e i passaggi per il ripristino. Conserva queste informazioni in un luogo accessibile al team operativo, non solo nella memoria di una persona.

Per i server gestiti, il monitoraggio dei certificati dovrebbe affiancarsi ai controlli di disponibilità, disco, backup e servizio. Una data di scadenza imminente è un segnale operativo, non una semplice attività amministrativa. Su kodu.cloud, questo tipo di manutenzione ricorrente si integra naturalmente con il supporto gestito e il monitoraggio: individua per tempo l’endpoint, rinnova con il metodo di convalida corretto e verifica il servizio attivo al termine.

Se il tuo certificato è prossimo alla scadenza, inizia controllando cosa viene attualmente presentato al pubblico, quindi procedi a ritroso tra DNS, convalida e configurazione del server. Di solito esiste un percorso chiaro per risolvere la situazione. Dedica al rinnovo il tempo necessario, verificalo dall’esterno e i visitatori noteranno soltanto che il sito continua a funzionare come dovrebbe.

Andres Saar, ingegnere del servizio clienti