SSL-Zertifikate mit Let's Encrypt

Die Erstellung von SSL-Zertifikaten zur Verschlüsselung von Server-Verbindungen ist dank StartCom kostenlos, aber mit jährlichem Aufwand verbunden, da die beantragten Zertifikate jährlich erneuert werden müssen.

Selbstsignierte Zertifikate sind für den Einsatz auf privaten Seiten zur Absicherung zwar sinnig, führen aber zu Sicherheitswarnungen, was sie für den produktiven Betrieb einer öffentlichen Internetseite ausschließt.

Eine spannende Möglichkeit, um an kostenlose SSL-Zertifikate zu gelangen, bietet nun die Internet Security Research Group (ISRG), einem Zusammenschluss mehrerer Firmen, u.a. Mozilla, Cisco und OVH, die mit Let's Encrypt einen Dienst zur Verfügung stellen, der automatisiert Zertifikate erstellt und ausgibt. Der Antragsteller muss lediglich verifizieren, dass er Zugriff auf die Domain hat.

Let's Encrypt herunterladen

Für den Einsatz von Let's Encrypt sind eine Reihe von Python-Anwendungen nötig, die über Github verfügbar sind. Falls git auf dem Server noch nicht installiert ist, muss dies nachinstalliert werden:

sudo apt-get update
sudo apt-get install git

Danach wechseln wir in ein Verzeichnis, in dem Let's Encrypt installiert werden kann (zum Beispiel /root) und klonen die aktuelle Version:

git clone https://github.com/letsencrypt/letsencrypt

Das Skript legt ein Verzeichnis letsencrypt an, in dem sich u.a. die Datei letsencrypt-auto befindet. Falls keine Rechte zum Ausführen gesetzt sind, fügen wir welche hinzu:

chmod +x ./letsencrypt-auto

Zertifikate erstellen

mit Dialog

Let's Encrypt bietet es an, vollautomatisch Zertifikate zu generieren und gleich in die Apache-Konfiguration aufzunehmen. Dafür reicht ein parameterloser Aufruf des Programms-. Wer nur die Zertifikate und keine Konfiguration braucht, kann Let's Encrypt mit folgendem Aufruf starten:

sudo ./letsencrypt-auto --rsa-key-size 4096 certonly

Dabei legen wir eine RSA-Key-Länge von 4096 statt standardmäßig 2048 fest, um die Sicherheit der Verschlüsselung zu erhöhen. Der Befehl certonly generiert nur Zertifikate ohne den Webserver zu konfigurieren. Beim ersten Aufruf installiert Let's Encrypt automatisch die erforderlichen Pakete nach.

Im nächsten Schritt fragt Let's Encrypt wie die Verifizierung vorgenommen werden soll. Hier bediene ich den zweiten Weg, das Ablegen einer Datei im Root-Verzeichnis der Domain:

2 Place files in webroot directory (webroot)

Let's Encrypt fragt dann, für welche Domain ein Zertifikat erstellt werden soll. Alle Domainnamen, die wir hier angeben, werden als Alternativ-Name im Zertifikat hinterlegt.

Im nächsten Schritt wird dann der Pfad der Seite angegeben. Let's Encrypt wird im nächsten Schritt einen Pfad .well-known anlegen. Es ist also zu überlegen, diesen Pfad für alle Domains auf ein Verzeichnis umzuleiten und dieses als webroot anzugeben. Ansonsten klickt man sich einmal bis zum richtigen Verzeichnis durch. Pro Domain muss hier ein eigenes Verzeichnis angegeben werden. Wer nur ServerAlias-Domains verschlüsseln möchte, kann dann das Webroot-Verzeichnis der Hauptdomain angeben.

Hat alles geklappt, erstellt Let's Encrypt ein Verzeichnis unterhalb von /etc/letsencrypt/live, in dem die verschiedenen 4 Zertifikate angelegt werden.

Damit sind die Zertifikate erstellt.

über Parameter

Der Aufruf lässt sich auch direkt über einen parametersteuerten Befehl ausführen. Dafür führt man aus dem letsencrypt-Verzeichnis folgenden Befehl aus:

sudo ./letsencrypt-auto --rsa-key-size 4096 certonly --webroot -w /var/www/vhosts/lukasthiel.de/htdocs/ -d lukasthiel.de -d www.lukasthiel.de

Der Speicherort ist derselbe wie beim obigen Aufruf.

über Datei

Es ist ebenfalls möglich, die Zertifikate über eine Konfigurationsdatei erstellen zu lassen. Das hat zwei immense Vorteile gegenüber der beiden obigen Lösungen:

1. die Konfiguration ist über Shell manipulierbar, was beim automatischen Anlegen von VHost von Vorteil ist
2. bei Konfigurationsänderungen reicht die Anpassung der Datei, ohne dass der Parameterbefehl gespeichert sein muss

