SSL-Zertifikate mit Let's Encrypt: Unterschied zwischen den Versionen
Lukas (Diskussion | Beiträge) |
Lukas (Diskussion | Beiträge) |
||
Zeile 103: | Zeile 103: | ||
sudo service postfix restart | sudo service postfix restart | ||
sudo service dovecot 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. [http://www.postfix.org/postconf.5.html#smtp_tls_policy_maps Postfix-Doku] | |||
== Cron-Job für die Aktualisierung == | == Cron-Job für die Aktualisierung == |
Version vom 12. Februar 2018, 14:03 Uhr
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.
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
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.