Springe zum Inhalt

Let’s Encrypt: Erinnerung vor Zertifikatablauf

Die von Let's Encrypt kostenlos erhältlichen Zertifikate sind aktuell 90 Tage gültig. Bei vielen Zertifikaten, so z.B. bei vielen Subdomains mit eigenen Zertifikaten, fällt der Überblick schwer, wann welches Zertifikat in Kürze abläuft und erneuert werden muss. Eine automatische Erinnerung muss her.

Eine Methode, um automatisiert alle Zertifikate auf ihren bevorstehenden Ablauf zu testen, kann mit dem folgenden Bash-Script realisiert werden.

Die Zerifikate werden von Let's Encrypt im Verzeichnis "/etc/letsencrypt/live/<domain>/cert.pem" abgelegt. Das Script wertet mit Hilfe von OpenSSL das Gültigkeitsdatum jedes unter diesem Pfad gefundenen Zertifikats aus und gibt bei Überschreitung einer eingestellten Vorwarnzeit eine Meldung aus. Wenn das Script per Cron automatisch ein Mal am Tag ausgeführt wird, erhält man vor dem Zertifikatablauf eine entsprechende Mail.

#!/bin/bash
 
DATADIR=/etc/letsencrypt
OPENSSL=/usr/bin/openssl
DATE=/bin/date
WARNSEC=$((7*24*60*60))
 
if [ ! -x $OPENSSL ]; then
	echo OpenSSL nicht gefunden!
	exit 1
fi
if [ ! -x $DATE ]; then
	echo Date nicht gefunden!?
	exit 1
fi
 
for cert in $DATADIR/live/*/cert.pem; do
	info=$($OPENSSL x509 -in $cert -noout -subject -enddate -checkend $WARNSEC) ||
		echo Folgendes Zerifikat läuft bald ab: $info
done
exit 0

Update vom 05.02.2016: Überarbeitetes  Script nach einem Hinweis aus den Kommentaren. Danke an Lutz und Michael!

Bei WARNSEC kann eingestellt werden, wie viele Tage vorher eine E-Mail als Erinnerung ausgegeben werden soll. openssl erwartet eine Angabe in Sekunden. Deshalb wird hier sofort umgerechnet.

Das obige Script speichert man z.B unter "/usr/local/bin/letsencrypt_checkcerts" und erstellt anschließend einen Eintrag für Cron, der das Script ein Mal am Tag aufruft.

Schon ist man sicher, keinen Zertifikatsablauf mehr zu verpassen.

10 Gedanken zu „Let’s Encrypt: Erinnerung vor Zertifikatablauf

  1. Philipp

    Kannst du mir mal erklären warum du die Pfade der binaries hardcodest? Es gibt nicht umsonst die PATH Variable. Wenn du prüfen willst ob die benötigten binaries da sind, kannst du dir mit which den pfad geben lassen. Würde ungefähr so aussehen:
    which openssl >/dev/null 2>&1 || exit 1
    Besonders lustig in dem Fall ist, dass du es nichtmal konsequent benutzt. In Zeile 5 setzt du DATE aber in Zeile 6 benutzt du date einfach so.

    Philipp

    Ps: bist du dir sicher, dass die bash immer in /bin ist?

    1. shogun

      Die Pfade der Binaries fest zu kodieren ist ein Sicherheitsaspekt. Nicht umsonst findet man z.B. in /etc/init.d fast kein Script, welches which verwendet. Unter Cron könnte das Script auch noch unter einem anderen User laufen, der vielleicht einen ganz anderen Pfad gesetzt hat. Dort könnte irgendjemand einem openssl im Pfad unterjubeln...

      Danke für den Hinweis auf den Fehler in Zeile 6. Wird sofort korrigiert.

      Ob die Bash immer unter /bin liegt kann ich leider nicht sagen. Es ist das erste Script, bei dem ich erste Anstrengungen in Sachen Portabilität unternehmen wollte. Es muss ja nicht immer Linux sein...

  2. Jan

    Let's Encrypt versendet zur Zeit bereits etwa 20 Tage vor Ablauf eines Zertifikats eine Mail an die angegebene Adresse:

    "Your certificate (or certificates) for the names listed below will expire in 20 days (on 2016-02-17 16:03:00 +0000 UTC). Please make sure to renew your certificate before then, or visitors to your website will encounter errors."

    1. Jens Tautenhahn

      Nun ist es auch bei mir so weit, ein paar Zertifikate laufen in einer Woche ab. In diesem Artikel steht zwar, dass eine Benachrichtigung kommen sollte, hier jedoch kam für 5 Subdomains keine an, obwohl ich eine funktionierende E-Mail-Adresse bei der Registrierung angegeben habe.

  3. Michael

    Danke für die gute Idee. Ich werde sie forken und nicht eine Erinnerung verschicken, sondern das Zertifikat-Renewal anstoßen.
    Bei uberspace mache ich das momentan per cron, aber so ist es eleganter.

    1. shogun

      Danke. "-checkend" ist für diesen Test sehr praktisch, war mir bis jetzt jedoch unbekannt. Ich werde mein Script mal anpassen.

      Die Vorgehensweise, nur die im Webserver verwendeten Zerifikate zu überprüfen hat auch ihre Vorteile und ist wohl die richtige für euren Zweck. Hier hatte ich jedoch auch mal daran gedacht, nicht-HTTP-Dienste mit Zertifikaten auszustatten. Deshalb schien mir das Testen auf das Let's Encrypt Verzeichnis am geeignetsten.

  4. Jens Tautenhahn

    Überarbeitetes Script mit korrekter Prüfung auf das Ablaufdatum des Zertifikats. Danke an Lutz und Michael!

Kommentare sind geschlossen.