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:
- die Konfiguration ist über Shell manipulierbar, was beim automatischen Anlegen von VHost von Vorteil ist
- 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.
