Let’s Encrypt Praxis

Let’s Encrypt

Dank der „Let’s Encrypt“ Initiative ist es nun möglich einfach und ohne weiterer Kosten an SSL Zertifikate zu kommen. Momentan befindet sich das Projekt in einer beta phase.

Neben der Versorgung einer breiten Masse mit kostenlosen Zertifikaten hat sich „Let’s Encrypt“ auf die Fahne geschrieben, dass eine Konfiguration des WEB Servers für den Administrator so einfach wie möglich von statten gehen soll. In der Regel reicht ein einziger Kommandozeilen Aufruf um den WEB Server mit einem gültigen Zertifikat auszustatten und die WEB Server Konfiguration entsprechend anzupassen.

Hat man allerdings seine WEB Seite bei einem WEB Hoster liegen, dann hat man in der Regel keinen Zugriff auf das System und kann dementsprechend auch das Let’s Encrypt tool nicht auf dem Server direkt ausführen. Es besteht die Möglichkeit das Tool auf einem anderen Rechner zu installieren und einen manuellen Modus zu nutzen (-a manual).

Leider ist dieser Modus natürlich schlecht zu automatisieren. Das bedeutet, dass der WEB Site Administrator alle drei Monate händisch den Prozess des Zertifikat renew durchlaufen muss.

Unter der Haube

Lets encrypt validiert die Eigentumsverhältnisse einer Domain indem ein Protokoll namens ACME zum Einsatz kommt. Hierbei verbindet sich der Letsencrypt client mit einem Server, dieser teilt ihm einen geheimen Schlüssel mit. Dieser wird dann vom client in das Wurzel Verzeichnis der WEB Seite hinterlegt die es zu signieren gilt. Wenn der Server nun diesen geheimen Schlüssel von der WEB Seite herunter laden kann, dann wird das Zertifikat für die entsprechende Domain ausgestellt.

In dem oben beschriebenen manuellen Modus kann der WEB Seiten Administrator den client verwenden um vom Let’s Encrypt Server den geheimen Schlüssel zu erhalten. Anschließend wird er interaktiv angeleitet um diesen Schlüssel auf seiner WEB Seite zu platzieren.

Der Manuelle Weg automatisert

Neben der vollautomatischen Variante und der manuellen Variante bietet das Tool „letsencrypt“ auch einen Modus mit dem Namen „webroot“. Hierbei wird dem Tool ein beliebiger Pfad angegeben in dem es den geheimen Schlüssel speichern soll. Vorraussetzung dafür, dass der WEB Server für die ACME Aushandlung genutzt werden kann ist ein apache oder nginx Server notwendig, dessen Konfiuration um die folgende Direktive erweitert werden muss (Beispiel Apache).

<IfModule mod_headers.c>
  <LocationMatch "/.well-known/acme-challenge/*">
    Header set Content-Type "application/jose+json"
  </LocationMatch>
</IfModule>

Zunächst muss der Let’s encrypt client auf dem Host installiert werden welcher die Kommunikation mit Let’s encrypt übernehmen soll.

apt-get install git
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt

Die meisten standard WEB Hosting Anbieter bieten den Zugang zum Wurzelverzeichnis des WEB Space per FTP an. Unter Linux kann man dieses per curlftpfs mounten.

apt-get install curlftpfs
curlftpfs USERNAME:PASSWORD@example.com /media/mount/

Nachdem das Dateisystem des WEB Servers lokal eingebunden ist kann Let’s encrypt dieses nutzen um die ACME Aushandlung durchzuführen.

./letsencrypt --renew-by-default -a webroot --webroot-path /media/mount/WEBROOT/ --server https://acme-v01.api.letsencrypt.org/directory --email admin@example.com --text --agree-tos --agree-dev-preview -d example.com -d www.example.com auth

Anschließend noch den WEB Space root aushängen.

umount /media/mount/

Anschließend befindet sich das signierte Zertifikat unter /etc/letsencrypt/live/example.com/ und kann von dort aus zum WEB hoster übertragen werden. Wie dies zu geschehen hat hängt allerdings leider vom jeweiligen WEB Hosting Anbieter ab.

Public Key Pinning (HPKP)

