Come verificare quando scade un certificato SSL

Il modo rapido: il lucchetto e un controllo online

In qualsiasi browser, clicca sul lucchetto nella barra degli indirizzi, apri i dettagli del certificato, e leggi "valido da" e "valido fino a". Ci vogliono dieci secondi e ti dice cosa vede il tuo stesso browser. Il suo limite è che copre solo il certificato servito a te, dal nodo periferico o dal server che hai raggiunto, nel momento in cui hai guardato.

Un controllo SSL online esegue lo stesso handshake dall'esterno della tua rete e riporta la data di scadenza, l'emittente, i nomi coperti dal certificato, e se la catena servita è completa. I browser nascondono quest'ultimo punto, quindi il controllo esterno ti dice qualcosa che il lucchetto non può.

Il modo manuale con openssl

Un comando stampa la finestra di validità:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null   | openssl x509 -noout -dates -subject -issuer

Il flag -servername invia SNI, il che conta perché la maggior parte dei server ospita più certificati su un unico indirizzo e ti consegnerebbe quello sbagliato senza di esso. L'output fornisce notBefore e notAfter in UTC, più per chi è il certificato e chi lo ha emesso.

Per vedere l'intera catena inviata dal server, non solo il foglia:

openssl s_client -connect example.com:443 -servername example.com -showcerts < /dev/null

Leggi il blocco "Certificate chain" in alto: dovresti vedere il foglia, poi uno o più intermedi. Una riga "verify error: unable to get local issuer certificate" significa che il server non sta inviando l'intermedio, cosa che molti browser mascherano ma che molti client API, app mobili e sistemi più vecchi non tollerano.

Foglia, catena e cosa scade

In una normale connessione HTTPS sono coinvolti tre certificati, e ciascuno ha la propria data di scadenza:

• Il foglia è il certificato emesso per il tuo dominio. È quello a vita breve, tipicamente 90 giorni per l'emissione automatizzata e fino a circa un anno per uno acquistato, ed è ciò che le persone intendono per "il certificato".
• L'intermedio firma il foglia e deve essere inviato dal server insieme a esso. Dura per anni, ed è proprio perché cambia così raramente che la sua scadenza coglie di sorpresa i team.
• La radice vive nel trust store del client, non sul tuo server. Quando una radice scade o perde fiducia, i dispositivi più vecchi che non hanno mai ricevuto l'aggiornamento iniziano a fallire mentre quelli aggiornati vanno bene, producendo un'interruzione che sembra impossibile dal tuo stesso portatile.

Quindi convalida la catena, non solo la data sul foglia. Un foglia con due mesi rimanenti su una catena rotta sta già fallendo per alcuni client.

Perché la scadenza è l'interruzione evitabile più comune

La scadenza del certificato è un guasto insolitamente dannoso. Fallisce completamente invece che gradualmente, perché un browser rifiuta la connessione a priori e mostra un avviso a schermo intero invece del sito. Il momento in cui accade era fissato fin dal giorno in cui il certificato è stato emesso, e nessuno teneva d'occhio quella data. Mette giù anche tutto ciò che usa quel nome contemporaneamente, non solo il sito web: API, backend di app mobili, webhook e integrazioni. I callback di pagamento falliti e le integrazioni rotte spesso costano più del downtime visibile.

È anche completamente evitabile, il che è il motivo per cui è il guasto per cui vale di più automatizzare un controllo.

Come il rinnovo automatico fallisce comunque

L'emissione automatizzata ha eliminato la maggior parte delle scadenze e ha introdotto una serie di guasti più difficili da vedere:

• Il rinnovo è avvenuto ma nulla si è ricaricato. Un nuovo certificato è sul disco mentre il server web continua a servire quello vecchio dalla memoria finché non viene ricaricato.
• La sfida di convalida si è rotta. Una regola di redirect, una modifica al firewall o una nuova CDN davanti all'origine blocca il percorso della sfida HTTP, quindi il rinnovo continua a fallire per settimane senza alcun sintomo visibile.
• La convalida DNS ha perso le proprie credenziali. Un token API è stato ruotato o è scaduto e la sfida DNS non può più creare il suo record.
• Il timer di rinnovo non è in esecuzione. Un container è stato ricreato senza il cron job o il timer systemd, oppure la macchina è stata migrata e la pianificazione non è arrivata con essa.
• Solo un nodo si è rinnovato. Dietro un load balancer, un server ha il nuovo certificato e un altro serve ancora quello vecchio, quindi i guasti sembrano intermittenti.
• Le email di rinnovo sono andate a qualcuno che se n'è andato. La versione con certificato acquistato dello stesso problema.
• Il certificato si è rinnovato ma non per tutti i nomi. Un sottodominio aggiunto in seguito manca dal nuovo certificato, quindi quel singolo nome host fallisce.

Ognuno di questi è invisibile dall'interno del sistema di rinnovo e ovvio dall'esterno. Questo è l'argomento a favore di verificare l'handshake reale invece di fidarsi dei log dell'automazione stessa.

Automatizzare il controllo

Leggere una data ti dà la risposta di oggi, e l'intero problema della scadenza è che arriva in un giorno che nessuno ha scelto di controllare. Il monitoraggio pianificato dei certificati esegue l'handshake reale dall'esterno a intervalli, avvisa un numero prestabilito di giorni prima di notAfter, e intercetta i problemi di catena e nome host che un promemoria sul calendario non intercetterebbe mai. HostTracker avvisa via email, SMS, chiamata vocale, Slack, Telegram e altro, così l'avviso raggiunge qualcuno prima della scadenza. Il monitoraggio di dominio e TLS esegue il controllo in continuo, lo strumento di controllo SSL fa un controllo una tantum, e come verificare se una porta è aperta tratta un handshake che fallisce prima ancora che venga offerto un certificato.