Vorwort

Nachdem Mozilla starke Kritik an Wosign und Startcom geübt hat, entfernte nun Apple als erstes die Zertifizierungsstelle aus seinen Trust-Stores. Für den Otto-Normal-Verbraucher heißt das nun, dass die Zertifikate von StartCom und Wosign faktisch wertlos sind; es ist ungewiss, ob sich die CA davon wieder erholt, auch wenn die Maßnahme vorerst auf ein Jahr begrenzt ist, und sich WoSign dann erneut einer unabhängigen Überprüfung unterziehen lassen kann.

Damit bleibt Let’s Encrypt die letzte mir bekannte Möglichkeit, kostenlos SSL-Zertifikate zu nutzen. Und bei aller berechtigten Kritik an dem Vorgehen, Zertifikte nur für 90 Tage auszustellen und diese mit einem Client automatisiert erneuern zu lassen, ist das Verfahren zumindest transparent und quelloffen.

Wem der native Python-Client nicht zusagt, der kann aus einer Vielfalt von alternativen Clients wählen. Ich habe mich für getssl entschieden, und möchte hier kurz eine Einführung geben.

Installation

Getssl ist ein simples Bash-Skript – daher kann auch ein unerfahrener Entwickler in den Code schauen und nachvollziehen, was dort eigentlich passiert. Installiert wird das Skript folgendermaßen:

curl --silent https://raw.githubusercontent.com/srvrco/getssl/master/getssl > /usr/local/sbin/getssl
chmod 700 /usr/local/sbin/getssl

Anschließend kann man das Skript mit -h aufrufen, um sich verfügbare Parameter ausgeben zu lassen:

$ getssl -h
getssl ver. 1.61
Obtain SSL certificates from the letsencrypt.org ACME server

Usage: getssl [-h|--help] [-d|--debug] [-c|--create] [-f|--force] [-a|--all] [-q|--quiet] [-Q|--mute] [-u|--upgrade] [-U|--nocheck] [-w working_dir] domain

Options:
  -h, --help      Display this help message and exit
  -d, --debug     Outputs debug information
  -c, --create    Create default config files
  -f, --force     Force renewal of cert (overrides expiry checks)
  -a, --all       Check all certificates
  -q, --quiet     Quiet mode (only outputs on error, success of new cert, or getssl was upgraded)
  -Q, --mute      Like -q, but mutes notification about successful upgrade
  -u, --upgrade   Upgrade getssl if a more recent version is available
  -U, --nocheck   Do not check if a more recent version is available
  -w working_dir  Working directory

Konfiguration

Nun kann man die erste Konfiguration für eine Domain anlegen. Für example.org würde der Aufruf so aussehen:

getssl -c example.org

Wenn das der erste Aufruf des Skripts überhaupt ist, wird automatisch das Verzeichnis ~/.getssl angelegt. Darin befindet sich die globale getssl.cfg (die ebenfalls beim ersten Lauf angelegt wird), sowie ein Konfigurationsverzeichnis für jede Domain.

Globale Konfiguration

Hier eine Übersicht über die Konfigurationsvariablen:

Domain Konfiguration

Wie gesagt, existiert für jede angelegte Domain ein Verzeichnis unterhalb von ~/.getssl. Darin befindet sich eine weitere getssl.cfg, in welcher Einstellungen der globalen Konfiguration überschrieben werden können, und weitere Einstellungen getätigt werden müssen. In der Liste gehe ich nur auf Variablen ein, die nicht in der globalen Konfiguration auftauchen.

| SANS | Hier kann man SubjectAlternativeNames definieren. Es ist zu beachten, dass Let’s Encrypt für jeden Namen eine separate Prüfung verlangt. Man braucht also für alle Namen administrative Rechte. Wildcard-Einträge sind bei Let’s Encrypt nicht möglich. ACL Dieser Eintrag ist ein Bash-Array mit Pfaden, an denen das Challenge-File angelegt werden soll. Der erste Eintrag gilt für den eigentlichen Domainname. Wenn es SANS gibt, muss für jeden Name ein Pfad hinzugefügt werden (Reihenfolge entscheidet!). Let’s Encrypt prüft dieses Challenge indem es die Ressource per HTTP(S) abruft: http(s):///.well-known/acme-challenge/

Hat das Zertifikat keine weiteren Namen, enthält ACL logischerweise nur einen Eintrag.

Wenn nicht der lokale Webserver für die Domain zuständig ist, kann man das Challenge auch per SSH oder FTP auf einen entfernten Server schaffen lassen. Die Syntax dazu findet man in der Beispielkonfiguration.

Nachdem man sowohl die globale als auch die domain-spezifische Konfiguration erstellt und angepasst hat, kann man das Zertifikat ausstellen lassen:

getssl -f <domain>

Der Parameter -f forciert dabei das Erstellen des Zertifikats, unabhängig davon, ob das aktuelle Zertifikat noch gültig ist oder nicht. Wenn es einen Fehler gibt, kann man auch noch -d angeben. Dann läuft getssl im Debug-Modus und ist gesprächiger. Wenn die Ausstellung dann geklappt hat, kann man die Domain auf das Live-API umstellen.

Um getssl periodisch laufen zu lassen kann man einen Cronjob einrichten:

# Zertfikate erneuern
0  3  *  *  *  root      getssl -q -a

Der Parameter -a bewirkt, dass alle Zertifikate überprüft werden, -q heißt, dass getssl keine unnötigen Ausgaben produziert. Der Entwickler empfiehlt noch die Option -u mit anzugeben, welche das Skript selbstständig updated. Das ist natürlich nicht unbedenklich, bedenkt man, was passieren könnte, wenn der Github-Account des Entwicklers kompromittiert würde, und das Update statt einer neuen Version einen Schadcode herunterladen würde. Aber nicht nur das wäre ein Problem, sondern auch eine Änderung im Verhalten des Skripts wäre möglich. Im schlimmsten Fall kriegt man das erst mit, wenn ein Zertifikat abgelaufen ist. Ob man die Auto-Update-Funktionalität also nutzen will, hängt von einem selbst ab.

Fazit

getssl ist eine schöne und saubere Möglichkeit Let’s Encrypt auf dem eigenen Server auszurollen. Auch der Entwickler ist sehr nett und kompetent, und hat mir bei meinen 2 Problemen innerhalb kürzester Zeit geholfen.