SSL-Zertifikatsüberwachung: Ablaufwarnungen für Zertifikate und Domains

Ein abgelaufenes SSL-Zertifikat ist nicht die einzige Frist, die eine Website offline nehmen kann - der Domain-Ablauf-Checker von HostTracker überwacht Ihren Registrierungsstatus zusätzlich zu Ihren Zertifikaten, ohne Aufpreis.

Ein SSL-Zertifikats-Ablaufmonitor wird oft als reine Kalendererinnerung verkauft, und der Ablauf ist tatsächlich die häufigste Art, wie Zertifikate versagen. Aber nicht die einzige. Jeder Lauf von HostTracker öffnet eine echte TLS-Verbindung und bewertet das Zertifikat, das der Server tatsächlich ausgeliefert hat - das erkennt auch die Fehler, die auftreten, ohne dass sich überhaupt ein Datum ändert.

Im Kern ist ein Zertifikatsmonitor eine TLS-Verbindung zu einem Host und einem Port. Der Port ist standardmäßig 443, Sie können aber einen anderen angeben - example.com:8443 -, sodass ein API-Gateway, ein alternativer HTTPS-Port oder ein Dienst auf einem impliziten TLS-Port genauso überwacht wird. Der Hostname wird per SNI gesendet, sodass ein Server, der mehrere Zertifikate unter einer IP-Adresse hostet, das richtige zurückliefert.

Wenn ein Server ausfällt, sieht ein Besucher einen Browserfehler und versucht es meist später erneut. Wenn ein Zertifikat abläuft, ist der Server weiterhin völlig gesund - er beantwortet jede Anfrage -, und der Browser weigert sich, anzuzeigen, was er geschickt bekommen hat. Der Unterschied macht sich auf vier Arten bemerkbar, die man leicht unterschätzt, bis es tatsächlich passiert.

• Die Warnung ist bewusst furchteinflößend gestaltet. Eine vollflächige Warnseite über eine unsichere Verbindung ist genau der Bildschirm, den ein Browser auch bei einem Abhörversuch anzeigt. Besucher lesen das nicht als „das Zertifikat ist abgelaufen“, sondern als „diese Website ist nicht sicher“.
• Auf einer HSTS-aktivierten Website gibt es keinen Weg vorbei. Wenn Sie jemals einen Strict-Transport-Security-Header gesendet haben - und das sollten Sie -, entfernen Browser die Option „Trotzdem fortfahren“ komplett. Jeder Besucher wird hart blockiert, bis das Zertifikat ersetzt ist.
• Maschinen scheitern härter als Menschen. Ihre mobile App, Ihre Zahlungs-Webhooks, die Integrationen Ihrer Partner und jeder API-Client validieren das Zertifikat ebenfalls, und keiner von ihnen hat einen Button zum Weiterklicken. Ein Ablauf ist ein kompletter Integrationsausfall, nicht nur ein Website-Ausfall.
• Ihr eigenes Monitoring kann trotzdem grün aussehen. Ein Check, der Zertifikatsprobleme ignoriert, meldet weiterhin HTTP 200 von einem Server, dessen Zertifikat vor einer Stunde abgelaufen ist. Die Anwendung hat nichts bemerkt. Genau diese Lücke soll ein Zertifikatsmonitor schließen.

Dieselbe Asymmetrie gilt für eine abgelaufene Domain, nur langsamer und schwerer rückgängig zu machen: Ein Zertifikat lässt sich in Minuten neu ausstellen, während eine Domain, die die Karenzfrist verlässt, von jedem registriert werden kann.

Die Zertifikatsüberwachung gibt es in zwei Varianten, und die meisten Konten wollen die erste.

Ein Zertifikat ändert sich nicht von einer Minute zur nächsten, daher prüft keine der beiden Varianten öfter, als es sinnvoll wäre. Sechs Stunden bedeuten: Im schlechtesten Fall vergehen zwischen dem Auftreten eines Zertifikatsproblems und der Erkennung durch HostTracker wenige Stunden - bei etwas, das Ihnen normalerweise 30 Tage Vorlaufzeit gibt.

HostTracker sendet Erinnerungen 30 Tage, 7 Tage und 1 Tag vor einem Ablaufdatum - sowohl für SSL/TLS-Zertifikate als auch für Domain-Registrierungen. Drei Stufen statt einer einzigen, denn jede fängt eine andere Art von Versäumnis ab: 30 Tage reichen aus, um eine Bestellung anzustoßen oder einen defekten Verlängerungsjob zu reparieren, 7 Tage fangen das Ticket ab, das niemand aufgegriffen hat, und 1 Tag ist der letzte Aufruf, bevor Browser Ihre Besucher zu warnen beginnen.

