Alternativer Client für Let's Encrypt

Wie schon im 1. Artikel zu Let’s Encrypt kurz erwähnt ist die Installation des Clients und die notwendige Umgebung unter ~/.local/ nicht ganz durchsichtig. Als Alternative habe ich den Client acme-tiny getestet. Voraussetzung für den Client ist lediglich Python und OpenSSL. Der Quellcode ist unter 200 Zeilen und somit noch einigermaßen leicht nachvollziehbar.

Als weiteren Vorteil kann man durch Subject Alternative Names auch ein Zertifikat erstellen, dass für mehrere Domains (die auf den gleichen Server und Webspace verweisen) gültig ist. So kann also z.B. ein für die Domains krausmueller.de und www.krausmueller.de gültiges Zertifikat ausgestellt werden. Die README enthält alle notwendigen Schritte, weshalb ich nur kurz auf die aus meiner Sicht wichtigsten Schritte gesondert eingehe.

Die Domains für die das Zertifikat ausgestellt wird (Subject Alternative Names) werden in Schritt 2 angegeben.

Der Nachweis, dass die Domain auch von einem verwaltet wird erfolgt bei acme-tiny per Dateien im Ordner .well-known/acme-challenge/ unterhalb der Domain. Es muss also entweder beim Aufruf des Clients in Schritt 4 als acme-dir der volle Pfad zu diesem Ordner angegeben (also z.B. /var/www/domain/.well-known/acme-challenge) oder ein Alias auf ein anderes Verzeichnis angelegt werden, welches dann als acme-dir angegeben werden kann (Beispiel unten für Apache).

1
Alias /.well-known/acme-challenge/ "/var/www/challenges/"

Die Beispielkonfiguration in Schritt 5 der README ist für nginx. Ein Konfiguration für Apache könnte folgendermaßen aussehen:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
<VirtualHost *:443>
    ServerAdmin webmaster@localhost
    ServerName krausmueller.de
    ServerAlias www.krausmueller.de
    DocumentRoot /var/www/krausmueller

    SSLEngine on
    SSLCertificateFile      /home/johannes/lets_encrypt/signed.crt
    SSLCertificateChainFile /home/johannes/lets_encrypt/intermediate.pem
    SSLCertificateKeyFile   /home/johannes/lets_encrypt/domain.key
    SSLProtocol             all -SSLv2 -SSLv3 -TLSv1
    SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK
    SSLHonorCipherOrder     on
</VirtualHost>

Zusätzlich kann man noch alle HTTP-Zugriffe automatisch auf HTTPS umleiten. Als Ausnahme muss dabei der Ordner .well-known/acme-challenge definiert werden, da dieser Pfad beim Erneuern des Zertifikats per HTTP erreichbar sein muss.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    ServerName krausmueller.de
    ServerAlias www.krausmueller.de
    DocumentRoot /var/www/

    <IfModule mod_rewrite.c>
        RewriteEngine On
        RewriteCond %{REQUEST_URI} !^/\.well\-known/acme\-challenge/
        RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
    </IfModule>
</VirtualHost>

Für das Erneuern des Zertifikats muss wie in Schritt 6 der README beschrieben ein Script erstellt werden, welches dann per Cronjob regelmäßig ausgeführt wird.