Die Lösung hat Uwe Debacher in einem Artikel vorgestellt.

 # Wir nutzen 4096 bit RSA key statt 2048
 rsa-key-size = 4096
 
 # allgemeine Angaben
 email = letsencrypt@meine-maildomain.de
 authenticator = webroot
 
 # Domains fuer die wir Zertifikate beantragen, die erste in
 # der liste legt den Hauptnamen fest. Alle Domains müssen beim
 # Aufruf erreichbar sein
 domains = lukasthiel.de, www.lukasthiel.de
 
 # Dies ist das Verzeichnis zur Domain, wo letsencrypt seinen Hash in
 # /.well-known/acme-challenge schreiben will. Der Pfad muss auf / enden
 # es muss in der vserver.conf stehen:   Alias /.well-known   /var/www/htdocs/.well-known
 webroot-path = /var/www/htdocs/

Die Erstellung erfolgt dann über

/usr/bin/certbot certonly --config /var/www/vhosts/meine-maildomain.de/letsencrypt.ini

Konfiguration Apache2

Für Apache2 ist folgende Konfiguration aufzunehmen (example.org muss natürlich durch den entsprechenden Hostnamen ersetzt werden):

<VirtualHost *:443>
        ServerAdmin webmaster@example.org
        ServerName example.org
        SSLEngine on
        SSLCertificateFile /etc/letsencrypt/live/example.org/cert.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/example.org/privkey.pem
        SSLCertificateChainFile /etc/letsencrypt/live/example.org/chain.pem
        DocumentRoot /var/www/vhosts/example.org/htdocs
        <Directory /var/www/vhosts/example.org/htdocs/>
                Options FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>
        SSLProtocol All -SSLv2 -SSLv3
        SSLHonorCipherOrder On
        SSLCompression off
        # Add six earth month HSTS header for all users...
        Header add Strict-Transport-Security "max-age=15768000"
        SSLCipherSuite EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA 

         ErrorLog /var/log/apache2/example.org.error.log
         LogLevel warn
         CustomLog /var/log/apache2/example.org.access.log combined
</VirtualHost>

Laut Thomas Leister muss ab Apache 2.4.8 auf die Chain-Datei verzichtet werden. Die entsprechenden Zeilen sehen dann wie folgt aus:

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/example.org/fullchain.pem # statt cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.org/privkey.pem

Nach einem

sudo service apache2 reload

sollte die Konfiguration laufen und die Seite unter https://example.org erreichbar sein.

Konfiguration Postfix und Dovecot

Die Zertifikate lassen sich nicht nur für die Absicherung von HTTPS-Verbindungen nutzen, sondern auch für die sichere Kommunikation mit dem Mailserver. Dafür werden die Zertifikate in den entsprechenden Konfigurationsdateien von Postfix und Dovecot eingebunden:

/etc/postfix/main.cf

# tls config
smtpd_use_tls = yes
smtp_tls_note_starttls_offer = yes
smtpd_tls_key_file = /etc/letsencrypt/live/example.org/privkey.pem
smtpd_tls_cert_file = /etc/letsencrypt/live/example.org/fullchain.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_mandatory_protocols=!SSLv2, !SSLv3
tls_random_source = dev:/dev/urandom
tls_random_prng_update_period = 3600s

und /etc/dovecot/dovecot.conf

ssl = yes
ssl_cert = </etc/letsencrypt/live/example.org/fullchain.pem
ssl_key = </etc/letsencrypt/live/example.org/privkey.pem

Nach einem Neustart sollten die neuen Zertifikate aktiviert sein:

sudo service postfix restart
sudo service dovecot restart

Nachtrag vom 19.10.2017

Unsere Uni-Server erfordern eine verschlüsselte Verbindung zwischen Mailservern. Die o.g. Konfiguration nutzt zwar TLS für die Verbindung zwischen Client und Server, aber nicht für den Transport der Mails über den eigenen Server hinaus. Hierfür sind folgende Ergänzungen in der main.cf nötig

smtpd_tls_security_level = may
smtp_tls_security_level = may

Der Modus "may" bedeutet hier "Opportunistic TLS", d.h., dass eine TLS-Verbindung genutzt wird, sofern beide Server sich damit verstehen. Bietet der gegenübersprechende Server kein TLS an, wird auch keins genutzt. Postfix-Doku

Nachtrag vom 27.06.2023

Es hätte mir vor sechs Jahren auch ohne Informatikstudium klar sein sollen, dass eine Verschlüsselung der Transportwege immer erfüllt sein muss. Daher muss es korrekt heißen:

smtpd_tls_security_level      = secure
smtp_tls_security_level       = secure

Cron-Job für die Aktualisierung

Da die Zertifikate nach drei Monaten ablaufen, müssen die dann neu erstellt werden. Let's Encrypt bietet das vollautomatisch an. Es reicht ein Cronjob als root:

0 3 * * * /root/letsencrypt/letsencrypt-auto renew > /dev/null 2>&1

Let's Encrypt überspringt dabei Zertifikate, die noch gültig sind und aktualisiert nur diejenigen, die abgelaufen sind.

Links

• https://letsencrypt.org/
• https://thomas-leister.de/internet/anleitung-fuer-lets-encrypt-kostenlose-tls-zertifikate-fuer-alle/
• https://kofler.info/lets-encrypt-zertifikate-fuer-web-und-mail-unter-ubuntu-16-04/
• https://www.debacher.de/ublog/2016/06/letsencrypt/