Eine Erinnerung ist kein Ausfallalarm, und HostTracker hält beides strikt getrennt. Ist das Zertifikat gerade tatsächlich ungültig - abgelaufen, widerrufen, mit einer nicht vertrauenswürdigen Kette verbunden oder für einen anderen Hostnamen ausgestellt -, ist das ein fehlgeschlagener Check, und er eskaliert über Ihre normalen Down-Alert-Kontakte mit der von jedem gewählten Verzögerung: sofort, oder nach 3, 5, 15, 30 oder 60 Minuten, oder nach 3, 6, 12 oder 24 Stunden.

Benachrichtigungen werden über die neun von HostTracker unterstützten Kanäle verschickt - E-Mail, SMS, Anruf, Webhook, Slack, Web-Push und die Messenger-Apps Telegram, Discord und Viber. Zertifikatsverlängerungen und Domain-Verlängerungen liegen meist bei unterschiedlichen Personen, setzen Sie also beide auf die Kontaktliste: Die Erinnerung, die nur das Postfach der Person erreicht, die den Monitor eingerichtet hat, ist die Erinnerung, die übersehen wird.

Die Leiter oben ist genau das, was eine SSL-Zertifikats-Ablaufverfolgung in der Praxis ist. Alle sechs Stunden liest HostTracker das Zertifikat neu ein, das Ihr Server tatsächlich ausgeliefert hat, und berechnet die verbleibenden Tage neu; an drei dieser Zahlen hängt eine Erinnerung.

Die drei Stufen liegen fest bei 30, 7 und 1 Tag, und dieselbe Leiter gilt für Domain-Registrierungen ebenso wie für Zertifikate. Eine Erinnerung ist informativ und setzt einen Monitor nie allein auf Down; ein tatsächlich ungültiges Zertifikat - abgelaufen, widerrufen, für einen anderen Hostnamen ausgestellt oder an einen nicht vertrauenswürdigen Root gekettet - ist eine fehlgeschlagene Prüfung und eskaliert wie jeder andere Ausfall.

Noch keine Überwachung? Die kostenlose Sofort-SSL-Prüfung liest dasselbe Zertifikat und meldet dasselbe Ablaufdatum, denselben Aussteller, dieselbe Kette und dieselbe ausgehandelte TLS-Version - einmal, sofort, ohne Konto. Die Ablaufverfolgung ist genau diese Prüfung in einer Sechs-Stunden-Schleife, mit den drei Erinnerungen daran.

Der oben beschriebene Zertifikatsmonitor beantwortet die Frage „Ist dieses Zertifikat gültig?“. Ein separater Satz von Schaltern auf einem HTTPS-Verfügbarkeitsmonitor beantwortet eine härtere Frage - „Entspricht diese Verbindung unserem Standard?“ - und jeder davon ist Opt-in, denn sie alle für jeden Kunden standardmäßig zu aktivieren, würde sehr viele Websites fehlschlagen lassen, die genau so funktionieren, wie ihre Betreiber es beabsichtigen.

• Gültige Zertifikatskette erfordern. Standardmäßig aus, damit ein selbstsigniertes Zertifikat auf einem internen Host seinen Uptime-Check nicht fehlschlagen lässt. Aktivieren Sie es für alles Öffentliche.
• Starkes TLS-Protokoll erfordern. Lässt den Check fehlschlagen, wenn der Server etwas unterhalb von TLS 1.2 aushandelt - der nützliche Schalter nach einem Härtungsprojekt, damit eine zurückgerollte Konfiguration nicht still und leise ein veraltetes Protokoll wieder einführt.
• Schwache Cipher blockieren. Lässt den Check fehlschlagen, wenn der ausgehandelte Cipher schwächer als 128-Bit ist.
• Zertifikatswiderruf prüfen. Fügt dem Verfügbarkeits-Check selbst eine OCSP/CRL-Abfrage hinzu.

Ein eigenständiger Zertifikats-Ablaufmonitor wendet Kettenvalidierung und Widerrufsprüfung ohnehin schon von sich aus an, ganz ohne diese Schalter - sie existieren, damit Ihr Uptime-Check so streng gemacht werden kann, wie es Ihre Sicherheitsanforderungen verlangen, unabhängig davon, was der Zertifikatsmonitor meldet.

