SSL-Zertifikats-Monitoring mit Ablauf-Alarm
Lass dich nie wieder von einem abgelaufenen Zertifikat überraschen.
Ein SSL-Monitor prüft das TLS-Zertifikat, das ein Host tatsächlich ausliefert, rechnet aus, wie viele Tage noch darauf sind, und alarmiert dich, bevor diese Zahl null erreicht. Abgelaufene Zertifikate scheitern nicht sanft: Browser ersetzen die Seite durch eine bildschirmfüllende Warnung, API-Clients brechen schon beim Handshake ab, dazwischen gibt es nichts. Deshalb lohnt sich die Überwachung des Ablaufdatums, denn der Ausfall ist vollständig vorhersehbar. Das Datum steht Monate vorher im Zertifikat, und die einzige offene Frage ist, ob es rechtzeitig jemand liest.
So funktioniert's
UptimeAlien prüft das Ablaufdatum des Zertifikats im Intervall und alarmiert eine konfigurierbare Zahl von Tagen vor Ablauf.
Wann du es nutzt
- Produktive TLS-Zertifikate
- Zertifikate außerhalb deiner Erneuerungs-Automatisierung
- Mail-, LDAP- und Broker-Zertifikate auf abweichenden Ports
- Zertifikate auf Load Balancern und CDN-Edges
- Compliance- und Erneuerungs-Erinnerungen
Was du bekommst
Tage bis zum Ablauf, das exakte Ablaufdatum, bei bereits abgelaufenen Zertifikaten die Zeit seitdem. Dazu den Alarm zur eingestellten Vorwarnzeit.
Beispiel
*.acme.com, 14 Tage vor Ablauf warnen
Automatische Erneuerung ist keine Garantie
ACME-Clients haben die Zertifikatserneuerung zu einem Hintergrundprozess gemacht, und Hintergrundprozesse scheitern leise. Ein Renewal-Hook, der nach einer Servermigration nie wieder eingerichtet wurde. Eine DNS-01-Challenge, die nach dem Nameserver-Wechsel nicht mehr validiert. Ein Cronjob, der im Wartungsfenster deaktiviert und nie reaktiviert wurde. Ein Zertifikat auf einem Load Balancer, einer CDN-Edge oder einem Mailserver, das von Anfang an gar nicht Teil der Automatisierung war. Nichts davon erzeugt einen Fehler, den jemand sieht. Die Logs liegen auf einer Maschine, in die niemand schaut, und alles funktioniert bis exakt zum Ablaufdatum weiter. Dann zeigen Browser eine Vollbildwarnung, API-Clients brechen mit TLS-Fehler ab, und Mobile Apps mit Certificate Pinning reden gar nicht mehr mit dir. Ein Zertifikats-Monitor prüft von außen und hängt an keiner deiner Automatisierungen. Deshalb meldet er sich auch dann noch, wenn die Automatisierung selbst das Kaputte ist.
Der Monitor liest das Ablaufdatum und urteilt nicht über die Vertrauenskette
Der Check öffnet eine TLS-Verbindung zum Host, schickt den Hostnamen per SNI mit, damit er auf einer geteilten IP das richtige Zertifikat bekommt, liest das Ablaufdatum aus dem tatsächlich ausgelieferten Zertifikat und rechnet es in verbleibende Tage um. Über die Vertrauenskette urteilt er nicht: Ein selbstsigniertes Zertifikat, eines aus einer internen CA oder ein Staging-Host mit unpassendem Namen wird genauso überwacht wie ein öffentlich vertrauenswürdiges. Das ist Absicht, denn dieser Monitor beantwortet die Frage „wann läuft es ab“, und interne Dienste haben auf diese Antwort denselben Anspruch. Wenn du zusätzlich „vertraut ein Browser dem“ wissen willst, leg einen HTTP-Monitor auf dieselbe URL: Der scheitert am TLS-Handshake, sobald die Kette bricht, ein Intermediate fehlt oder der Name nicht passt. Zusammen decken sie beide Hälften ab, und zwar unabhängig voneinander.
Zertifikate liegen nicht nur auf Port 443
Die Zertifikate, die einen wirklich erwischen, sind selten die auf der Website, auf die schaut ohnehin jeder. Es ist das SMTP-Submission-Zertifikat auf Port 465, IMAP auf 993, LDAPS auf 636, der MQTT-Broker auf 8883, die Postgres- oder RabbitMQ-Instanz hinter einem TLS-Listener. Läuft eines davon ab, gibt es keine Warnseite und keinen sichtbaren Ausfall. Die Mailzustellung hört einfach auf, ein Queue-Consumer verbindet sich in einer Schleife neu, eine Integration fängt an zu scheitern, in einer Frequenz, der jemand nächste Woche mal nachgeht. Trag das Ziel als host:port ein, dann prüft der Monitor dort, wo das Zertifikat liegt. Eine vollständige URL geht auch: Schema, Pfad und Query werden abgeschnitten und der Port daraus übernommen, sodass eine aus dem Browser kopierte Adresse direkt das Richtige tut.
Vorwarnzeit: 14 Tage bei ACME, 30 bei manueller Erneuerung
Die Vorwarnzeit wird pro Monitor gesetzt, zwischen 1 und 90 Tagen, Voreinstellung ist 7. Sieben Tage reichen zum Bemerken, aber nicht immer zum Handeln: Ein Alarm am Freitagabend lässt zwei Arbeitstage. Welcher Wert richtig ist, hängt davon ab, wie das Zertifikat erneuert wird. Bei einem ACME-Zertifikat mit 90 Tagen Laufzeit sind 14 bis 21 Tage der nützliche Bereich. Die Automatisierung erneuert normalerweise bei 30 Tagen Rest, ein Alarm bei 14 ist also eindeutig: Die Erneuerung hat nicht stattgefunden, und sie wird von allein auch nicht mehr stattfinden. Bei einem manuell erneuerten Ein-Jahres-Zertifikat sind 30 Tage realistischer, weil Beschaffung, Validierung und ein Freigabeschritt länger dauern als die eigentliche Arbeit. Deutlich weiter zu gehen ist kontraproduktiv: Ein Alarm zwei Monate im Voraus wird zur Kenntnis genommen und vergessen, und der Monitor steht danach wochenlang auf Rot, bis er gar nichts mehr bedeutet.
Häufige Fragen
Was ist SSL-Zertifikats-Monitoring?
Es prüft regelmäßig das Ablaufdatum deines TLS-Zertifikats und alarmiert dich eine einstellbare Anzahl Tage vor Ablauf, damit eine Erneuerung nicht untergeht.
Wie richte ich SSL-Zertifikats-Monitoring ein?
Leg einen Monitor vom Typ SSL an, trag den Hostnamen ein, bei Bedarf mit :port, falls das Zertifikat nicht auf 443 liegt, und stell ein, wie viele Tage vor Ablauf du gewarnt werden willst. Der erste Check läuft im nächsten Durchgang und meldet das gefundene Ablaufdatum; danach bleibt der Monitor grün, bis die verbleibenden Tage deine Schwelle erreichen.
Warum überwachen, wenn die Erneuerung automatisiert ist?
Weil Automatisierung leise scheitert: Ein Renewal-Hook bricht, eine DNS-Challenge validiert nicht mehr, ein Cronjob wird bei einer Migration deaktiviert. Meist merkt man es, wenn Browser bereits eine Warnseite zeigen. Ein Zertifikats-Monitor macht daraus eine frühzeitige Meldung.
Wie viele Tage Vorwarnzeit sind sinnvoll?
Genug, um in Ruhe zu erneuern. Zwei Wochen sind ein üblicher Wert, lang genug zum Reagieren, kurz genug, dass der Alarm ernst genommen wird. Bei manuell erneuerten Zertifikaten passen eher 30 Tage, weil Beschaffung und Freigaben länger dauern als die Arbeit.
Kann ich Zertifikate auf anderen Ports als 443 überwachen?
Ja. Schreib das Ziel als host:port, also mail.acme.com:465 für SMTP-Submission, imap.acme.com:993, broker.acme.com:8883 für MQTT. Ohne Portangabe wird 443 angenommen.
Wohin gehen die Ablauf-Alarme?
Dorthin, wohin du sie leitest: E-Mail, Slack, Discord, Telegram, PagerDuty, Opsgenie, ntfy, Gotify, Webhook, ein MQTT-Topic oder eine Push-Nachricht in der Android-App. Die Kanäle werden pro Monitor gesetzt, Zertifikatswarnungen können also woanders landen als Ausfall-Alarme. Sinnvoll, weil das eine eine Aufgabe für diese Woche ist und das andere ein Notfall.
Was passiert, wenn ein Zertifikat bereits abgelaufen ist?
Der Monitor geht auf Down, und der Alarm nennt, wie lange der Ablauf her ist, statt nur zu wiederholen, dass er ansteht. Dieser Unterschied zählt, wenn du vor einem Stapel Benachrichtigungen sitzt und unterscheiden musst, was schon kaputt ist und was gleich kaputtgeht.
Wird die komplette Zertifikatskette geprüft?
Nein, gelesen wird das Ablaufdatum des Zertifikats, das der Host ausliefert. Intermediates haben eigene, deutlich längere Laufzeiten und werden von der CA getauscht. Wenn du die Kette validiert haben willst, erledigt das ein HTTP-Monitor auf denselben Host nebenbei: Eine kaputte Kette lässt den TLS-Handshake scheitern, und der Check geht auf Rot.
Funktioniert das mit Wildcard-Zertifikaten?
Ja, Wildcard-Zertifikate werden genauso geprüft wie Zertifikate für einen einzelnen Hostnamen.
Gibt es eine API für SSL-Monitoring?
Ja. POST /api/v1/monitors legt mit einem API-Token einen Monitor an und nimmt Typ, Ziel und certWarnDays im Body entgegen; ein GET auf denselben Pfad listet sie samt dem zuletzt ermittelten Ablaufdatum. Zertifikate lassen sich damit von derselben Automatisierung eintragen, die sie ausstellt.
Überwacht dieser Monitor auch den Ablauf der Domain?
Nein, dafür gibt es einen eigenen Typ. Zertifikat und Domain haben getrennte Ablaufdaten und völlig unterschiedliche Konsequenzen: Ein Zertifikat läuft alle paar Monate ab und erneuert sich meist selbst, eine Domain-Registrierung läuft nach Jahren ab und ist danach nur mit Aufwand und Kosten zurückzuholen. Nutze dafür das Domain-Ablauf-Monitoring.
Leg deinen ersten Monitor an. Kostenlos.
Kostenlos loslegenWeitere Monitoring-Typen
Passendes Feature: Ablauf-Überwachung