Monitoraggio dei certificati SSL: avvisi di scadenza per certificati e domini

Un certificato SSL scaduto non è l'unica scadenza che può mettere un sito offline - il controllo scadenza dominio di HostTracker monitora lo stato della tua registrazione insieme ai tuoi certificati, senza costi aggiuntivi.

Un monitor di scadenza dei certificati SSL viene spesso presentato come un semplice promemoria in calendario, e la scadenza è davvero il modo più comune in cui i certificati si rompono. Ma non è l'unico. Ogni esecuzione di HostTracker apre una vera connessione TLS e valuta il certificato effettivamente servito dal server - il che permette di individuare i guasti che si presentano senza che alcuna data cambi affatto.

Dietro le quinte, un monitor di certificati è una connessione TLS verso un host e una porta. La porta predefinita è 443, e puoi specificarne una diversa - example.com:8443 - così un gateway API, una porta HTTPS alternativa o un servizio su una porta TLS implicita vengono monitorati esattamente allo stesso modo. L'hostname viene inviato tramite SNI, così un server che ospita più certificati su un unico indirizzo IP restituisce quello giusto.

Quando un server va giù, un visitatore vede un errore del browser e di solito riprova più tardi. Quando un certificato scade, il server è ancora perfettamente funzionante - risponde a ogni richiesta - ma il browser si rifiuta di mostrare ciò che ha inviato. La differenza conta in quattro modi facili da sottovalutare finché non accade davvero.

• L'avviso è pensato per essere spaventoso. Un'interstiziale a schermo intero su una connessione non sicura è la stessa schermata che un browser mostra per un tentativo di intercettazione. I visitatori non la leggono come "il loro certificato è scaduto"; la leggono come "questo sito non è sicuro".
• Su un sito con HSTS attivo non c'è via d'uscita. Se hai mai inviato un'intestazione Strict-Transport-Security - e dovresti averlo fatto - i browser rimuovono del tutto l'opzione "procedi comunque". Ogni visitatore viene bloccato senza possibilità di aggirare l'avviso finché il certificato non viene sostituito.
• Le macchine falliscono più duramente delle persone. La tua app mobile, i tuoi webhook di pagamento, le integrazioni dei tuoi partner e ogni client API convalidano anch'essi il certificato, e nessuno di loro ha un pulsante da cliccare per andare oltre. Una scadenza è un'interruzione completa delle integrazioni, non solo del sito web.
• Il tuo stesso monitoraggio può apparire verde. Un controllo configurato per ignorare i problemi dei certificati continua a segnalare HTTP 200 da un server il cui certificato è scaduto un'ora fa. L'applicazione non se n'è accorta. È esattamente il divario che un monitor di certificati esiste per colmare.

La stessa asimmetria si applica a un dominio scaduto, solo più lentamente e in modo meno reversibile: un certificato può essere riemesso in pochi minuti, mentre un dominio che esce dal periodo di redenzione può essere registrato da chiunque.

Il controllo dei certificati si presenta in due forme, e la maggior parte degli account vuole la prima.

Un certificato non cambia da un minuto all'altro, quindi nessuna delle due forme controlla più spesso di quanto sia utile. Sei ore significa che, nel caso peggiore, il tempo tra la rottura di un certificato e il momento in cui HostTracker se ne accorge è di poche ore, su qualcosa che normalmente ti dà 30 giorni di preavviso.

HostTracker invia avvisi di promemoria a 30 giorni, 7 giorni e 1 giorno prima di una data di scadenza - sia per i certificati SSL/TLS sia per le registrazioni di dominio. Tre gradini invece di uno, perché ciascuno intercetta un tipo diverso di mancanza: 30 giorni sono un anticipo sufficiente per emettere un ordine di acquisto o riparare un job di rinnovo interrotto, 7 giorni intercettano il ticket che nessuno ha preso in carico, e 1 giorno è l'ultima chiamata prima che i browser inizino ad avvisare i tuoi visitatori.

Un promemoria non è un avviso di interruzione, e HostTracker mantiene i due concetti separati. Se il certificato è realmente invalido in questo momento - scaduto, revocato, collegato a una radice non attendibile o emesso per un hostname diverso - si tratta di un controllo fallito, che viene inoltrato ai tuoi normali contatti di allerta down secondo il ritardo scelto da ciascuno: immediatamente, oppure dopo 3, 5, 15, 30 o 60 minuti, o 3, 6, 12 o 24 ore.

Gli avvisi vengono inviati sui nove canali supportati da HostTracker - email, SMS, chiamata vocale, webhook, Slack, web push e le app di messaggistica Telegram, Discord e Viber. I rinnovi dei certificati e i rinnovi dei domini sono di solito gestiti da persone diverse, quindi metti entrambe nell'elenco dei contatti: il promemoria che raggiunge solo la casella di posta di chi ha configurato il monitor è il promemoria che finisce per essere ignorato.

