WordPress auf HTTPS umstellen mit kostenlosen Let’s Encrypt Zertifikaten

Wie dem ein oder anderen schon aufgefallen ist, läuft code-bude.net seit einigen Tagen strikt per HTTPS-Protokoll. Alle Anfragen per HTTP-Protokoll werden auf HTTPS weitergeleitet. Wie genau die Umstellung von HTTP auf HTTPS für code-bude.net verlief, möchte ich im folgenden Artikel erklären.

Der Artikel zeigt euch, wie ihr euren WordPress Blog auf HTTPS umstellen könnt. Als Grundlage für den Artikel dient mein Setup, welches aus einem vServer mit Ubuntu Server und Apache als Webserver besteht. (Mehr zu meinem Setup hier.)

Die Anleitung gliedert sich in folgende Schritte:

1. Warum HTTPS für einen Blog?
2. Certbot installieren und Zertifikate generieren
3. Zertifikate automatisch erneuern mit Certbot
4. Zertifikate in Apache vHosts konfigurieren
5. WordPress auf HTTPS umstellen
6. Tools und Tipps zur Überprüfung der Umstellung

Doch zuerst soll die Frage – “Warum überhaupt HTTPS?” – geklärt werden…

Warum HTTPS für einen WordPress-Blog?

Um besser nachvollziehen zu können, warum ich auf HTTPS umgestellt habe und warum ich diesen Schritt für sinnvoll erachte, habe ich einmal Pro- und Kontra-Argumente aufgelistet.

Pro HTTPS:

• Verschlüsselte Datenübertragung zwischen Server und Client
• Trust-Sign und positives Rankingsignal für Google

Kontra HTTPS:

• SSL-Zertifikate kosten eine Jahresgebühr
• Einrichtung und Erneuerung der Zertifikate bedeutet Aufwand
• HTTPS hat im Vergleich zu HTTP einen etwas größeren Protokoll-Overhead und ist dementsprechend (minimal!) langsamer

Falls sich nun jemand fragt, warum die ersten beiden Kontra-Punkte durchgestrichen sind, dem sei gesagt, dass sie durch die Verwendung von Let’s Encrypt obsolet sind. SSL-Zertifikate von Let’s Encrypt sind kostenlos und einmal eingerichtet erneuern sie sich von selbst.

Somit bleibt nur noch das Argument der minimal größeren Datenmenge und Rechenzeit zur Verschlüsselung. Verglichen mit dem Sicherheitsgewinn und dem positiven Rankingsignal ist dies jedoch zu vernachlässigen.

Wo wir das Motiv nun also geklärt haben, können wir uns mit der Umsetzung beschäftigen.

Let’s Encrypt und der Certbot

Kommen wir zu Schritt zwei der Anleitung. Wesentlicher Bestandteil der Konfiguration ist das Programm Certbot. Dieses Tool nimmt uns die Arbeit der Zertifikatsgenerierung sowie die Erneuerung der Certifikate ab.

Cerbot könnt ihr über die Certbot-Webseite beziehen. Auf der Startseite ist der verwendete Webserver sowie das verwendete Betriebssystem anzugeben. Nach Angabe der Daten erhaltet ihr einen Kommandozeilenbefehl, mit dem sich Certbot installieren lässt.

Für mein Setup (Apache2 und Ubuntu 14.04 LTS) lauten die Befehle, welche ich per Putty abgesetzt habe wie folgt:

cd /usr/local/sbin/
wget https://dl.eff.org./certbot-auto
chmod a+x certbot-auto

Im ersten Schritt wechseln wir in das Verzeichnis /usr/local/sbin (Verzeichnis für Scripte und Programme, die mit root-Rechten laufen sollen). Danach laden wir Certbot mittel wget herunter und versehen es im Anschluss mittels chmod mit den nötigen Rechten, um es ausführen zu können.

Nun können wir das (oder bei mehreren Blogs die) Zertifikate generieren. Hier nutzen wir folgenden Certbot-Aufruf.

/usr/local/sbin/certbot-auto certonly -d code-bude.net

Der eben ausgeführte Befehl sagt Certbot, dass er nur die Zertifikate (certonly) für die Domain code-bude.net (-d Parameter) erzeugen soll.

Wenn alles geklappt hat, solle nun im Verzeichnis /etc/letsencrypt/live ein Unterordner mit dem Namen eurer Domain sein, welcher die SSL-Zertifiakte sowie die Keychain-Datei enthält.

