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.

Diese Datei passen wir nun noch an unsere Anforderungen an. Hierbei sind verschiedene Anfoderungen zu berücksichtigen. Auf der einen Seite wollen wir eine möglichst sichere Konfiguration, auf der anderen Seite schränken wir damit den Zugriff auf moderne Browser und Clientprogramme ein. Hier ist ein vernünftiger Kompromiss zu suchen. Zunächst erstellen wir aber eine möglichst sichere Konfiguration. Für Hintergrundinfomationen zu den hier verwendeten Einstellungen findet man in der technischen Richtlinie TR-02102-2 zur Verwendung von Transport Layer Security (TLS) des BSI und der RFC 7525: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) der Internet Engineering Task Force IETF.

Als Protokoll lassen wir nur TLSv1.2 zu, die entsprechende Zeile sieht dann aus wie folgt:

oder alternativ so:

Als Ciphersuites werden nur Varianten mit 256 bit Verschlüsselungslänge verwendet. Damit sieht die Zeile für die Ciphersuite wie folgt aus:

Als nächstes entfernen wir das Kommentarzeichen in der letzten Zeile, damit Cookies ebenfalls immer als sicher gekennzeichnet werden.

Zuletzt wollen wir noch „HTTP Strict Transport Security“ HSTS konfigurieren. Dazu ergänzen wir die Konfigurationsdatei am Ende mit den folgenden beiden Zeilen:

Damit sieht unsere Datei /etc/letsencrypt/options-ssl-apache.conf jetzt wie folgt aus:

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.

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.

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.

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.

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.

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.

Unsere Konfiguration sieht nun wie folgt aus:

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.

Nun wiederholen wir die beiden Tests, zunächst den Free SSL Server Test.

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.

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.

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.

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.

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.

In diesem Verzeichnis legen wir ein Script letsencrypt-updatecerts.sh mit dem folgenden Inhalt an.

Anschließend setzen wir noch die Permissions.

Jetzt führen wir einen Testlauf unseres Scripts durch.

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:

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.

Es gibt aber eine einfache Alternative, die auch als Cronjob funktioniert. Wir ändern unser Script zum Erneuern der Zertifikate wie folgt ab.

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.

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.

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.

Im 5. Teil der Artikelserie werden wir uns ein wenig mit WordPress beschäftigen, denn ich möchte diesen Blog auf unseren Cloud Server umziehen.