Wechsel auf Letsencrypt
Ich hab' mich lange davor gescheut, auf eine eingebaute CA zu wechseln. Die typischen Gründe waren meine seltsamen Hostnamen, die ich benutze. Also brauch' ich meist eine ganze Latte an zusätzlichen Namen oder gar ein Wildcard. Das ist teuer. Letsencrypt bietet das inzwischen zwar an, ist aber wegen der kurzen Laufzeiten umständlich, denn ich will kein fremdgesteuertes Binärblob über meine Daten bestimmen lassen. Aber auch dafür gibt es inzwischen eine Lösung.
My server is my castle
Fremdsoftware, die ich nicht selbst kompilieren und halbwegs verstehen kann, mag ich nicht auf meiner Kiste laufen haben. Python und ähnlicher neumodischer Schnickschnack kommt mir nicht auf die Platte. Also fällt der Letsencrypt Client aus.
Man kann das ACME Protokoll natürlich von Hand nacharbeiten, aber das ist aufwendig. Und da es schon jemand gemacht hatte, war es auch keine besondere Herausforderung. Meine ersten Letsencrypt Zertifikate habe ich manuell über gethttpsforfree erzeugt. Da kann ich den Code lesen und außerhalb des Servers die Zertifikate erstellen.
Nur skaliert das leider nicht besonders gut. Der Aufwand der Zertifikatserneuerung kommt häufiger als notwendig (gefühlt) und es kostet zu viel Zeit während die Uhr tickt. Das ist kein Zustand, den ich lange durchhalten möchte.
Aufmerksam wurde ich aber als Letsencrypt gegen ein Bash-Skript vorging, weil es die Markenrechte(!) verletzen würde. Der Autor benannte das Script um und brachte seinen Unwillen ob dieses unfreundlichen Aktes zum Ausdruck. Allein aus Solidarität hab ich mir das Script angeschaut.
In den Tiefen der Shell
Dehydrated ist ein klar strukturiertes, verständliches Script, dass sich einem beherzten set -x nicht entgegen setzt. Auf den ersten Blick ein sympathisches Stück Software.
Unglücklicherweise läuft es nicht.
Die Fehler sind vielfältig und reichen von Inkompatibilitäten der Letsencrypt-Webseite mit meinem curl bis hin zu schlichten Programmabbrüchen.
+ Requesting challenge for lutz.donnerhacke.de... sed: -e expression #1, char 42: unterminated `s' command
Die verursachende Zeile sieht etwas overquoted aus:
challenges="$(printf '%s\n' "${response}" | sed -n 's/.*\("challenges":[^\[]*\[[^]]*]\).*/\1/p')"Beim besten Willen bekomme ich den sed-Ausdruck zum Laufen. Irgendwas ist mit den eckigen Klammern mächtig durcheinander geraten.
Also versuche ich mal zu verstehen, was der Ausdruck will und wie man ihn anders schreiben kann.
- Es wird alles vor dem Text "challenges": weggeschnitten.
- Dann werden alle Zeichen bis zur öffnenden eckigen Klammer mitgenommen.
- Und schließlich alle Zeichen bis zur nächsten schließenden eckigen Klammer.
- Der Rest wird verworfen.
- Gab es überhaupt einen Treffer, wird der zurück gegeben.
Anders gesagt:
... | sed -n '/"challenges":/{;s/.*\("challenges":\)/\1/;s/].*/]/;p;}')"Wenn also der Text da steht, werden drei Aktionen ausgeführt:
- Der Text vor dem Marker wird entfernt.
- Der Text hinter der ersten schließenden eckigen Klammer wird entfernt.
- Der Text wird ausgegeben.
Das ist praktisch gesehen die gleiche Aktion, diesmal aber in funktionierend.
Nach einigen Tests insbesondere hinsichtlich TLSA und Schlüsselwechsel, und natürlich mit abweichenden Schlüssellängen, kann es live gehen.
Total 1 comments