Theoretisch kann Certbot die Zertifikate auch gleich noch in die Apache-Konfiguration eintragen. In meinem Fall, bei Verwendung mehrerer recht komplexer vHost-Dateien klappte dies jedoch nicht. Und da ich mir ungerne von Tools an Konfigurationsdateien “fummeln” lassen, bei denen ich nicht genau weiß, was sie alles ein- oder verstellen, habe ich mich auf das Zertifikat erstellen begrenzt. Die Konfiguration in Apache nehmen wir in Schritt 4 von Hand vor.

Let’s-Encrypt-Zertifikate automatisch erneuern

Zwar sind die Let’s Encrypt Zertifikate kostenlos und mittlerweile auch von nahezu allen Browsern anerkannt, jedoch haben sie die kleine “Schwäche”, dass sie jeweils nur 3 Monate gültig sind. Im Gegenteil zu den üblichen käuflich erweblichen Zertifikaten müsste man also 4 mal im Jahr die Zertifikate austauschen/erneuern. Verpasst man dies, wird der WordPress-Blog/die Webseite nicht mehr richtig ausgeliefert.

Um diesem Fiasko aus dem Weg zu gehen, bietet Certbot eine Funktion an, um die Zertifikate automatisch zu erneuern. Zuerst führen wir folgende Funktion aus:

/usr/local/sbin/certbot-auto renew --dry-run

Der Aufruf cerbot-auto renew weißt Certbot an, zu überprüfen, ob die Zertifikate erneuert werden müssen und diese ggf. zu erneuern. Der Parameter –dry-run sorgt dafür, dass die Zertifikate nicht tatsächlich erneuert werden, sonder startet einen Probelauf.

Wenn das Ergebnis des Aufrufs grünes Licht gibt (alle zu erneuernden Domains gefunden und keine Fehlermeldung ausgegeben), dann können wir den “echten” Aufruf regelmäßig einplanen. Hierzu legen wir einen Eintrag in der Cronjob-Tabelle (crontab) an.

Idealerweise führt man den renew-Job zweimal täglich und nicht zur vollen Stunde aus. (Die Minute ist dabei egal. Es geht nur darum, die Last auf den Let’s Encrypt Server gering zu halten.)

Den entsprechenden Eintrag legen wir wie folgt in der Crontab an:

crontab -e
13 */12 * * * /usr/local/sbin/certbot-auto renew >/dev/null 2>&1
[Strg+X]

Mittels crontab -e öffnen wir die Crontab im Editiermodus. Dann fügen wir den Cerbot-Aufruf in der letzten Zeile ein und speichern und schließen mittels Strg+X.

Mein Aufruf läuft zweimal am Tag in der 13ten Minute. Wer ein anderes Intervall möchte, aber (wie ich) auch immer den Syntax der Intervalle vergisst, kann sich den Cronjob hier zusammenklicken.

SSL-Zertifikate in Apache vHost eintragen

Nun haben wir die Zertifikate erzeugt und sichergestellt, dass diese auch immer aktuell gehalten werden. Nun kommen wir zu Schritt 4 – der Konfiguration der Zertifikate in Apache.

Solltet ihr euren Apache-Server noch nie per HTTPS betrieben haben, sind folgende Schritte nötig. Anderenfalls könnt ihr bis zu der vHost-Konfiguration weiter scrollen.

Zuerst müsst ihr Apache sagen, dass er auf Port 443 hören soll. Dies geht per Eintrag in der Datei /etc/apache2/ports.conf. Öffnet die Datei mit einem Editor und fügt unter dem Listen 80 folgenden Block ein.

<IfModule ssl_module>
    Listen 443
</IfModule>

Schließt die Datei und aktiviert das SSL-Modul. Abschließend muss die Konfiguration des Apache noch einmal neu geladen werden.

a2enmod ssl
service apache2 force-reload

Nun ist der Apache bereit für HTTPS-Verbindungen. Im nächsten Schritt müssen wir die SSL-Konfiguration für die Domain vornehmen. Hierzu öffnen wir das entsprechende vHost-File mit einem Editor (z.B. nano). Die vHost-Dateien sollten sich im Verzeichnis /etc/apache2/sites-available/ befinden.

cd /etc/apache2/sites-available
nano code-bude.net

Innerhalb des vHost-Files kopieren wir den HTTP-Abschnitt und ersetzen Port 80 durch 443 und fügen den neuen vHost unter dem bestehenden HTTP-vHost ein.