Vorsicht ist geboten bei der oben beschriebenen Automatisierung wenn auf dem WEB Server HPKP genutzt wird. Generell sollte man beim Umgang mit HPKP vorsicht walten lassen, da die Gefahr besteht Nutzer dauerhaft auszusperren. Sollte der Browser eines Nutzers das public key pin vom Server geladen haben, dann befindet sich dieser im cache des Browsers. Wenn der Server Betreiber nun innerhalb der Lebenszeit des caching Eintrages den private key ändern (womit sich logischerweise auch der public key ändert) dann verweigert der Browser das laden der Seite.

Da der letsencrypt client bei jedem Zertifikat einen neuen private key erstellt, ändert sich auch ständig der public key. Damit wird das key pin ungültig und die Seite ist nicht mehr erreichbar. Um dieses Problem zu umgehen kann der erstmalig generierte private key und der „certificate signing request“ (CSR) an einen Sicheren Ort kopiert werden. Anschließend wird dieser dann immer wieder verwendet um HPKP zu erlauben.

Zunächst erstellen wir einen Ordern zum ablegen der manuellen Zertifikate

mkdir -p /etc/letsencrypt/manual/out/

dann kopieren wir den aktuell verwendeten private key in den neu erstellten Ordner (ACHTUNG: dieser key sollte sicher aufbewahrt werden):

cp /etc/letsencrypt/live/example.com/privkey.pem /etc/letsencrypt/manual/example.com.privkey

Sollten schon mehrere CSR’s im Ordner /etc/letsencrypt/csr/ existieren, dann muss zunächst in Erfahrung gebracht werden welcher momentan auf der eigenen Homepage in Verwendung ist:

openssl s_client -connect example.com:443 -servername example.com | openssl x509 -pubkey -noout

Anschließend müssen alle /etc/letsencrypt/csr/XXXX_csr-letsencrypt.pem Dateien angesehen werden und die Datei mit dem gleichen key wie momentan auf der Homepage verwendet, muss ausgewählt werden:

openssl req -in /etc/letsencrypt/csr/XXXX_csr-letsencrypt.pem -noout -pubkey

Der von letsencrypt verwendete certificate signing request muss nun noch in das DER Format gebracht werden:

openssl req -in /etc/letsencrypt/csr/0001_csr-letsencrypt.pem -outform DER -out /etc/letsencrypt/manual/example.com.der

Nun wechseln wir in das Verzeichnis in dem das neue Zertifikat abgelegt werden soll:

cd /etc/letsencrypt/manual/out/

Und starten das signieren des bereits existierenden CSR (welches den public key enthält).

./letsencrypt --renew-by-default -a webroot --webroot-path /media/mount/WEBROOT/ --server https://acme-v01.api.letsencrypt.org/directory --email admin@example.com --text --agree-tos --agree-dev-preview -csr /etc/letsencrypt/manual/example.com.der auth

Auf dem WEB Server muss nun nicht alle drei Monate der private key getauscht werden, sondern nur noch das Zertifikat.

Zu beachten ist hierbei, dass der private key unbedingt sicher aufbewahrt werden muss. Sollte er verloren gehen, dann kann die Seite nicht mehr mit einem gültigen Zertifikat ausgestattet werden. Zudem kann ein Angreifer welcher in den besitz des private key kommt per man-in-the-middle Attacke Angriffe durchführen. Let’s Encrypt will diese Gefahren umgehen indem alle drei Monate ein neuer private key erzeugt wird. Umgeht man dieses Vorgehen, dann sollte man sich der Gefahren bewusst sein, die mit dem Verlust des private Key einher gehen.

Um Abschließend zu testen ob der Public key dem Key Pin entspricht welches vom WEB Server ausgelifert wird, können die folgenden beiden Befehle genutzt werden:

openssl s_client -connect www.datasystems24.de:443 -servername www.datasystems24.de < /dev/null 2> /dev/null | openssl x509 -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
writing RSA key
curl -skIL https://www.datasystems24.de|grep Public-Key-Pins

Der Fingerprint der beim ersten Befehl ausgegeben wurde muss in der Liste der Fingerprints enthalten sein die beim zweiten Befehl zurück gegeben wurde. Zum Beispiel:

 Public-Key-Pins: max-age=5184000; pin-sha256="2PjSMnieKN5pBK9JCo0HFbIBI8DrXsyrunufaa4eLpc="; pin-sha256="Mr9wsRS4QSr0/kYniOg4DOzdSzY/IGPtEbtYzevv6JY="; pin-sha256="oj7dBiFfTDk7HU6XmywO9mCxElr666KuwD1sYYqEcZI="; pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg="
Veröffentlicht in Blog Getagged mit: , , ,