7 errori da evitare nel rinnovo dei certificati SSL
Pubblicato il 16 luglio 2026
Un certificato può essere rinnovato con successo e comunque mandare offline il tuo sito. Questa è la parte scomoda degli errori nel rinnovo dei certificati SSL: l'avviso di rinnovo può scomparire, mentre i visitatori vedono un avviso del browser perché il nuovo certificato non è mai stato distribuito, non corrisponde alla chiave privata oppure non viene servito da ogni endpoint.
Tratta il rinnovo come una modifica controllata in produzione, non come un'attività di calendario. Controlla il certificato, il metodo di convalida, la configurazione del server e il risultato pubblico. Di solito si tratta di una procedura breve. Saltare un piccolo controllo, tuttavia, può trasformare la mattinata del tuo team in un incubo molto lungo.
1. Tenere traccia della data di scadenza nel calendario di una sola persona
Un promemoria manuale è meglio di nessun promemoria, ma è fragile. Le persone cambiano ruolo, le caselle di posta condivise vengono trascurate e un certificato può coprire un dominio che non fa più parte del normale processo di rinnovo. I certificati possono anche avere periodi di validità più brevi di quanto i team si aspettino, specialmente quando vengono usati in più servizi.
Usa un monitoraggio della scadenza che avvisi più di una persona o di un team responsabile. Una pianificazione utile prevede un primo avviso 30 giorni prima della scadenza, un avviso più forte a 14 giorni e un'escalation operativa a sette giorni. Per i domini business-critical, monitora il certificato presentato pubblicamente sulla porta 443, non solo la data di scadenza registrata in un portale.
Questa distinzione è importante. Il fornitore del tuo certificato può mostrare un certificato rinnovato valido, mentre internet continua a ricevere quello vecchio da un load balancer, una CDN, un reverse proxy o un server secondario.
2. Supporre che il rinnovo automatico significhi distribuzione automatica
Il rinnovo automatico è eccellente, ma ha dei limiti. Molti strumenti basati su ACME possono richiedere e scaricare un nuovo certificato senza installarlo automaticamente in ogni servizio che usa TLS. Nginx, Apache, HAProxy, i server di posta, i controller ingress di Kubernetes e gli application proxy possono richiedere ciascuno un reload, un riavvio o un aggiornamento della configurazione.
Dopo il rinnovo, verifica a quali file fa effettivamente riferimento il servizio. Un problema comune è che lo strumento di rinnovo scriva il nuovo certificato in una directory mentre la configurazione del server web punta ancora a un percorso meno recente. Un altro è un rinnovo riuscito seguito da un reload non riuscito a causa di un errore di configurazione non correlato.
Per un singolo VPS, può essere semplice come convalidare la configurazione e ricaricare con garbo il server web. In un ambiente più grande, fai della distribuzione parte del flusso di lavoro di rinnovo: rinnova, distribuisci, ricarica, poi testa dall'esterno della rete. I log stanno raccontando la stessa storia solo ora, quando l'endpoint pubblico lo conferma.
3. Interrompere la convalida del dominio prima del giorno del rinnovo
La convalida del controllo del dominio è il punto in cui molti rinnovi falliscono. La convalida HTTP-01 richiede che l'autorità di certificazione raggiunga uno specifico file di verifica tramite il web pubblico. La convalida DNS-01 richiede il record TXT corretto. Entrambi i metodi sono affidabili quando l'infrastruttura circostante rimane stabile.
I problemi compaiono dopo una migrazione del sito web, un cambio di provider DNS, una nuova regola della CDN o una policy di sicurezza che blocca percorsi sconosciuti. Una regola di reindirizzamento può inviare la richiesta di convalida in un punto imprevisto. Un web application firewall può respingerla. I record DNS possono essere gestiti in un account mentre il server è gestito in un altro, che non è la situazione DNS più elegante, ma è sotto controllo una volta che la proprietà è chiara.
Controlla il metodo di convalida molto prima della scadenza del certificato. Se usi HTTP-01, conferma che il percorso `/.well-known/acme-challenge/` possa essere raggiunto pubblicamente e non venga intercettato da un'applicazione o da un proxy. Se usi DNS-01, conferma che le credenziali di automazione abbiano ancora il permesso di creare i record richiesti e che il tempo di propagazione del tuo provider DNS rientri nella tua finestra di rinnovo.
I certificati wildcard meritano un'attenzione speciale. In genere richiedono la convalida DNS, quindi un rinnovo dell'ultimo minuto può diventare difficile se la persona che ha l'accesso DNS non è disponibile.
4. Rinnovare il certificato sbagliato per i domini che usi davvero
Un certificato non protegge un server in generale. Protegge i nomi esatti elencati nel suo campo Subject Alternative Name, o SAN. Rinnovare `example.com` non coprirà automaticamente `www.example.com`, `api.example.com`, `shop.example.com` o un sottodominio cliente usato da un'applicazione.
Prima del rinnovo, fai l'inventario di ogni hostname servito dal certificato. Includi reindirizzamenti, API, pannelli di amministrazione, ambienti di staging esposti a internet pubblico e servizi correlati alla posta se usano lo stesso certificato. Anche le agenzie dovrebbero controllare i domini white-label e i domini dei clienti che potrebbero essere stati aggiunti nel corso dell'anno.
Fai attenzione ai certificati wildcard. Un wildcard come `*.example.com` copre un livello di sottodomini, come `app.example.com`. Non copre `api.eu.example.com` e non include automaticamente il dominio apex `example.com`. Aggiungi esplicitamente i nomi di cui hai bisogno e testali singolarmente.
5. Riutilizzare la chiave privata sbagliata o mescolare i file del certificato
Un certificato TLS e la sua chiave privata sono una coppia corrispondente. Se un nuovo certificato viene installato con una vecchia chiave privata non correlata, il servizio può non avviarsi o presentare una configurazione non valida. Questo accade più spesso quando i file vengono copiati manualmente tra server o quando diversi certificati hanno nomi simili.
C'è anche la catena del certificato. I browser hanno bisogno del certificato del server più i certificati intermedi appropriati. Se il file della catena è incompleto, alcuni visitatori possono vedere errori di attendibilità mentre altri sembrano non essere interessati a causa di intermedi memorizzati nella cache o di archivi di attendibilità diversi sui dispositivi. Questa non è una distribuzione riuscita. È un ticket di supporto ritardato.
Conserva i file del certificato in una posizione prevedibile con permessi e proprietà chiari. Usa una convenzione di denominazione documentata, soprattutto dove più domini condividono un host. Prima di ricaricare il servizio, conferma i dettagli del certificato, la corrispondenza della chiave privata e la catena completa prevista dal tuo server web.
6. Aggiornare un server mentre il traffico ne raggiunge diversi
Un sito web pubblico può avere più endpoint TLS del previsto. Il traffico può passare attraverso una CDN, un load balancer cloud, un IP di failover, un reverse proxy, più nodi applicativi o server distribuiti geograficamente. Se solo un endpoint riceve il certificato rinnovato, il problema può sembrare intermittente agli utenti.
Questo è uno degli errori nel rinnovo dei certificati SSL che causa più confusione. Un tecnico testa il server principale e vede un certificato valido. Un cliente raggiunge un altro nodo e vede un avviso di scadenza. Entrambe le osservazioni possono essere vere.
Mappa il percorso completo della richiesta prima di rinnovare. Identifica dove termina TLS e quali sistemi possono rispondere per l'hostname. Se TLS termina in una CDN o in un load balancer, rinnovare il certificato sul server origin potrebbe non cambiare ciò che ricevono i visitatori. Se anche i server origin accettano traffico diretto, hanno bisogno anch'essi di certificati validi.
Per i sistemi clusterizzati, distribuisci tramite configuration management o una pipeline orchestrata invece di copiare i file nodo per nodo. Poi testa ripetutamente da reti esterne o da postazioni di monitoraggio. Un controllo dall'interno della stessa rete privata è utile, ma non dimostra che il percorso pubblico sia corretto.
7. Rinnovare senza test, monitoraggio o un piano di rollback
Il processo di rinnovo non è completo quando il comando restituisce un messaggio di successo. È completo quando un controllo TLS pubblico conferma l'hostname corretto, la data di scadenza, la catena del certificato e la risposta dell'endpoint.
Testa immediatamente dopo la distribuzione. Conferma che il servizio presenti il certificato previsto, che la catena sia valida e che la tua applicazione resti raggiungibile tramite HTTPS. Per e-commerce, SaaS ed endpoint di login, esegui anche un breve controllo funzionale. Un certificato valido aiuta poco se un reload ha lasciato l'applicazione dietro una risposta 502.
Tieni disponibile il precedente certificato e la configurazione sicuramente funzionanti finché la verifica non è terminata. Potresti non aver mai bisogno di un rollback, ma la possibilità di ripristinare rapidamente uno stato funzionante è più rassicurante che ricostruire la modifica sotto pressione. Registra che cosa è stato rinnovato, dove è stato installato, chi lo ha verificato e quando dovrà scattare il prossimo avviso di monitoraggio.
Una routine di rinnovo più sicura
Una routine affidabile ha quattro fasi: prepararsi prima della scadenza, convalidare il controllo del dominio, distribuire a ogni endpoint TLS e verificare dall'esterno della propria infrastruttura. L'automazione può gestire gran parte di questo lavoro, ma richiede comunque monitoraggio e revisioni occasionali dopo modifiche a DNS, hosting o applicazione.
Se gestisci un VPS gestito o diversi ambienti cliente, affianca i controlli di scadenza e distribuzione dei certificati ai backup, al monitoraggio dell'uptime e alla manutenzione delle patch. Appartengono alla stessa categoria operativa: piccolo lavoro di routine che previene incidenti visibili e costosi.
Un avviso del certificato è molto visibile perché i browser sono progettati per proteggere gli utenti. Il tuo processo di rinnovo dovrebbe essere ugualmente protettivo: avvisi anticipati, proprietà chiare, automazione testata e un controllo umano quando l'infrastruttura cambia. Così il servizio resta tranquillo e i tuoi clienti possono continuare a lavorare senza essere introdotti all'entusiasmante mondo degli errori dei certificati.
Andres Saar Customer Care Engineer