La scala qui sopra è esattamente ciò che in pratica è un tracciamento della scadenza dei certificati SSL. Ogni sei ore HostTracker rilegge il certificato che il tuo server ha davvero servito e ricalcola i giorni che restano; a tre di quei numeri è agganciato un promemoria.

I tre gradini sono fissi a 30, 7 e 1 giorno, e la stessa scala vale per le registrazioni dei domini oltre che per i certificati. Un promemoria è informativo e da solo non porta mai un monitor in Down; un certificato davvero non valido - scaduto, revocato, emesso per un altro nome host o agganciato a una radice non attendibile - è un controllo fallito ed esegue l’escalation come qualsiasi altro disservizio.

Non stai ancora monitorando? Il controllo SSL istantaneo gratuito legge lo stesso certificato e riporta la stessa data di scadenza, lo stesso emittente, la stessa catena e la stessa versione TLS negoziata: una volta sola, adesso, senza account. Il tracciamento della scadenza è quel controllo in un ciclo di sei ore, con i tre promemoria agganciati.

Il monitor di certificati descritto sopra risponde alla domanda "questo certificato è valido". Un insieme separato di interruttori su un monitor di disponibilità HTTPS risponde a una domanda più difficile - "questa connessione è all'altezza del nostro standard" - e ciascuno è opzionale, perché attivarli tutti per ogni cliente farebbe fallire moltissimi siti che funzionano esattamente come i loro proprietari intendono.

• Richiedi una catena di certificati valida. Disattivato per impostazione predefinita, così un certificato autofirmato su un host interno non fa fallire il suo controllo di uptime. Attivalo per qualsiasi cosa pubblica.
• Richiedi un protocollo TLS robusto. Fa fallire il controllo quando il server negozia qualcosa al di sotto di TLS 1.2 - l'interruttore utile dopo un progetto di hardening, così una configurazione ripristinata non può reintrodurre silenziosamente un protocollo obsoleto.
• Blocca i cifrari deboli. Fa fallire il controllo quando il cifrario negoziato è più debole di 128 bit.
• Verifica la revoca del certificato. Aggiunge una verifica OCSP/CRL al controllo di disponibilità stesso.

Un monitor di scadenza certificati autonomo applica già da solo la convalida della catena e il controllo di revoca, senza nessuno di questi interruttori - questi esistono affinché il tuo controllo di uptime possa essere reso rigoroso quanto richiede la tua politica di sicurezza, indipendentemente da ciò che riporta il monitor di certificati.

Il rinnovo automatico doveva porre fine agli incidenti di scadenza, e in gran parte lo ha fatto. Ciò che è cambiato è la forma di quelli rimasti: invece di una persona che dimentica una data, è un pezzo di automazione che smette di funzionare senza che nessuno se ne accorga, perché un'automazione funzionante è silenziosa e un'automazione rotta è silenziosa esattamente allo stesso modo. La durata dei certificati continua a diminuire in tutto il settore - le autorità gratuite più diffuse emettono certificati validi 90 giorni, e la durata massima accettata dai browser viene ridotta a fasi - il che significa che il rinnovo avviene ormai molte volte l'anno, e ognuno di questi rinnovi può essere quello che fallisce.

I guasti che vediamo segnalati assomigliano a questi:

• Il job cron di rinnovo è morto mesi fa. L'ultimo certificato rinnovato era valido 90 giorni, quindi il guasto è diventato visibile solo al giorno 91.
• Il rinnovo è riuscito, ma nulla è stato ricaricato. Il nuovo certificato resta sul disco mentre il server web, il load balancer o il container continuano a servire quello vecchio dalla memoria. Ogni log di rinnovo dice successo.
• Un nodo su più è stato dimenticato. Dietro un load balancer, la maggior parte delle richieste riceve il nuovo certificato e una frazione riceve quello scaduto - motivo per cui un errore di certificato intermittente del tipo "funziona per me" è quasi sempre un problema di coerenza tra i nodi della flotta.
• Il bordo (edge) va bene, l'origine no. La tua CDN presenta il proprio certificato valido mentre quello dell'origine, sotto di essa, è scaduto. Qualsiasi cosa parli direttamente con l'origine si rompe.
• Il metodo di convalida ha smesso di funzionare. Un record DNS è stato riordinato, un percorso /.well-known/ ha iniziato a reindirizzare, una regola del firewall è cambiata - e il rinnovo che dipende da essa ha smesso silenziosamente di andare a buon fine.
• Il wildcard non copriva il nuovo sottodominio. Un certificato wildcard copre un solo livello, quindi un host aggiunto sotto un'etichetta più profonda non è affatto coperto.

Ognuno di questi è invisibile dall'interno della tua stessa pipeline di deployment ed evidente dall'esterno, il che è l'intera ragion d'essere di un osservatore esterno. Un monitor che si connette come farebbe il browser di uno sconosciuto vede il certificato che stai effettivamente servendo - non quello che la tua automazione crede di aver installato.