<VirtualHost *:443>
        ServerAdmin webmaster@code-bude.net
        ServerName code-bude.net
        ServerAlias www.code-bude.net code-bude.net *.code-bude.net
        DocumentRoot /var/www/code-bude.net/public_html

        <Directory /var/www/code-bude.net/public_html>
                Options FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>
	
	//Weitere Einstellungen...

</VirtualHost>

Zwischen DocumentRoot und <Directory… tragen wir nun die SSL-/HTTPS-Konfiguration ein.

<VirtualHost *:443>
        ServerAdmin webmaster@code-bude.net
        ServerName code-bude.net
        ServerAlias www.code-bude.net code-bude.net *.code-bude.net
        DocumentRoot /var/www/code-bude.net/public_html
        
        SSLEngine on
        SSLProtocol all -SSLv2 -SSLv3
        SSLCompression Off
        SSLHonorCipherOrder on
        SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK;
        SSLCertificateFile    /etc/letsencrypt/live/code-bude.net/cert.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/code-bude.net/privkey.pem
        SSLCertificateChainFile /etc/letsencrypt/live/code-bude.net/chain.pem

        <Directory /var/www/code-bude.net/public_html>
                Options FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>
	
	//Weitere Einstellungen...

</VirtualHost>

Mit SSLEngine on schalten wir den SSL-Modus an. Mit SSLProtocol legen wir die verwendeten Protokolle fest. Durch SSLCompression Off deaktivieren wir die SSL Komprimierung, da in älteren Browsern sonst Crime-/Beast-Angriffe erfolgen könnten. Mit SSLHonorCipherOrder on geben wir an, dass die Cipher-Reihenfolge vom Server und nicht vom Client bestimmt werden soll. Mit SSLCipherSuite geben wir die zu verwendenden Cipher-Suiten in ihrer Reihenfolge an.

Abschließend geben wir mit SSLCertificateFile, SSLCertificateKeyFile und SSLCertificateChainFile die Verweise auf unsere Let’s Encrypt Dateien an.

Abschließend schließen wir das vHost-File. Und laden die Konfiguration neu.

sudo service apache2 reload

Nun haben wir also die Zertifikate generiert, deren Erneuerung eingeplant und Apache für die Verwendung der Zertifikate eingerichtet. Im nächsten Schritt bringen wir WordPress bei, nur HTTPS zu verwenden.

WordPress aus HTTPS umstellen

Nachdem die Arbeiten an der Basis nun abgeschlossen sind, müssen wir WordPress noch beibringen, dass es HTTPS verwenden soll. Hierzu nutzen wir das WordPress HTTPS (SSL) Plugin.

Loggt euch im WordPress-Backend ein und installiert das Plugin. Nach der Installation aktiviert ihr das Plugin und öffnet euren Blog. Sollte es zu Darstellungsfehlern kommen, weil einzelne Dateien immer noch per HTTP ausgeliefert werden, so könnt ihr eure .htaccess-Datei noch anpassen.

Öffnet hierzu die .htaccess-Datei im Hauptverzeichnis eurer WordPress-Installation und fügt hinter der Zeile “RewriteBase /” folgenden Eintrag ein:

RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Diese beiden Zeilen leiten alle HTTP-Anfragen per 301-Redirect auf die HTTPS-Variante weiter.

An dieser Stelle ist die eigentliche HTTPS/SSL-Umstellung abgeschlossen. Im letzten Abschnitt des Artikel setzen wir uns mit der Überprüfung der korrekten Installation auseinander.

Überprüfen, ob SSL korrekt funktioniert

Nachdem die Konfiguration nun abgeschlossen ist, ist es ratsam ein paar Prüfungen durchzuführen. Hierzu habe ich euch folgende Checkliste erstellt:

• Startseite, statische Seiten und Blogposts mit verschiedenen Browsern (auch IE) aufrufen und schauen, ob die Darstellung stimmt
• Versuchen einen Kommentar zu schreiben und schauen, ob es gelingt
• Die Webseite mittels dem SSL-Checker prüfen. (Mit obiger Konfiguration sollte mindestens eine A-Bewertung drin sein.)
• Falls ihr euren Blog in den Google Webmaster Tools habt, denkt dran, einen neue Property für die HTTPS-Variante anzulegen

Für Fragen, Feedback und Anregungen stehe ich wie immer jederzeit zur Verfügung.