Letsencrypt - Nutzung: Was ist kritisch, worauf sollte man achten? Worin liegt das Risiko bei der Nutzung von einem der vielen Tools?

09.06.2018 23:53:57, Jürgen Auer, keine Kommentare

Vor etwa zwei Wochen, nachdem für die eigenen Kunden eine Verwaltungsmöglichkeit für Dinge in bezug auf die DSGVO abgeschlossen waren, hatte ich meinen Letsencrypt-Client fertig gebaut.

Letsencrypt

https://letsencrypt.org/

bietet kostenlose SSL-Zertifikate an, die nur 90 Tage gültig sind und regelmäßig erneuert werden müssen. Technisch sind damit vollwertige Verschlüsselungen von Websites per https möglich. Gleichzeitig hatte Letsencrypt ein Protokoll, das Automatic Certificate Management Environment (ACME) entwickelt, mit dem der bis dahin meist händische Prozess einer Zertifikatsbeantragung plus Nachweis der Inhaberschaft über die Domain automatisiert werden konnte. Für ACME interessierten sich schnell andere Unternehmen. Damit wurde eine Version 2 entwickelt, die aktuell noch den Standardisierungsprozess bei der IETF (Internet Engineering Task Force) durchläuft. Sprich: Das Protokoll zur Kommunikation zwischen Client (Webserver, der ein Letsencrypt-Zertifikat beantragt) und den Servern von Letsencrypt, die diese Zertifikate ausstellen, wird ganz offiziell standardisiert.

Den eigenen Client gab es in einer ersten Version schon im Februar, zu dem Zeitpunkt war aber das ACME-v2 - Protokoll noch nicht produktiv nutzbar. Das gab es zu diesem Zeitpunkt nur auf dem Letsencrypt - Testsystem. Zu der Version 1, die seit Ende Dezember 2015 nutzbar ist, wollte ich mir keinen Client schreiben. Die hatte noch ein paar Einschränkungen. ACME-v2 unterstützt bsp. Wildcard-Zertifikate, also das, was ich in der Form von *.server-daten.de für alle Kundensubdomains nutze.

Ende Mai war das in einer ersten Version soweit fertig. Damit wurden die ersten Kundendomains mit Letsencrypt-Zertifikaten bestückt. Zunächst noch "teilmanuell". Seither hatte ich den Client ab und zu etwas weiterentwickelt und im Letsencrypt-Forum

https://community.letsencrypt.org/

etwas rumgelesen und geschrieben.

Wer überlegt, ebenfalls Letsencrypt zu nutzen und womöglich nicht einen der offiziellen Clients zu nutzen, sondern einen eigenen zu schreiben:

Die eigentliche Kommunikation mit Letsencrypt ist eher harmlos. Es gibt "nur" ein paar Schritte, die zu erledigen sind:

(1) Man muß einmalig einen Account erstellen. Dazu benötigt man ein RSA-Schlüsselpaar. Über einen Account kann man viele Domains verwalten.

(2) Man erzeugt eine neue Order. Das ist die Beantragung eines Zertifikats mit einem oder mehreren Domainnamen. Wobei bsp. ein übliches "kleines" Zertifikat zwei Domains, nämlich www.example.com und example.com enthält. Dazu gibt es eine Order-Url. Diese sammelt die Authorization-Urls und die Finalize-Url, über die schließlich der Zertifikatsrequest hochgeladen wird. Zu jeder Domain bekommt man eine Authorization-Aufgabe gestellt, das ist eine Url mit weiteren Daten. Jede Authorization-Url enthält eine http- und eine dns-Challenge. Diese bestehen jeweils aus einer Challenge-Url und einem langen Token (= Zufallszeichenfolge).

(3) Da sucht man sich aus, wie man seine Inhaberschaft über die Domain nachweisen will. Entweder erzeugt man unter /.well-known/acme-challenge/ eine Datei mit dem Token als Dateinamen und dem Token, einem Punkt und dem entsprechend codierten SHA256-Hash des eigenen Schlüssels. Das ist die http-01 - Challenge. Oder man nutzt die DNS-Variante. Dafür muß man einen DNS-TXT-Eintrag mit dem Namen _acme-challenge erstellen, dessen Wert ebenfalls nach einem bestimmten Prinzip aus dem Token und dem eigenen Schlüssel ermittelt wird.

(4) Hat man das gemacht, ruft man die Challenge-Url jeweils mit einem geeigneten POST-Befehl auf, um Letsencrypt mitzuteilen, daß die Challenges überprüft werden sollen.

(5) Ist Letsencrypt zufrieden, dann wechselt die zugehörige Authorization-Seite vom Status "pending" in den Status "valid". Sind alle Authorization-Seiten "valid", kann ein Zertifikatsrequest generiert und an die Finalize-Url geschickt werden. Stimmt der Zertifikatsrequest (Liste der Domainnamen) mit dem Order-Request bzw. der Liste der dortigen Domainnamen überein, dann wechselt die Order-Seite in den Status "valid" und bietet eine Zertifikatsurl, über die man sich das neue Zertifikat herunterladen kann.

Hat man einmal verstanden, wie man die JSON-Objekte aufbauen muß, dann ist das keine große Geschichte mehr.

Allerdings: Was spricht für einen eigenen Client?

Inzwischen hatte sich die Vermutung bestätigt, die mich schon im Februar dazu brachte, einen eigenen Client zu bauen. Und zwar sowohl angesichts der eigenen Erfahrungen als auch aufgrund dessen, was im Letsencrypt-Forum zu lesen ist.

