Mein 1&1 cloud server, Teil 4, Apache und Let’s Encrypt, Fortsetzung
Der 4. Teil meiner Artikelserie beschäftigt sich mit den Sicherheitseinstellungen des Apache Servers, sowie der Konfiguration des Let’s Encrypt Clients und der Einrichtung einer automatischen Zertifikatserneuerung. Die Grundkonfiguration des Apache Servers und die erste Erstellung eines Let’s Encrypt Zertifikates haben wir im 3. Teil der Artikelserie besprochen. Nun wollen wir uns die Konfiguration des Apache und des Let’s Encrypt Clients noch im Details anschauen. Zunächst betrachten wir die Konfiguration für unsere Default HTTPS Seite, die der Let’s Encrypt Client erzeugt hat.
Wir sehen, dass der Let’s Encrypt Client das Zertifikatfile, das Schlüsselfile, ein File für die Zertifikatskette sowie einen Server Namen eingetragen hat. Eine HTTPS Konfiguration ohne Servernamen ist sinnlos, da das Serverzertifikat hier für einen bestimmten Servernamen ausgestellt wurde. Schliesslich hat der Let’s Encrypt Client noch eine Include Anweisung eingefügt. Die Datei /etc/letsencrypt/options-ssl-apache.conf enthält zusätzliche Anweisungen zur ssl Konfiguration.
Zuletzt wollen wir noch „HTTP Strict Transport Security“ HSTS konfigurieren. Dazu ergänzen wir die Konfigurationsdatei am Ende mit den folgenden beiden Zeilen:
1
2
# HTTP Strict Transport Security, HSTS
Header always set Strict-Transport-Security"max-age=31536000"
Damit sieht unsere Datei /etc/letsencrypt/options-ssl-apache.conf jetzt wie folgt aus:
Header always set Strict-Transport-Security"max-age=31536000"
Die letzten beiden Anweisungen benötigen das Headers Modul des Apache servers, weshalb wir das Headers Modul noch aktivieren und anschließend den Apache restarten müssen.
Shell
1
2
3
4
5
6
$a2enmod headers
Enabling module headers.
Toactivate the newconfiguration,you need torun:
service apache2 restart
$service apache2 restart
*Restarting web server apache2
Nun werden wir die Sicherheit unseres Servers mit zwei Online-Testsuiten für SSL Server untersuchen. Als erstes nutzen wir den SSL Server Test der Qualys SSL Labs. Dazu tragen wir auf der SSL Server Test Seite unsere Domain ein, setzen gegebenenfalls das Häkchen bei „Do not show the results on the boards“ und klicken den Submit Button. Der Test dauert mehr als eine Minute. Wenn der Testdurchlauf beendet ist gibt er uns einen detailierten Bericht zu unserem Webserver.
Qualys SSL Report Summary
Wie wir sehen haben wir ein Overall Rating A+ und nur beim Key Exchange fehlen uns 10 von 100 Punkten. Details zur Bewertung sind im SSL Server Rating Guide nachzulesen.
Wenn wir jetzt nach unten scrollen finden wir unter Configuration den Abschnitt Handshake Simulation.
Qualys SSL Report Configuration
Hier sehen wir, dass wir mit unserer Konfiguration einige Browser, bzw. Clients vom Zugriff auf unsere Webpage ausschließen. Details zu den Clients findet man unter den jeweiligen Links.
Bevor wir über Anpasssungen unserer Konfiguration sprechen schauen wir uns das Ergebnis einer weitere Testsuite an. Die High-Tech Bridge SA stellt mit ihrem Free SSL Server Test ebenfalls eine Testseite zur Verfügung. Auf dieser Seite geben wir ebenfalls unsere Domain ein, setzen gegebenenfalls das Häkchen bei „Do not display test results in statistics“ und klicken dann auf das blaue Dreieck im Domainnamenfeld. Der Test dauert ebenfalls etwa eine Minute und auch hier erhalten wir einen ausführlichen Bericht, der allerdings etwas andere Schwerpunkte setzt.
HTBridge Server Test Summary
Hier erhalten wir FINAL GRADE A und wir können den Bericht als PDF herunterladen. Dokumentation zu den durchgeführten Tests finden wir unter den beiden Links im Kasten „SSL/TLS Security Test by High-Tech Bridge„. Wenn wir weiter nach unten scrollen, sehen wir im Abschnitt „Test For Compliance With NIST Guidelines„, dass unsere Konfiguration in einigen Punkten nicht den NIST Guidelines entspricht.
HTBridge Server Test Nist Guidelines
Laut NIST Guidelines sollten wir TLSv1.1 einschalten und weitere CIPHERS konfigurieren. Deshalb nehmen wir nun nochmals Änderungen an unserer Konfiguration vor und testen anschließend nochmals mit beiden Testsuites.
Header always set Strict-Transport-Security"max-age=31536000"
Unsere beiden ursprünglichen Konfigurationen habe ich behalten, mit einem Kommentar versehen und auskommentiert. Wir können also bei Bedarf schnell zwischen den Konfiguationen wechseln.
Jetzt erhalten wir FINAL GRADE A+, sehr schön! Wir scrollen weiter nach unten und schauen uns die Abschnitte „Test For Compliance With NIST Guidelines„und „Test For Industry Best-Practices“ an.
HTBridge Server Test Nist Guidelines neuHTBridge Server Test Best Practices neu
Die einzigen beiden Schwachstellen sind das Fehlen von OCSP Stapling und HTTP-Public-Key-Pinning (HPKP). Mit beiden Erweiterungen werden wir uns in einem späteren Artikel beschäftigen.
Nun werfen wir noch einen Blick auf die Ergebnisse unserer Testergebnisse bei Qualys SSL Labs.
Qualys SSL Report Summary neu
Das Overall Rating A+ ist uns erhalten geblieben. Im Rating für den Protocol Support haben wir 5 und in der Cipher Strength 10 Punkte verloren. Insgesamt aber immer noch ein gutes Ergebnis. Nun werfen wir noch einen Blick auf den Abschnitt Configuration.
Qualys SSL Report Configuration neu
Wir sehen, es sind immer noch eine ganze Reihe älterer Clients vom Zugriff auf unsere Seite ausgeschlossen. In den meisten dieser Fälle ist das Fehlen des TLSv1 Protokolls in unserer Konfiguration verantwortlich. Detailierte Informationen zu den Clients findet man unter den jeweiligen Links. Falls das TLSv1 Protokoll benötigt wird, können wir es in unserer Konfiguration aktivieren, ohne die A+ Bewertung zu verlieren. In meinem Falle möchte ich die Konfiguration zunächst so belassen.
Nun wollen wir noch eine automatische Erneuerung unserer Let’s Encrypt Zertifikate konfigurieren. Zunächst legen wir eine Konfigurationdatei für Let’s Enrypt im Verzeichnis /etc/letsencrypt an. Dazu kopieren wir die Beispielkonfiguration /root/letsencrypt/examples/cli.ini in das Verzeichnis /etc/letsencrypt und passen sie an unsere Bedürfnisse an.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
# This is an example of the kind of things you can do in a configuration file.
# All flags used by the client can be configured here. Run Let's Encrypt with
# "--help" to learn more about the available options.
# Use a 4096 bit RSA key instead of 2048
rsa-key-size=2048
# Uncomment and update to register with the specified e-mail address
email=whoever@whereever.de
# Uncomment and update to generate certificates for the specified
# domains.
# domains = example.com, www.example.com
# Uncomment to expand the cert with additional names
# expand = True
# Uncomment to use a text interface instead of ncurses
# text = True
# Uncomment to use the standalone authenticator on port 443
# authenticator = standalone
# standalone-supported-challenges = tls-sni-01
# Uncomment to use the webroot authenticator. Replace webroot-path with the
# path to the public_html / webroot folder being served by your web server.
# authenticator = webroot
# webroot-path = /usr/share/nginx/html
Ich habe hier nur meine E-Mail Adresse eingetragen, alles Andere steuere ich über Kommandozeilenparameter des Let’s Encrypt Wrapperscripts.
Danach wechseln wir in unser Home Verzeichnis und legen dort ein Verzeichnis „bin“ an.
Shell
1
2
$cd
$mkdirbin
In diesem Verzeichnis legen wir ein Script letsencrypt-updatecerts.sh mit dem folgenden Inhalt an.
2016-02-2416:41:03,426:INFO:letsencrypt.cli:Cert notyet due forrenewal
Das sieht zunächst einmal gut aus. Unser Zertifikat ist noch nicht zur Erneuerung fällig. Abschließend legen wir einen crontab Eintrag an, der das Script einmal Montags um 1:33 Uhr ausführt.
Am einfachsten rufen wir dazu „crontab -e“ auf und ergänzen am Ende der Datei die folgende Zeile:
1
331**1/root/bin/letsencrypt-updatecerts.sh
Dann speichern wir ab und überprüfen mit „crontab -l“, ob der Eintrag korrekt ist. Die Meldungen, die das Script bei der Ausführung ausgibt, werden an den Benutzer, in diesem Falle „root“, gemailt. Dadurch haben wir die Kontrolle über auftretende Fehler.
Wie sich nach dem ersten Cronjeb Lauf des Let’s Encrypt Clinets zeigt funktioniert der Aufruf aus dem Cronjob, so wie wir ihn angegeben haben, leider nicht. Es tritt ein Fehler auf, der Client findet das apache plugin nicht. Warum das Problem nur beim Cronjob auftaucht ist mir ein Rätsel.
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
$cat/var/log/letsencrypt/letsencrypt.log.7
2016-03-1401:33:03,781:DEBUG:letsencrypt.cli:Root logging level set at20
2016-03-1401:33:03,787:INFO:letsencrypt.cli:Could notchoose appropriate plugin:The apache plugin isnotworking;there may be problems with your existing configuration.
Damit funktioniert das Erneuern der Zertifikate auch aus dem Cronjob.
Es gibt momentan noch einen Schönheitsfehler. Da der Mailserver noch nicht konfiguriert ist, landen die Mails des cron jobs im lokalen Postfach für nobody. Das kann für den produktiven Betrieb so nicht bleiben. Da meine Domain, zu der unser Server gehört, auf einem Hostingvertrag ebenfalls bei 1&1 läuft und die E-Mails dort gehostet werden, ist die Lösung des Problems denkbar einfach. Wir müssen nur Postfix richtig für ausgehende Mail konfigurieren. Postfix ist als Mailserver vorkonfiguriert und läuft bereits. Zunächst setzen wir in der Datei /etc/postfix/main.cf den Eintrag für myhostname auf den tatsächlichen Hostnamen, dort steht momentan noch localhost. Ausserdem müssen wir den Hostnamen bei der Variable mydestination anfügen.
Anschließend restarten wir Postfix mit „service postfix restart“.
Jetzt müssen wir nur noch dafür sorgen, dass die Systemmails, die an den Benutzer „root“ geschickt werden, bei uns ankommen. Dazu ergänzen wir in der Datei /etc/aliases eine Weiterleitungszeile folgender Form.
1
root:webmaster@whereever.de
Bitte eine sinnvolle E-Mail-Adresse eintragen, damit die Mails bei Euch ankommen. Diese Änderung muss noch in die aliases Database übernommen werden. Dazu müssen wir das Kommando „newaliases“ ausführen, fertig. Jetzt können wir testen, ob ausgehende Mail funktioniert.
Shell
1
2
3
mail-sTestroot@localhost
Das ist ein Test.
Cc:
Die Testmail sollte dann an der oben angegebenen E-Mail-Adresse ankommen.
Somit haben wir nun die Konfiguration eines Webservers mit Let’s Encrypt Zertifikaten abgeschlossen. Zum Abschluss machen wir noch einen Backup und nehmen dabei die Postfix Konfiguration ins Backup mit auf.