SSL/TLS
Monitoraggio dei certificati SSL/TLS
Il certificato SSL/TLS che un host serve e quanti giorni mancano alla sua scadenza.
Provalo ora
Un controllo, da un solo posto, subito, e nulla viene salvato. Un monitor controlla da ogni posizione in cui operiamo e conferma un errore da altri due continenti prima che qualcuno venga svegliato, cosa che un singolo controllo non può mostrarti.
A cosa serve
La scadenza del certificato è l'interruzione che tutti hanno avuto e nessuno pianifica. Il rinnovo è automatico fino al giorno in cui l'automazione fallisce silenziosamente, e il primo segnale è che ogni browser al mondo rifiuta il tuo sito con NET::ERR_CERT_DATE_INVALID.
Questo apre una connessione TLS sulla porta 443, o dove indichi, e legge il certificato X.509 che l'host sta realmente servendo. Non è sempre quello scritto dal tuo job di rinnovo: un load balancer con un nodo obsoleto, un secondo host virtuale che nessuno ha ricaricato, una CDN che conserva la vecchia catena. Riporta il subject, l'autorità di certificazione emittente e la data notAfter, quindi un conto alla rovescia invece di un up o down.
I certificati wildcard e SAN sono un unico certificato, quindi controlla l'host da cui ciascuno viene effettivamente servito. Un certificato che copre *.example.com su tre load balancer richiede tre monitor, perché il problema è che uno dei tre non viene ricaricato.
Come ogni controllo qui, viene eseguito da Amsterdam, New York, Sydney and Singapore, e un errore viene confermato da altri due continenti prima che qualcuno venga svegliato. Come funziona.
Cosa puoi impostare
Tutto ciò che segue è nel modulo quando ne aggiungi uno, su ogni piano.
- Host
- Un hostname, un host e porta, o un URL: example.com, example.com:8443 e https://example.com funzionano tutti. Porta 443 a meno che non ne specifichi una.
Ricevi tre avvisi: a quattordici giorni, sette giorni e due giorni, ciascuno inviato una sola volta. I promemoria giornalieri vengono ignorati, quindi non si ripetono. I trenta giorni vengono saltati apposta: è quando Let's Encrypt rinnova, quindi scatterebbe su ogni certificato valido. Se il certificato è scaduto o non riusciamo a leggerlo (connessione rifiutata, handshake fallito, nessuna risposta), è un alert, non un avviso, e scatta nel momento in cui lo rileviamo.
Domande
Qual è la differenza tra un certificato SSL e un certificato TLS?
Niente, per questo scopo. SSL è il vecchio nome del protocollo, TLS è quello attuale, e SSL 2.0 e 3.0 sono morti da oltre un decennio. Il file stesso è comunque un certificato X.509 e non sa quale protocollo lo presenterà. La maggior parte delle persone cerca ancora SSL, quindi scriviamo SSL/TLS e intendiamo la stessa cosa che intendi tu.
Perché il mio browser dice NET::ERR_CERT_DATE_INVALID?
Il certificato consegnato al browser è scaduto o la sua data notBefore non è ancora arrivata, cosa che succede quando l'orologio del server è sbagliato. Chrome mostra questo codice, Firefox dice SEC_ERROR_EXPIRED_CERTIFICATE e Safari dice che il certificato non è valido. Questo monitor è ciò che te lo dice due giorni prima dei tuoi visitatori.
Questo controlla la catena del certificato?
Questo controllo legge la scadenza, quindi una catena incompleta o un certificato intermedio mancante non lo fa fallire. Un monitor HTTPS controlla la catena: si connette come farebbe un browser e fallisce su una catena non valida, un certificato autofirmato o un hostname non corrispondente. Usa entrambi su tutto ciò che conta, ed è per questo che HTTPS è su ogni piano.
E i certificati wildcard e SAN?
Entrambi funzionano. Un certificato wildcard, o uno con diversi subject alternative names, è un unico certificato con una sola data di scadenza. Ciò che varia è quale host lo sta servendo, quindi aggiungi un monitor per host invece di uno per nome sul certificato.
Controllate OCSP o la trasparenza dei certificati?
No, e lo diciamo chiaramente invece di implicare il contrario. Questo legge il certificato che un host serve e riporta i giorni rimanenti. Il controllo della revoca e il monitoraggio dei log CT sono prodotti diversi che risolvono problemi diversi, e un monitor che li facesse a metà sarebbe peggiore di uno che non li fa.
Il mio rinnovo è automatico. Mi serve comunque questo?
È esattamente per chi è pensato. Nessuno con un rinnovo manuale dimentica per novanta giorni di fila; le interruzioni derivano da un rinnovo Let's Encrypt che è fallito silenziosamente sei settimane fa, o è riuscito sulla macchina che scrive il certificato ma non su quella che lo serve.
E se l'host non risponde affatto?
Un fallimento dell'handshake TLS, una connessione rifiutata o un timeout vengono segnalati come un fallimento del controllo piuttosto che come un avviso di scadenza, perché sono problemi diversi con soluzioni diverse. Il conto alla rovescia della scadenza si muove solo quando leggiamo effettivamente un certificato.
Perché non mettere semplicemente la data di rinnovo in un calendario?
Un promemoria non costa nulla ed è meglio di niente, quindi mettilo comunque. Il problema è che la data nel tuo calendario è una data che qualcuno ha scritto, e il certificato sul server è quello che c'è effettivamente. Concordano fino a quando un rinnovo riesce a metà, un deploy distribuisce un vecchio bundle, un host in un pool manca il nuovo file, o il certificato rinnovato non è quello servito. Questo legge il certificato come lo riceve un visitatore, quindi la data di cui avvisa è quella reale.