Dokumentation

Vom Zertifikatsablauf erfahren, bevor es zu spät ist

Ein abgelaufenes Zertifikat legt eine Website so gründlich lahm wie ein abgestürzter Server: Jeder Browser verweigert die Seite, jeder API-Client die Verbindung. Die Ursache liegt selten am Tag selbst: Ein Erneuerungsjob läuft seit Monaten nicht mehr, eine DNS-Änderung hat eine Challenge scheitern lassen, oder das neue Zertifikat ist auf einem Load Balancer angekommen und auf dem anderen nicht. Eine TLS-Prüfung meldet das, solange noch Zeit zum Beheben ist.

Was geprüft wird

Bei jedem Lauf verbindet sich die Prüfung mit dem angegebenen Host und Port, schließt einen TLS-Handshake ab und bewertet, was sie erhalten hat:

Es zählt der früheste Ablauf in der Kette, nicht nur der des Serverzertifikats: Ein Zwischenzertifikat, das zuerst abläuft, legt die Website an seinem eigenen Datum lahm. Die Vertrauensprüfung nutzt nur die Zertifikate, die der Server sendet. Desktop-Browser ergänzen ein fehlendes Zwischenzertifikat manchmal aus ihrem Cache; API-Clients, Kommandozeilenwerkzeuge und ältere Smartphones tun das nicht – und von genau diesen Clients würden Sie sonst nichts hören.

Ein Server kann zwei Zertifikate haben, meist ein ECDSA- und ein RSA-Zertifikat, und zeigt das RSA-Zertifikat nur Clients, die ECDSA nicht beherrschen. Der tägliche Konfigurationstest fragt nach beiden Arten, und jedes Zertifikat, das er erhält, wird wie das Hauptzertifikat geprüft: Gültigkeit, Vertrauen, Name und Ablauf, bei jedem Lauf. Ein Befund zu einem dieser Zertifikate nennt es ausdrücklich. Ein Server, der nur TLS 1.3 spricht, verschlüsselt seine Zertifikate; ein zweites bleibt dann unsichtbar, und das Ergebnis weist darauf hin.

Jedes Ergebnis hält fest, was der Server vorgelegt hat, auch wenn eine Prüfung fehlschlägt: Inhaber, Aussteller, Namen, Schlüssel, Ablaufdaten und die Schlüssel-Pins, die eine App für Certificate Pinning verwenden kann.

Widerruf, Certificate Transparency und CAA

Der Widerruf wird für das Serverzertifikat geprüft: anhand einer Antwort, die der Server im Handshake mitliefert, sonst anhand der Sperrliste oder des OCSP-Responders der CA. Es zählt nur eine Antwort, die die ausstellende CA signiert hat und die noch aktuell ist; alles andere gilt als unbekannt, und eine unbekannte Antwort lässt keine Prüfung fehlschlagen, denn ein ausgefallener Server der CA ist keine ausgefallene Website.

Certificate Transparency folgt den Regeln, die Chrome anwendet: Ein öffentlich vertrauenswürdiges Zertifikat muss Nachweise unabhängiger öffentlicher Logs tragen. Zertifikate Ihrer eigenen Zertifizierungsstelle sind ausgenommen, wie im Browser.

CAA-Einträge nennen die CAs, die für eine Domain Zertifikate ausstellen dürfen. Fehlt darin die CA des aktuellen Zertifikats, warnt die Prüfung: Das Zertifikat funktioniert weiter, seine Erneuerung wird aber abgelehnt. Ein Name ohne CAA-Einträge wird im Ergebnis vermerkt, ohne den Status zu ändern.

Pinning für mobile Apps

Eine App mit Key-Pinning lehnt einen Server ab, dessen Kette keinen ihrer Schlüssel mehr trägt, während jeder Browser weiter funktioniert – von dem Fehler erfahren Sie dann aus den App-Bewertungen. Hinterlegen Sie dieselben Pins in der Prüfung, im Format der Apps (sha256/ und der Hash des Schlüssels), und eine Erneuerung mit neuem Schlüssel schlägt hier zuerst fehl. Jedes Ergebnis listet die Pins der vorgefundenen Kette zum Kopieren auf.

Wenn sich das Zertifikat ändert

