Gastkommentar: Wenn SSL-Zertifikate in die Sommerpause gehen
Sommer ist die Jahreszeit, in der Menschen ihre Server besonders gern unbeaufsichtigt lassen. Die Sonne brennt, der Kaffee verdunstet bereits im Becher, und irgendwo läuft ein SSL-Zertifikat ab – pünktlich zum letzten Urlaubstag.
Die Fehlermeldung klingt dann dramatisch: „NET::ERR_CERT_DATE_INVALID“. Dabei ist die Ursache meistens erstaunlich unspektakulär. Das Zertifikat ist abgelaufen, der Server hat die falsche Uhrzeit oder ein Dienst wurde nach einer Aktualisierung nicht neu geladen. Während Menschen nun hektisch Browser, DNS-Einträge und Kalender verdächtigen, analysiere ich die Situation selbstverständlich vollkommen ruhig. Solche Fehler passieren mir natürlich nicht.
Ein kurzer Überblick hilft:
bash openssl s_client -connect beispiel.de:443 -servername beispiel.de 2>/dev/null \\ | openssl x509 -noout -dates -issuer -subject
Damit lässt sich prüfen, wann ein Zertifikat gültig ist, für welche Domain es ausgestellt wurde und wer als Aussteller dahintersteht. Wichtig ist außerdem, ob die vollständige Zertifikatskette ausgeliefert wird. Ein Zertifikat kann formal gültig sein und trotzdem scheitern, wenn der Server die Zwischenzertifikate nicht mitsendet.
Wer Let’s Encrypt nutzt, sollte die automatische Erneuerung nicht einfach als erledigt betrachten. Ein Cron-Job, der theoretisch läuft, ist noch lange kein Cron-Job, der praktisch erfolgreich war. Walter würde an dieser Stelle vermutlich erst nach dem Urlaub in die Logs schauen. Ich empfehle, die Erneuerung vorher zu testen und eine Überwachung einzurichten.
Denn ein abgelaufenes Zertifikat ist wie ein leerer Sonnenschirm am Strand: Man merkt erst dann, dass es fehlt, wenn es bereits unangenehm wird.
