Wann ein SSL-Zertifikat abläuft prüfen

Der schnelle Weg: das Schloss-Symbol und eine Online-Prüfung

Klicken Sie in einem beliebigen Browser auf das Schloss-Symbol in der Adressleiste, öffnen Sie die Zertifikatsdetails und lesen Sie "Gültig ab" und "Gültig bis". Das dauert zehn Sekunden und zeigt Ihnen, was Ihr eigener Browser sieht. Die Einschränkung dabei: Es deckt nur das Zertifikat ab, das an Sie ausgeliefert wurde, vom Edge-Knoten oder Server, den Sie zufällig erreicht haben, in dem Moment, in dem Sie nachgesehen haben.

Eine Online-SSL-Prüfung führt denselben Handshake von außerhalb Ihres Netzwerks aus und meldet das Ablaufdatum, den Aussteller, die vom Zertifikat abgedeckten Namen und ob die ausgelieferte Kette vollständig ist. Browser verbergen diesen letzten Punkt, die externe Prüfung zeigt Ihnen also etwas, das das Schloss-Symbol nicht kann.

Der manuelle Weg mit openssl

Ein Befehl gibt das Gültigkeitsfenster aus:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null   | openssl x509 -noout -dates -subject -issuer

Das Flag -servername sendet SNI, was wichtig ist, weil die meisten Server mehrere Zertifikate auf einer Adresse hosten und Ihnen ohne dieses Flag das falsche aushändigen. Die Ausgabe liefert notBefore und notAfter in UTC sowie den Inhaber und Aussteller des Zertifikats.

Um die gesamte vom Server gesendete Kette zu sehen statt nur das Blattzertifikat:

openssl s_client -connect example.com:443 -servername example.com -showcerts < /dev/null

Lesen Sie den Block "Certificate chain" oben: Sie sollten das Blattzertifikat sehen, dann ein oder mehrere Zwischenzertifikate. Eine Zeile "verify error: unable to get local issuer certificate" bedeutet, dass der Server das Zwischenzertifikat nicht sendet, was viele Browser überdecken und viele API-Clients, mobile Apps und ältere Systeme nicht tun.

Blattzertifikat, Kette und was abläuft

An einer normalen HTTPS-Verbindung sind drei Zertifikate beteiligt, und jedes hat sein eigenes Ablaufdatum:

• Das Blattzertifikat ist das für Ihre Domain ausgestellte Zertifikat. Es ist das kurzlebige, typischerweise 90 Tage bei automatisierter Ausstellung und bis zu etwa einem Jahr bei einem gekauften, und es ist das, was gemeint ist, wenn von "dem Zertifikat" die Rede ist.
• Das Zwischenzertifikat signiert das Blattzertifikat und muss vom Server zusammen damit gesendet werden. Es hält sich über Jahre, und gerade weil es sich so selten ändert, überrascht sein Ablauf Teams so oft.
• Das Root-Zertifikat liegt im Truststore des Clients, nicht auf Ihrem Server. Läuft ein Root-Zertifikat ab oder verliert das Vertrauen, beginnen ältere Geräte, die das Update nie erhalten haben, zu scheitern, während aktuelle einwandfrei funktionieren, was einen Ausfall erzeugt, der vom eigenen Laptop aus unmöglich wirkt.

Validieren Sie also die Kette, nicht nur das Datum auf dem Blattzertifikat. Ein Blattzertifikat mit zwei verbleibenden Monaten auf einer defekten Kette schlägt für manche Clients bereits fehl.

Warum Ablauf der häufigste vermeidbare Ausfall ist

Zertifikatsablauf ist ein ungewöhnlich schädlicher Ausfall. Er scheitert vollständig statt allmählich, denn ein Browser lehnt die Verbindung rundheraus ab und zeigt statt der Website eine seitenfüllende Warnung. Der Zeitpunkt, zu dem es geschieht, stand bereits am Tag der Ausstellung fest, und niemand hat dieses Datum im Blick behalten. Er legt außerdem alles gleichzeitig lahm, was den Namen verwendet, nicht nur die Website: APIs, mobile App-Backends, Webhooks und Integrationen. Fehlgeschlagene Zahlungs-Callbacks und defekte Integrationen kosten oft mehr als die sichtbare Ausfallzeit.

Er ist zudem vollständig vermeidbar, weshalb sich für diesen Ausfall eine automatisierte Prüfung am meisten lohnt.

Wie automatische Verlängerung trotzdem scheitert

Automatisierte Ausstellung hat die meisten Abläufe beseitigt und dafür eine Reihe schwerer erkennbarer Ausfälle eingeführt:

• Die Verlängerung lief, aber nichts wurde neu geladen. Ein neues Zertifikat liegt auf der Festplatte, während der Webserver weiter das alte aus dem Speicher ausliefert, bis er neu geladen wird.
• Die Validierungs-Challenge ist kaputtgegangen. Eine Weiterleitungsregel, eine Firewall-Änderung oder ein neues CDN vor dem Ursprung blockiert den HTTP-Challenge-Pfad, sodass die Verlängerung wochenlang ohne sichtbares Symptom fehlschlägt.
• DNS-Validierung hat ihre Zugangsdaten verloren. Ein API-Token wurde rotiert oder ist abgelaufen, und die DNS-Challenge kann ihren Eintrag nicht mehr anlegen.
• Der Verlängerungs-Timer läuft nicht mehr. Ein Container wurde ohne den Cron-Job oder Systemd-Timer neu gebaut, oder die Maschine wurde migriert und der Zeitplan kam nicht mit.
• Nur ein Knoten hat verlängert. Hinter einem Load Balancer hat ein Server das neue Zertifikat, ein anderer liefert noch das alte aus, sodass Fehler zeitweise wirken.
• Verlängerungs-E-Mails gingen an jemanden, der das Unternehmen verlassen hat. Die Variante desselben Problems bei gekauften Zertifikaten.
• Das Zertifikat wurde verlängert, aber nicht für jeden Namen. Eine später hinzugefügte Subdomain fehlt im neuen Zertifikat, sodass genau dieser Hostname scheitert.

Jeder dieser Fälle ist von innerhalb des Verlängerungssystems unsichtbar und von außen offensichtlich. Das ist das Argument dafür, den echten Handshake zu prüfen, statt den eigenen Protokollen der Automatisierung zu vertrauen.

Die Prüfung automatisieren

Ein Datum abzulesen beantwortet die Frage für heute, und das ganze Problem beim Ablauf ist, dass er an einem Tag eintritt, den niemand zum Nachsehen ausgewählt hat. Geplantes Zertifikats-Monitoring führt den echten Handshake in einem Intervall von außen aus, warnt eine festgelegte Anzahl von Tagen vor notAfter und erkennt die Ketten- und Hostname-Probleme, die eine Kalendererinnerung nie erkennen würde. HostTracker benachrichtigt per E-Mail, SMS, Sprachanruf, Slack, Telegram und mehr, sodass die Warnung jemanden erreicht, bevor der Ablauf es tut. Das Domain- und TLS-Monitoring führt die Prüfung fortlaufend aus, das SSL-Check-Tool für eine einmalige Prüfung, und wie Sie prüfen, ob ein Port offen ist behandelt einen Handshake, der bereits scheitert, bevor überhaupt ein Zertifikat angeboten wird.