Il lato dominio interroga il registro anziché il server. HostTracker cerca il dominio tramite RDAP - il successore moderno e strutturato di WHOIS - risolvendo quale registro risponde per il tuo TLD a partire dalla directory pubblicata dalla stessa IANA, e ricade su una classica query WHOIS sulla porta 43 per i TLD che non pubblicano ancora un servizio RDAP. La ricerca viene eseguita con una cadenza fissa di sei ore, e il controllo riporta:

• la data di scadenza detenuta dal registro - quella ufficiale, non quella nel tuo sistema di fatturazione;
• i codici di stato del registro sul dominio, dove RDAP li fornisce - incluso se è attivo un blocco dei trasferimenti;
• un avviso separato di "data di scadenza cambiata" ogni volta che la data del registro differisce dal controllo precedente - è così che confermi che un rinnovo è effettivamente andato a buon fine, ed è così che scopri di uno che non hai autorizzato.

Quest'ultimo è, silenziosamente, il segnale più utile della pagina. Un rinnovo che hai pagato ma che non è mai arrivato al registro appare identico a un dominio sano fino a quando non scatta il promemoria dei 30 giorni. Osservare il cambiamento della data stessa trasforma il rinnovo da qualcosa che speri sia accaduto in qualcosa che puoi vedere.

Vuoi il record completo del registro - registrar, nameserver, data di creazione - subito invece che come monitor? Esegui la ricerca WHOIS e scadenza dominio gratuita; senza bisogno di accesso. Il monitor ricorrente riporta deliberatamente meno informazioni, perché ciò che cambia è la scadenza e lo stato.

1. Cerca prima il dominio con il controllo istantaneo gratuito, così conosci le date di scadenza odierne prima di automatizzare qualsiasi cosa.
2. Se già monitori l'uptime del sito, apri quel monitor e attiva il controllo dei certificati e il controllo della scadenza del dominio. Nessun nuovo monitor, nessuna richiesta extra.
3. Per qualsiasi cosa tu non monitori per l'uptime - un host di posta, un gateway interno, una porta alternativa - aggiungi un monitor autonomo Scadenza certificato e dagli host:porta. La porta 443 è assunta se non ne specifichi una.
4. Aggiungi un monitor Scadenza dominio per ogni dominio registrabile che possiedi, incluse le registrazioni difensive e i domini di reindirizzamento. Sono esattamente quelli che scadono, perché nessuno controlla un dominio che non ha un sito sopra.
5. Metti più di una persona nell'elenco dei contatti. Certificati e domini sono di solito gestiti da team diversi, e il promemoria che raggiunge solo la persona che ha configurato il monitor è quello che resta inosservato quando quella persona cambia lavoro.
6. Prendi nota della scala dei promemoria - 30, 7 e 1 giorno - e assicurati che il tuo processo di rinnovo rientri in 30 giorni. Se un ordine di acquisto richiede sei settimane, il vincolo non è la scala dei promemoria; è il processo.

Gli strumenti gratuiti di controllo SSL - incluso quello di HostTracker - sono davvero utili e rispondono a una domanda diversa. Uno strumento di controllo ti dice lo stato di un certificato nel momento in cui lo interroghi. Il monitoraggio ti dice quando quello stato cambia mentre non stai guardando, che è l'unico momento in cui conta davvero.

I certificati si affiancano alle altre cose che possono andare storte in un dominio senza che nessuno tocchi il tuo server. Una volta che il lato scadenza è monitorato, i due successivi più comuni sono le segnalazioni di malware e phishing e le presenze in blacklist DNS - entrambi guasti silenziosi di reputazione che lasciano il sito attivo ma il traffico sparito.

• Nessun STARTTLS. Il controllo si connette e avvia immediatamente l'handshake TLS, quindi funziona su qualsiasi porta che parla TLS direttamente. I protocolli che iniziano in chiaro e passano a TLS a metà sessione - SMTP sulla 587, IMAP sulla 143, FTP con TLS esplicito - richiedono una negoziazione che il controllo non esegue. Puntalo invece sulla porta a TLS implicito.
• I giorni di promemoria sono fissi a 30, 7 e 1. Al momento non sono un'impostazione configurabile per singolo monitor.
• Un responder di revoca irraggiungibile viene segnalato, non fatto fallire. È intenzionale - l'interruzione del servizio OCSP di un'autorità di certificazione non è un'interruzione del tuo sito - ma significa che la copertura della revoca dipende dal fatto che una terza parte sia attiva.
• I log di Certificate Transparency non vengono monitorati. HostTracker ti informa sul certificato effettivamente servito; non controlla i log CT pubblici per certificati emessi per il tuo dominio da qualcun altro.
• I certificati client non vengono utilizzati. Il controllo convalida il certificato presentato dal server, non un handshake mutual-TLS.
• La copertura dei domini segue i registri. RDAP viene usato dove il TLD lo pubblica e il classico WHOIS dove non lo pubblica; un piccolo numero di TLD poco comuni non pubblica bene nessuno dei due, e il controllo segnala un errore di ricerca invece di fingere di conoscere una data.