SSL/TLS
SSL/TLS-Zertifikatsüberwachung
Das SSL/TLS-Zertifikat, das ein Host ausliefert, und wie viele Tage es noch gültig ist, bevor es abläuft.
Jetzt ausprobieren
Ein Test, von einem Ort, jetzt sofort, und nichts wird gespeichert. Ein Monitor prüft von jedem Standort, den wir betreiben, und bestätigt einen Ausfall von zwei anderen Kontinenten, bevor jemand geweckt wird, was ein einzelner Blick dir nicht zeigen kann.
Wofür es ist
Das Ablaufen eines Zertifikats ist die Störung, die jeder schon hatte und niemand einplant. Die Erneuerung ist automatisiert, bis die Automatisierung eines Tages unbemerkt fehlschlägt, und das erste Zeichen ist, dass jeder Browser weltweit deine Seite mit NET::ERR_CERT_DATE_INVALID ablehnt.
Das öffnet eine TLS-Verbindung auf Port 443 oder wo du es angibst und liest das X.509-Zertifikat, das der Host tatsächlich ausliefert. Das ist nicht immer das, was dein Erneuerungsjob geschrieben hat: ein Load Balancer mit einem veralteten Node, ein zweiter virtueller Host, den niemand neu geladen hat, ein CDN mit der alten Zertifikatskette. Es meldet den Subject, die ausstellende Zertifizierungsstelle und das notAfter-Datum, also einen Countdown statt einem Up oder Down.
Wildcard- und SAN-Zertifikate sind ein Zertifikat, also überwache den Host, von dem jedes tatsächlich ausgeliefert wird. Ein Zertifikat für *.example.com auf drei Load Balancern sind drei Monitore, weil das Problem ist, dass einer der drei nicht neu geladen wird.
Wie jeder Check hier läuft er von Amsterdam, New York, Sydney and Singapore, und ein Fehler wird von zwei anderen Kontinenten bestätigt, bevor jemand geweckt wird. Wie das funktioniert.
Was du einstellen kannst
Alles unten steht im Formular, wenn du einen hinzufügst, in jedem Tarif.
- Host
- Ein Hostname, ein Host und Port oder eine URL: example.com, example.com:8443 und https://example.com funktionieren alle. Port 443, außer du gibst einen an.
Du bekommst drei Warnungen: bei vierzehn Tagen, sieben Tagen und zwei Tagen, jede nur einmal. Tägliche Erinnerungen werden ignoriert, damit es sich nicht wiederholt. Dreißig Tage werden absichtlich übersprungen: Das ist der Zeitpunkt, an dem Let's Encrypt erneuert, und es würde bei jedem gültigen Zertifikat auslösen. Wenn das Zertifikat abgelaufen ist oder wir es gar nicht lesen können (Verbindung verweigert, Handshake schlägt fehl, keine Antwort), ist das ein Alarm und keine Warnung, und er wird sofort ausgelöst.
Fragen
Was ist der Unterschied zwischen einem SSL-Zertifikat und einem TLS-Zertifikat?
Nichts, für diesen Zweck. SSL ist der alte Name des Protokolls, TLS ist der aktuelle, und SSL 2.0 und 3.0 sind seit über einem Jahrzehnt tot. Die Datei selbst ist so oder so ein X.509-Zertifikat und weiß nicht, welches Protokoll sie präsentieren wird. Die meisten suchen immer noch nach SSL, also schreiben wir SSL/TLS und meinen dasselbe wie du.
Warum zeigt mein Browser NET::ERR_CERT_DATE_INVALID an?
Das Zertifikat, das der Browser erhalten hat, ist abgelaufen oder sein notBefore-Datum ist noch nicht erreicht, was passiert, wenn die Uhr des Servers falsch ist. Chrome zeigt diesen Code, Firefox sagt SEC_ERROR_EXPIRED_CERTIFICATE und Safari sagt, das Zertifikat sei nicht gültig. Dieser Monitor sagt es dir zwei Tage, bevor es deine Besucher tun.
Überprüft das die Zertifikatskette?
Dieser Check liest das Ablaufdatum, sodass eine unvollständige Kette oder ein fehlendes Zwischenzertifikat ihn nicht fehlschlagen lässt. Ein HTTPS-Monitor überprüft die Kette: Er verbindet sich wie ein Browser und schlägt bei einer ungültigen Kette, einem selbstsignierten Zertifikat oder einem Hostnamen-Mismatch fehl. Nutze beide für alles, was wichtig ist, weshalb HTTPS in jedem Tarif enthalten ist.
Was ist mit Wildcard- und SAN-Zertifikaten?
Beides funktioniert. Ein Wildcard-Zertifikat oder eines mit mehreren Subject Alternative Names ist ein einzelnes Zertifikat mit einem einzigen Ablaufdatum. Was sich unterscheidet, ist, welcher Host es ausliefert, also füge einen Monitor pro Host hinzu statt einen pro Namen auf dem Zertifikat.
Überprüft ihr OCSP oder Certificate Transparency?
Nein, und wir sagen das, statt etwas anderes zu implizieren. Das liest das Zertifikat, das ein Host ausliefert, und meldet die verbleibenden Tage. Widerrufsprüfungen und CT-Log-Überwachung sind andere Produkte, die andere Probleme lösen, und ein Monitor, der sie halb macht, wäre schlechter als einer, der sie gar nicht macht.
Meine Erneuerung ist automatisiert. Brauche ich das trotzdem?
Genau dafür ist das gedacht. Niemand mit einer manuellen Erneuerung vergisst für neunzig Tage am Stück; die Ausfälle kommen von einer Let's Encrypt-Erneuerung, die vor sechs Wochen still fehlgeschlagen ist oder auf der Maschine erfolgreich war, die das Zertifikat schreibt, aber nicht auf der, die es ausliefert.
Was, wenn der Host gar nicht antwortet?
Ein TLS-Handshake-Fehler, eine verweigerte Verbindung oder ein Timeout wird als Fehler des Checks gemeldet und nicht als Ablaufwarnung, weil das unterschiedliche Probleme mit unterschiedlichen Lösungen sind. Der Ablauf-Countdown bewegt sich nur, wenn wir tatsächlich ein Zertifikat lesen.
Warum nicht einfach das Erneuerungsdatum in einen Kalender eintragen?
Eine Erinnerung kostet nichts und ist besser als nichts, also füge auch eine ein. Das Problem ist, dass das Datum in deinem Kalender ein Datum ist, das jemand eingetragen hat, und das Zertifikat auf dem Server ist, was tatsächlich dort ist. Sie stimmen überein, bis eine Erneuerung halb gelingt, ein Deploy ein altes Bundle ausliefert, ein Host in einem Pool die neue Datei verpasst oder das erneuerte Zertifikat nicht das ist, das ausgeliefert wird. Das liest das Zertifikat so, wie ein Besucher es erhält, also ist das Datum, vor dem es warnt, das echte.