Automatische Verlängerung sollte Ablauf-Vorfälle eigentlich beenden, und größtenteils hat sie das auch. Was sich geändert hat, ist die Form der verbleibenden Vorfälle: Statt dass ein Mensch ein Datum vergisst, hört ein Stück Automatisierung auf zu funktionieren, und niemand bemerkt es - denn funktionierende Automatisierung ist still, und defekte Automatisierung ist genauso still. Die Laufzeiten von Zertifikaten werden branchenweit immer kürzer - die weit verbreiteten kostenlosen Zertifizierungsstellen stellen 90-Tage-Zertifikate aus, und die maximale von Browsern akzeptierte Laufzeit wird schrittweise reduziert -, was bedeutet, dass eine Verlängerung inzwischen mehrmals im Jahr stattfindet, und jede davon kann diejenige sein, die scheitert.

Die Fehler, von denen uns berichtet wird, sehen typischerweise so aus:

• Der Verlängerungs-Cronjob ist vor Monaten gestorben. Das Zertifikat, das er zuletzt verlängert hat, war 90 Tage gültig, sodass der Fehler erst am Tag 91 sichtbar wurde.
• Die Verlängerung war erfolgreich, aber nichts wurde neu geladen. Das neue Zertifikat liegt auf der Festplatte, während Webserver, Load Balancer oder Container weiterhin das alte aus dem Speicher ausliefern. Jedes Verlängerungsprotokoll meldet Erfolg.
• Ein Knoten von mehreren wurde vergessen. Hinter einem Load Balancer erhalten die meisten Anfragen das neue Zertifikat und ein Teil das abgelaufene - weshalb ein sporadischer „bei mir funktioniert es“-Zertifikatsfehler fast immer ein Konsistenzproblem über die gesamte Flotte ist.
• Der Edge ist in Ordnung, der Origin nicht. Ihr CDN präsentiert sein eigenes gültiges Zertifikat, während das des Origin-Servers darunter abgelaufen ist. Alles, was direkt mit dem Origin spricht, bricht.
• Die Validierungsmethode hat aufgehört zu funktionieren. Ein DNS-Eintrag wurde aufgeräumt, ein /.well-known/-Pfad hat begonnen weiterzuleiten, eine Firewall-Regel hat sich geändert - und die davon abhängige Verlängerung ist still und leise nicht mehr durchgelaufen.
• Das Wildcard-Zertifikat hat die neue Subdomain nicht abgedeckt. Ein Wildcard-Zertifikat deckt genau eine Ebene ab, sodass ein Host unter einer tieferen Bezeichnung davon überhaupt nicht erfasst wird.

Jeder dieser Fälle ist von innerhalb Ihrer eigenen Deployment-Pipeline unsichtbar und von außen offensichtlich - das ist das ganze Argument für einen externen Beobachter. Ein Monitor, der sich so verbindet wie der Browser eines Fremden, sieht das Zertifikat, das Sie tatsächlich ausliefern - nicht das, von dem Ihre Automatisierung glaubt, es installiert zu haben.

Die Domain-Seite fragt die Registry statt den Server. HostTracker fragt die Domain über RDAP ab - den modernen, strukturierten Nachfolger von WHOIS - und ermittelt dabei aus dem von der IANA veröffentlichten Verzeichnis, welche Registry für Ihre TLD zuständig ist; für TLDs, die noch keinen RDAP-Dienst anbieten, wird auf eine klassische WHOIS-Abfrage über Port 43 zurückgegriffen. Die Abfrage läuft in einem festen Sechs-Stunden-Takt, und der Check meldet:

• das bei der Registry hinterlegte Ablaufdatum - das maßgebliche, nicht das in Ihrem Abrechnungssystem;
• die Statuscodes der Registry für die Domain, sofern RDAP sie liefert - einschließlich, ob eine Transfer-Sperre aktiv ist;
• eine separate Meldung „Ablaufdatum geändert“, sobald sich das Datum der Registry gegenüber der vorherigen Prüfung unterscheidet - so bestätigen Sie, dass eine Verlängerung tatsächlich angekommen ist, und so erfahren Sie auch von einer, die Sie nicht veranlasst haben.

Dieser letzte Punkt ist im Stillen das nützlichste Signal auf dieser Seite. Eine bezahlte Verlängerung, die nie bei der Registry angekommen ist, sieht bis genau zu dem Moment, in dem die 30-Tage-Erinnerung auslöst, wie eine gesunde Domain aus. Die Veränderung des Datums selbst zu beobachten macht aus der Verlängerung etwas, das Sie sehen können, statt etwas, von dem Sie nur hoffen, dass es passiert ist.

