Warum SSL/TLS-Verschlüsselung?
Warum sollte man aufwendig die Verschlüsselung aktivieren, wenn es auch ohne geht? Aus meiner Sicht gibt es viele Gründe seine Inhalte verschlüsselt anzubieten:
- Schutz der Login-Daten bei der Übertragung.
- Schutz der Privatsphäre der Blog Besucher; insbesondere wenn aus öffentlichen Netzwerken auf die Seite zugegriffen wird.
- Im Zuge des um sich greifenden Überwachungswahn, gilt es so viele Daten wie möglich zu verschlüsseln, damit die massenhafte Überwachung möglichst teuer und damit hoffentlich eingeschränkt wird.
- Zu guter letzt: Das Google-Ranking wird angeblich besser, wenn die Seite über SSL/TLS angeboten wird.
Nachdem “echtes” SSL/TLS erstmal grundsätzlich aktiviert ist, muss nur noch das WordPress-Blog umgestellt werden, damit es auch korrekt über SSL/TLS erreichbar ist:
- Sofern bisher ein SSL-Proxy für den Zugriff auf das Backend verwendet wurde, sollten die dazu vorgenommen Änderungen zunächst zurück genommen werden. Dies betrifft z.B. auch folgende Beiträge hier im Blog “WordPress SSL Admin” und “Basic Auth per SSL-Proxy erzwingen” und insbesondere die in den Beiträgen genannten Änderungen an den Dateien .htaccess und wp-config.php. Außerdem sollte auch das Plugin SSL-Proxy URL Fixer deaktiviert werden.
- In WordPress unter Einstellungen -> Allgemein die Werte für die Felder “Wordpress-Adresse (URL)” und “Seiten-Adresse URL” die URLs anpassen und die neuen HTTPS-Adressen eintragen (z.B. https://klein-gedruckt.de). Danach sollte das Blog eigentlich schon wieder erreichbar sein. Falls nicht, so hilft ggf. folgender Eintrag in der wp-config.php:
define( 'WP_CONTENT_URL', 'https://Ihre Webseite' )
-
Achtung: Bevor Änderungen an der Datenbank vorgenommen werden sollte für den Notfall unbedingt ein Backup mit dem DB-Client der Wahl (z.B. per phpMyAdmin) durchgeführt werden.
Anschließend müssen noch einige Einträge in der Datenbank angepasst werden. Dabei sollte mit Bedacht vorgegangen werden. Mit einem falschen Kommando ist die Datenbank schnell zerstört und die Inhalte für immer verloren.
Daher sollten die folgenden Schritte nur durchgeführt werden, wenn ein aktuelles Datenbank-Backup vorliegt:
UPDATE wp_options SET option_value = replace(option_value, 'http://klein-gedruckt.de', 'https://klein-gedruckt.de') WHERE option_name = 'home' OR option_name = 'siteurl'; UPDATE wp_posts SET guid = replace(guid, 'http://klein-gedruckt.de','https://klein-gedruckt.de'); UPDATE wp_posts SET post_content = replace(post_content, 'http://klein-gedruckt.de', 'https://klein-gedruckt.de'); UPDATE wp_postmeta SET meta_value = replace(meta_value,'http://klein-gedruckt.de','https://klein-gedruckt.de');
Da ich bisher auch den SSL-Proxy von All-Inkl für die Administration genutzt habe, muss bei der Ersetzung ggf. auch noch die SSL-Proxy-URL (bei mir https://ssl-account.com/klein-gedruckt.de) des Blogs berücksichtigt werden:
UPDATE wp_options SET option_value = replace(option_value, 'https://ssl-account.com/klein-gedruckt.de', 'https://klein-gedruckt.de') WHERE option_name = 'home' OR option_name = 'siteurl'; UPDATE wp_posts SET guid = replace(guid, 'https://ssl-account.com/klein-gedruckt.de','https://klein-gedruckt.de'); UPDATE wp_posts SET post_content = replace(post_content, 'https://ssl-account.com/klein-gedruckt.de', 'https://klein-gedruckt.de'); UPDATE wp_postmeta SET meta_value = replace(meta_value,'https://ssl-account.com/klein-gedruckt.de','https://klein-gedruckt.de');
Außerdem empfiehlt es sich ggf. auch noch weitere Tabellen zu berücksichtigen, wie z.B. die Tabellen von spezielle Plugins. Grundsätzlich können die oben genannten Update-Statements dabei als Vorlage genutzt werden.
Nur zur Sicherheit weise ich nochmal darauf hin, dass die URLs und ggf. auch die Tabellen-Prefixe in den SQL-Statements angepasst werden müssen.
- Funktioniert danach noch alles, so kann eine permanente Weiterleitung auf SSL/TLS eingerichtet werden:
RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}/$1 [R=301,L]
- Zu guter letzt sollte noch überprüft werden ob auch wirklich alle Bilder und Elemente nun per SSL/TLS-Eingebunden werden. Sollten noch irgendwo Inhalte per http eingebunden werden, so wird dies als “unsichere Inhalte” in der Browser-Leiste angezeigt. Dies kommt beispielsweise vor, wenn ein Element in der Datenbank nicht korrekt angepasst wurde, oder Elemente (z.B. Logos oder Javascript-Bibliotheken) direkt im Template mit einer absoluten URL eingebunden wurden. Erst wenn wirklich alle Elemente der Web-Seite per HTTPS geladen werden verschwindet auch diese Warnmeldung vom Browser.
Ich habe bei der Sicherheitsfirma Janotta und Partner diesen Hinweis gefunden.
Demnach soll ab dem 01. Januar 2017 der Google Chrome Browser alle Onlineshops und Webseiten mit einer Warnung anzeigen, wenn diese kein HTTPS besitzen.
https://janotta-partner.de/ssl-installieren.html
Falls das stimmt brauche ich eventuell Hilfe bei der Umstellung. Macht Ihr das auch und was kostet mich das?
Vielen Dank für Ihren tollen Artikel.
Bei Punkt 2 wollte ich nochmal nachfragen, was den wohl besser ist?
Mit www. oder ohne? Und muss ich dann die Datenbank auch dementsprechend mit www oder ohne machen? Ich habe nämlich mal geschaut und irgendwie finde ich in der Datenbank ohne http://www., aber in den Einstellungen steht meine Domain mit www.
Deswegen bin ich auch gerade etwas irritiert. Allerdings weiß ich auch nicht, ob ich das irgendwann mal geändert habe und es deswegen so unterschiedlich steht.
Die Frage ist halt, ob es schlimm ist oder negativ.
Lieben Gruss, Pascal