Die Kommunikation mit Letsencrypt ist nur der eine Teil der Gesamtaufgabe. Der andere Teil besteht darin, daß lokal ein Account-Schlüsselpaar, zu jedem Zertifikat ein Schlüsselpaar und die eigentlichen Zertifikate verwaltet werden müssen. Ferner muß das heruntergeladene Zertifikat schließlich (bei Windows-Systemen) in Webhosting abgelegt und beim Webserver in die entsprechende Bindung eingehängt bzw. dort ausgetauscht werden (altes Zertifikat raus, neues rein).

Diese ganzen lokalen Aufgaben sind im Zweifelsfall weitaus kritischer als die Kommunikation mit Letsencrypt.

Und das eigentlich kritische ist: Bei Fehlern sollte der Job gestoppt und nicht einfach wiederholt werden.

Es gibt reihenweise Beispiele im Letsencrypt-Forum. Es wird ein Cronjob (o.ä.) eingerichtet, der sich eigentlich automatisch um das Aktualisieren der Zertifikate kümmern soll. Dann geht "irgendetwas" schief. Das wird nicht sofort bemerkt. Der Cronjob wiederholt sich. Und mit "etwas Pech" wurde 10 mal hintereinander korrekt ein Letsencrypt-Zertifikat beantragt, aber die Ausführung bzw. das Einbinden scheiterte aus irgendwelchen Gründen. Nun schlägt das Limit von Letsencrypt zu. Und man kann bsp. in den nächsten Tagen kein neues Zertifikat mehr beantragen, dann wird die Zeit knapp.

Der Nutzer "hat" also diverse neue Zertifikate aus den letzten Tagen, die allesamt 90 Tage gültig sind. Aber auf seinem Webserver läuft noch das Zertifikat, das in wenigen Tagen ausläuft. Und dem Nutzer ist völlig unklar, wie er die neuen Zertifikate finden und nutzen kann. Mit "etwas Pech" ist das nicht nur ein Zertifikat, sondern es sind noch ein paar mehr.

Sprich: Letsencrypt hat ein paar Limits (siehe https://letsencrypt.org/docs/rate-limits/ ). Man kann bsp. zu einer Domain nur maximal 20 Zertifikate pro Woche neu beantragen (Erneuerungen zählen nicht mit). Und man kann eine Kombination von Domainnamen innerhalb von einer Woche nur fünf mal erneut beantragen (Duplicate Certificate Limit).

Hängt irgendetwas bei der lokalen Verwaltung, merkt man das nicht sofort und läßt das weiterlaufen, dann stoppt das irgendwann - weil das Letsencrypt-Limit zuschlägt.

Das eigentliche Problem dabei: Den vielen Clients, die unter

Client-Options

https://letsencrypt.org/docs/client-options/

angeboten werden, "sieht" man es nicht so richtig an, ob sie bei irgendeinem Fehler (inklusive fehlenden Berechtigungen, Problemen bei der Validierung oder beim Einbinden des Zertifikats) und einem Neustart einen Tag später alles wiederholen, auf denselben Fehler laufen und damit in Richtung der Limits kommen. Oder ob es irgendeinen Mechanismus der Information gibt, so daß eine "sinnlose Wiederholung" vermieden wird.

Es macht nun mal keinen Sinn, wenn so ein Tool täglich einmal ausgeführt wird und dann an fünf oder zehn Tagen jedesmal gegen dieselbe Wand rennt, bis das Limit vollgelaufen ist.

Bei meinem eigenen Client ist das auf zwei verschiedenen Ebenen einigermaßen gelöst. Ein Gedanke ist, die Kommunikation mit Letsencrypt abzukoppeln vom Ändern der Bindung. Das eine Programm holt sich ein neues Zertifikat und importiert es unter "Webhosting". Das kann im Laufe eines Tages gemacht werden. Es kann einmal pro Tag ausgeführt werden und prüft alle Zertifikate unter "Webhosting", ob diese in Kürze auslaufen. Falls ja, wird ein neues Zertifikat geholt.

Das zweite Programm prüft zu jeder Bindung, ob es unter "Webhosting" ein neueres Zertifikat gibt. Falls ja, wird das Zertifikat ausgetauscht. Das zieht einen Neustart des Webservers nach sich. Das sollte eher am Abend stattfinden.

Diese Logik hat jedenfalls den Vorteil, daß ein Crash beim Zertifikatstausch nicht dazu führt, daß ein Zertifikat mehrfach innerhalb kurzer Zeit beantragt wird.

Aber eigentlich entscheidend ist eine Blockade innerhalb des ersten Programms: Kann ein Zertifikat heute nicht geholt werden, darf das morgen nicht einfach blind wiederholt werden. Das wurde so gelöst, daß das Erstellen einer Order bis hin zum Ablegen unter "Webhosting" in elf sehr kleine Schritte zerlegt wurde. Zu jeder Domain, zu der ein Zertifikat geholt wird, gibt es eine Art Steuerungsdatei. In die werden alle Daten geschrieben - plus der letzte erfolgreiche Schritt. Existiert so eine Datei, wird nicht bei Null begonnen, sondern mit dem nächsten Schritt weitergemacht. Da die Daten in Form einer Tabelle abgelegt werden, kann auf die Ergebnisse der vorherigen Schritte zurückgegriffen werden. Das ist also mehr als eine bloße Protokolldatei.

Ferner gibt es bei Letsencrypt ein Testsystem. Dort läuft alles wie auf dem Produktivsystem. Die Zertifikate werden aber von "Fake LE Intermediate X1" signiert. Damit läßt sich aber der gesamte Prozess mehrfach und schrittweise testen.

Mal sehen, wann ich mit der Hauptdomain *.server-daten.de ebenfalls auf Letsencrypt umziehe.

*
* (wird nicht angezeigt)
Die Erläuterungen zum Datenschutz habe ich gelesen und stimme diesen zu.