Monitoraggio dei certificati SSL: una guida pratica per il 2026

I certificati SSL scaduti rappresentano il disservizio più facilmente prevenibile del settore. Il certificato era valido ieri, il monitoraggio è rimasto in silenzio e stamattina ogni browser mostra la pagina di avviso rossa. I rinnovi automatici falliscono più spesso di quanto si ammetta e un certificato Let's Encrypt da 90 giorni lascia un margine ristretto per un job di rinnovo non andato a buon fine. Questa guida spiega come funziona realmente il monitoraggio SSL, su cosa impostare gli avvisi e come evitare che i certificati ti creino problemi.

Perché i disservizi SSL continuano a verificarsi nell'era del rinnovo automatico

Il rinnovo automatico non ha risolto il problema della scadenza SSL. Ha solo cambiato il punto in cui si verifica il fallimento. Il job di certbot o acme.sh viene eseguito, ma il nuovo certificato non viene mai caricato da nginx perché la fase di reload è stata disattivata. L'ingress di Kubernetes effettua il rinnovo, ma il segreto non viene mai propagato a un pod che continua a servire il vecchio certificato. Un certificato SAN multi-dominio viene rinnovato, ma uno degli hostname è stato rimosso dalla richiesta e ora serve un certificato alternativo scaduto.

Il monitoraggio esterno individua tutti questi casi perché non si fida del tuo stato interno. Vede ciò che vede un vero browser: il certificato servito sull'hostname pubblico, sulla porta pubblica, presentato nell'handshake TLS in tempo reale. Se non viene servito il certificato corretto, il monitor lo sa, indipendentemente da ciò che dicono i log dei tuoi cron.

Cosa controlla effettivamente un monitor SSL

Un monitor SSL ben costruito esegue sei operazioni a ogni sonda. La maggior parte degli strumenti porta in superficie solo alcune di queste come avvisi e nasconde le altre.

• Giorni alla scadenza, la metrica principale, esposta con una finestra di preavviso configurabile.
• Corrispondenza dell'hostname, in modo che un certificato valido per example.com ma servito su api.example.com attivi immediatamente un avviso.
• Validazione della catena del certificato, per individuare i certificati intermedi mancanti che funzionano su alcuni browser ma falliscono su mobile.
• Rilevamento di certificati autofirmati e di emittenti non attendibili per gli ambienti di staging che si ritrovano accidentalmente con un certificato reale.
• Versione TLS, in modo che i protocolli deprecati (TLS 1.0, TLS 1.1) vengano segnalati prima che i browser li dismettano del tutto.
• Elenco dei Subject Alternative Name, utile per i certificati SAN che durante il rinnovo perdono silenziosamente un hostname.

Come impostare finestre di preavviso che funzionino davvero

Una finestra di preavviso di 7 giorni è troppo breve. Una finestra di 90 giorni provoca affaticamento da allerta. I valori che funzionano nella pratica sono 30 giorni per il primo avviso e 7 giorni per un'escalation.

30 giorni sono sufficienti per scoprire che il tuo job di rinnovo è fallito silenziosamente per settimane, individuare il problema di fondo e distribuire un nuovo certificato senza farsi prendere dal panico. 7 giorni è il punto in cui il tuo on-call dovrebbe ricevere un page indipendentemente dall'ora del giorno. Se puoi avere un solo avviso, quello tardivo è più utile, perché quello anticipato tende a essere confermato e poi dimenticato.

Abitudini operative comuni che prevengono i disservizi SSL

Tre abitudini, in ordine di priorità, terranno SSL fuori dai tuoi report sugli incidenti.

• Monitora ogni hostname pubblico individualmente. Il certificato wildcard non sostituisce il monitoraggio di ogni sottodominio che lo utilizza, perché qualsiasi cosa che serva il certificato sbagliato (un proxy mal configurato, una cache CDN obsoleta) non verrà rilevata in un controllo wildcard.
• Testa il percorso di rinnovo a intervalli regolari. Una simulazione mensile che esegue il rinnovo in staging è molto meno costosa che scoprire a 90 giorni che il processo di rinnovo si è deteriorato.
• Collega gli avvisi SSL allo stesso canale delle notifiche di deploy. I bug SSL si ricollegano quasi sempre a un deploy che ha modificato il percorso del certificato, il comando di reload o il nome del segreto.

Quando l'automazione non basta

Tre situazioni richiedono un intervento umano e nessuna automazione può eliminarle.

Primo, un trasferimento di dominio o cambio di registrar. Il processo di rinnovo si autentica con il vecchio registrar, fallisce silenziosamente e il certificato scade. Secondo, un cambio di provider CDN. La nuova CDN serve un certificato predefinito finché non carichi il tuo. Terzo, configurazioni multi-regione in cui il processo di rinnovo gira in una regione ma il certificato deve essere distribuito in tutte. Il monitoraggio SSL rileva tutti e tre i casi a livello di sintomo (certificato errato servito) prima che lo faccia il cliente.

Mettiamo tutto insieme

Aggiungi un monitor SSL per ogni hostname pubblico che possiedi. Imposta l'avviso a 30 giorni. Indirizza l'avviso allo stesso canale dove arrivano le notifiche di deploy. Aggiungi un'escalation a 7 giorni che notifichi il reperibile. Esegui una simulazione di rinnovo ogni mese. Con queste quattro misure in atto, SSL smette di essere un tipo di incidente ricorrente.