Ablauf von TLS-Zertifikaten auf jedem Endpunkt überwachen, nicht nur auf der Hauptwebsite

Ziel

Nie von einem Nutzer erfahren, dass ein Zertifikat abgelaufen ist. Jedes von der Organisation ausgelieferte Zertifikat hat ein bekanntes Ablaufdatum und einen Alarm, der früh genug auslöst, um die Erneuerung von Hand zu reparieren.

Voraussetzungen

Ein Verzeichnis der Hostnamen und Ports, die TLS terminieren (443, aber auch SMTP, IMAP, LDAP, Datenbank-Ports, Admin-Panels, Load-Balancer-Listener, VPN-Endpunkte); ein Monitoring-System, das Abfragen nach Zeitplan ausführt; Kenntnis darüber, wie jedes Zertifikat ausgestellt wird (ACME-Client, anbieterverwaltet, manuell).

Schritte

1. Das Verzeichnis aus dem aufbauen, was tatsächlich ausgeliefert wird, nicht aus dem, was dokumentiert ist: die eigenen Adressen und DNS-Namen nach TLS-Listenern scannen und Host, Port, Subject und Aussteller festhalten.
2. Jeden Endpunkt von ausserhalb des Hosts abfragen und die Kette so lesen, wie ein Client sie sieht. RFC 5280 definiert die Gültigkeitsdauer über notBefore und notAfter; das Endzertifikat und jedes Zwischenzertifikat tragen ihre eigenen.
3. Die verbleibenden Tage bis notAfter für das Endzertifikat und die Zwischenzertifikate berechnen und als Metrik exportieren. Für ein Skript dokumentiert das OpenSSL-Manual openssl x509 -checkend <seconds>, was einen Wert ungleich null zurückgibt, wenn das Zertifikat innerhalb dieser Sekundenzahl abläuft; das 3.6-Manual ergänzt -multi, womit -checkend fehlschlägt, sobald irgendein Zertifikat in der Eingabe (zum Beispiel eine gespeicherte Kette) innerhalb der Frist abläuft. Das 3.5-Manual kennt -multi noch nicht, daher auf älteren Versionen das Endzertifikat und jedes Zwischenzertifikat einzeln prüfen.
4. Den Schwellenwert passend zum Ausstellungsmechanismus setzen. Let's Encrypt gibt an, dass seine Standardzertifikate 90 Tage gültig sind und empfiehlt, sie alle 60 Tage zu erneuern, und dass seine kurzlebigen Zertifikate sechs Tage gültig sind mit Erneuerung alle drei Tage. Beim 90-Tage-Fall bleiben nach einer Erneuerung an Tag 60 noch 30 Tage; ein Alarm bei noch 20 verbleibenden Tagen bedeutet daher, dass die automatische Erneuerung bereits einen Zyklus verpasst hat, während für eine Person noch Zeit bleibt. Sechstägige Zertifikate brauchen einen in Stunden gemessenen Schwellenwert.
5. Auch bei fehlgeschlagener Abfrage alarmieren (Port geschlossen, Handshake-Fehler) sowie bei einem Zertifikat, dessen Subject oder Aussteller vom erwarteten abweicht.
6. Den Alarm testen, indem gezielt ein kurzlebiges Zertifikat abgefragt wird oder indem der Schwellenwert für einen Endpunkt über die aktuell verbleibenden Tage angehoben wird.
7. Für jeden Endpunkt festhalten, wer ihn wie erneuert; das Runbook zum Alarm lautet „Erneuerung ausführen, dann erneut abfragen“.

Erwartetes Ergebnis

Eine einzige Übersicht über die verbleibende Lebensdauer jedes Zertifikats, ein Alarm, der auslöst, solange eine manuelle Erneuerung noch komfortabel möglich ist, und kein Endpunkt, dessen Zertifikat überrascht.

Grenzen und Prüfbasis

Abfragen von innerhalb des Hosts übersehen Zertifikate, die von einem vorgeschalteten Load Balancer oder CDN präsentiert werden. Client-Zertifikate und Code-Signing-Zertifikate brauchen dasselbe Verzeichnis, aber andere Abfragen. Die Gültigkeitsdauern folgen den zitierten Angaben der Aussteller; es werden keine Ausfallstatistiken behauptet.