Möchten Sie den vollständigen Registrierungsdatensatz - Registrar, Nameserver, Erstellungsdatum - sofort statt als Monitor? Führen Sie den kostenlosen WHOIS- und Domain-Ablauf-Lookup aus - ohne Login. Der wiederkehrende Monitor meldet bewusst weniger, weil sich eben Ablauf und Status ändern.

1. Fragen Sie die Domain zuerst mit dem kostenlosen Sofort-Check ab, damit Sie die heutigen Ablaufdaten kennen, bevor Sie irgendetwas automatisieren.
2. Wenn Sie die Uptime der Website bereits überwachen, öffnen Sie diesen Monitor und schalten Sie die Zertifikats- und die Domain-Ablaufüberwachung ein. Kein neuer Monitor, keine zusätzliche Anfrage.
3. Für alles, dessen Uptime Sie nicht überwachen - einen Mail-Host, ein internes Gateway, einen alternativen Port -, legen Sie einen eigenständigen Certificate expiration-Monitor an und geben Sie host:port an. Port 443 wird angenommen, wenn Sie den Port weglassen.
4. Legen Sie einen Domain expiration-Monitor für jede registrierbare Domain an, die Sie besitzen - einschließlich der defensiven Registrierungen und der Weiterleitungsdomains. Genau die laufen ab, weil niemand eine Domain im Blick hat, auf der keine Website liegt.
5. Tragen Sie mehr als eine Person in die Kontaktliste ein. Zertifikate und Domains gehören meist zu unterschiedlichen Teams, und die Erinnerung, die nur die Person erreicht, die den Monitor eingerichtet hat, ist die, die ungelesen bleibt, wenn diese Person den Job wechselt.
6. Beachten Sie die Erinnerungsleiter - 30, 7 und 1 Tag - und stellen Sie sicher, dass Ihr Verlängerungsprozess innerhalb von 30 Tagen abläuft. Wenn eine Bestellung sechs Wochen dauert, ist nicht die Leiter Ihre Einschränkung, sondern der Prozess.

Kostenlose SSL-Checker-Tools - einschließlich des eigenen von HostTracker - sind wirklich nützlich und beantworten eine andere Frage. Ein Checker sagt Ihnen den Zustand eines Zertifikats zu dem Moment, in dem Sie gefragt haben. Monitoring sagt Ihnen, wann sich dieser Zustand ändert, während Sie gerade nicht hinsehen - und genau dann ist es wichtig.

Zertifikate stehen neben den anderen Dingen an einer Domain, die schiefgehen können, ohne dass jemand Ihren Server anfasst. Sobald die Ablaufseite überwacht wird, sind die üblichen nächsten zwei Malware- und Phishing-Markierungen und DNS-Blacklist-Einträge - beides stille Reputationsausfälle, bei denen die Website online bleibt, aber der Traffic verschwindet.

• Kein STARTTLS. Der Check verbindet sich und startet sofort den TLS-Handshake, funktioniert also auf jedem Port, der direkt TLS spricht. Protokolle, die im Klartext beginnen und mitten in der Sitzung upgraden - SMTP auf 587, IMAP auf 143, explizites TLS bei FTP - benötigen eine Aushandlung, die der Check nicht durchführt. Richten Sie ihn stattdessen auf den impliziten TLS-Port.
• Die Erinnerungstage sind fest auf 30, 7 und 1 eingestellt. Sie sind derzeit keine Einstellung pro Monitor.
• Ein nicht erreichbarer Widerrufsdienst wird gemeldet, nicht als Fehler gewertet. Das ist Absicht - ein OCSP-Ausfall bei einer Zertifizierungsstelle ist nicht der Ausfall Ihrer Website -, bedeutet aber, dass die Widerrufsprüfung davon abhängt, dass ein Drittanbieter erreichbar ist.
• Certificate-Transparency-Logs werden nicht überwacht. HostTracker informiert Sie über das ausgelieferte Zertifikat; es beobachtet keine öffentlichen CT-Logs auf Zertifikate, die jemand anderes für Ihre Domain ausstellen lässt.
• Client-Zertifikate werden nicht geprüft. Der Check validiert das vom Server präsentierte Zertifikat, keinen Mutual-TLS-Handshake.
• Die Domain-Abdeckung richtet sich nach den Registries. RDAP wird verwendet, wo die TLD es anbietet, klassisches WHOIS, wo nicht; eine kleine Zahl exotischer TLDs bietet beides nur unzureichend an, und der Check meldet dann einen Abfragefehler, statt ein Datum vorzutäuschen.