Jede Prüfung merkt sich die Zertifikate, die ihr in den letzten 30 Tagen ausgeliefert wurden. Bekommt ein Standort eines, das die Prüfung in dieser Zeit nicht gesehen hat, erfasst sie den Wechsel und meldet ihn standardmäßig, wenn er unerwartet aussieht: Das neue Zertifikat stammt von einer anderen Organisation, deckt weniger Namen ab oder hat einen schwächeren Schlüssel als das ersetzte, oder die TLS-Bewertung des Servers ist mit ihm gesunken. Eine gewöhnliche Erneuerung durch dieselbe CA löst keine Meldung aus, es sei denn, Sie lassen sich über jedes neue Zertifikat benachrichtigen; Sie können diese Meldungen auch ausschalten. Weil mit den letzten 30 Tagen statt mit dem letzten Ergebnis verglichen wird, löst ein CDN, dessen Knoten unterschiedliche Zertifikate ausliefern, nicht bei jedem Lauf eine Wechselmeldung aus.

Die Meldung geht an Abonnements mit dem Auslöser „Zertifikat geändert“, per E-Mail, Webhook oder in der App, und nennt den Standort und beide Zertifikate.

Die Voreinstellungen und ihre Gründe

Eine neue TLS-Prüfung warnt 14 Tage vor dem Ablauf und schlägt 3 Tage vorher fehl. Automatische Erneuerung geschieht üblicherweise etwa ein Drittel der Laufzeit im Voraus. Bei 14 Tagen ist die Erneuerung also schon überfällig, und 3 Tage Fehlerzustand lassen Zeit, sie von Hand nachzuholen. Beide Werte gelten je Prüfung, sodass ein Zertifikat einer internen Zertifizierungsstelle mit Jahreszyklus eigene Zahlen bekommen kann.

Die Prüfung läuft alle 6 Stunden, und ihre Standorte wechseln sich ab: Bei vier Standorten prüft jeder einmal am Tag. Was eine TLS-Prüfung findet, ändert sich über Stunden und Tage, nicht über Sekunden. Ob die Website überhaupt erreichbar ist, beantwortet eine HTTP-Prüfung im Abstand weniger Minuten; beide gehören zusammen.

Wenn der Server nicht erreichbar ist

Bleiben drei Versuche ohne Antwort, ist das Ergebnis „unbekannt“, mit dem Grund. Das Zertifikat wird dann nicht bewertet, und ein früherer Fehler wird dadurch nie zu einem Erfolg: Ein Standort, der zuletzt ein abgelaufenes Zertifikat gesehen hat, bleibt im Fehlerzustand, bis er ein gültiges sieht.

Andere Ports und interne Zertifikate

Jeder Port, der direkt mit TLS beginnt, lässt sich prüfen, etwa 465 oder 993 für Mail. Ist der Host eine IP-Adresse oder liefert er mehrere Namen aus, tragen Sie als Servernamen den Namen ein, den das Zertifikat abdecken soll. Für ein Zertifikat Ihrer eigenen Zertifizierungsstelle schalten Sie die Kettenprüfung aus: Ablauf und Hostname werden weiter geprüft. Die unten beschriebenen HTTP-Prüfungen laufen standardmäßig nur auf Port 443; in den Einstellungen der Prüfung lassen sie sich für HTTPS auf einem anderen Port ein- oder ausschalten.

HTTP-Header

Auf Port 443 liest der tägliche Konfigurationstest auch die HTTP-Header, die HTTPS absichern: Strict-Transport-Security, die Weiterleitung von Port 80 und das Secure-Attribut von Cookies. Fehlendes oder zu kurzes HSTS wird wie jeder andere Konfigurationsbefund als Abweichung von Mozillas Richtlinien gewertet; die übrigen Angaben werden erfasst und zählen für das fünfte Schloss der TLS-Bewertung. Werte von Cookies und Ziele von Weiterleitungen werden nie gespeichert.

Was unsere Prüfungen senden

Eine TLS-Prüfung ist eine gewöhnliche Client-Verbindung, wie die eines Browsers. Sie liest, was der Server vorlegt, und schließt die Verbindung. Einmal täglich je Server und Standort testet sie außerdem die Konfiguration des Servers mit bis zu 60 kurzen Testverbindungen und ruft bei Port 443 die Startseite einmal über HTTPS und einmal unverschlüsselt über Port 80 ab. Dabei liest sie nur die Header und folgt keiner Weiterleitung. Unsere Seite für Serverbetreiber nennt die Adressen, von denen die Prüfungen kommen: https://pingsured.eu/bot