Blog/Website von HTTP auf HTTPS (SSL) umstellen

In diesem Beitrag wird es um zwei Themen gehen. Zunächst beleuchte ich kurz, warum heutzutage ein Blog/ eine Website ausschließlich via HTTPS – also SSL verschlüsselt – aufrufbar sein sollte (muss). Im zweiten Teil gibt es dann ein kurzes HowTo (Tutorial) anhand eines WordPress Beispiels, welche Schritte notwendig sind, um eine bestehende Seite umzustellen (migrieren).

Warum noch ein Tutorial hierzu? HTTPS wurde 1994 (Stand heute vor 26 Jahren) veröffentlicht. Obwohl inzwischen seit 2000 Standard und wird es trotz allem nicht flächendeckend genutzt, um Daten im Internet zu schützen. In den nachfolgenden  Anleitungen werden ein wenig die Hintergründe erläutert: was passiert in welchem Schritt der Umstelllung auf SSL und welches Risiko ist hiermit verbunden. Denn nach meiner Erfahrung sind technisch nicht ganz so versierte Blog/Site-Betreiber oftmals verunsichert, was letztlich dazu führt, dass die Umstellung von http auf HTTPS nicht erfolgt.

Warum ist eine SSL Verschlüsselung (HTTPS) unbedingt notwendig?

  • Gesetzeskonformität (DSGVO): Die meisten Sites/Blogs besitzen eine Funktion zum Kommentieren bei der die E-Mail-Adresse des Kommentierenden abgefragt wird, oder eine Funktion, um sich für einen Newsletter z.B. für neue Beiträge zu registrieren. Gemäß Artikel 5 DSGVO in Verbindung mit 32 DSGVO müssen personenbezogene Daten mit angemessener Sicherheit verarbeitet werden. Dies ist keine juristische Empfehlung meinerseits. Aber da eine SSL Verschlüsselung einfach umsetzbar ist, sollte diese nach meiner Auffassung in jedem Fall durchgeführt werden,.
  • Schutz der eigenen Zugangsdaten (z.B. wp-admin): Ohne HTTPS werden natürlich auch die Anmeldedaten unverschlüsselt übertragen sobald Ihr Euch in Euer Content Management System (, CMS z.B. WordPress) einloggt! Im heimischen WLAN ist das vermutlich noch zu verkraften, aber im öffentlichen WLAN (Kaffee, Hotel, Flughafen, …) ein absolutes Sicherheitsrisiko. Denn je nach der dort eingesetzten Netzwerkinfrastruktur kann jeder, der sich im selben WLAN befindet, unverschlüsselte Daten mitlesen und so auf recht einfache Art und Weise Euren Benutzernamen und das Passwort phishen (herauslesen). Kling kompliziert, ist es aber wirklich nicht. BSI Wlan
  • Search Engine Optimization (SEO): Eine Datenübertragung via http ist nicht mehr Stand der Technik, das sieht auch Google so. Daher stuft der Browser Google Chrome alle Sites ohne HTTPS seit einiger Zeit als unsicher ein. Im Ranking der Suchergebnisse werden http Seiten ebenfalls schlechter bewertet. Google Ranking
    Beispiel Chrome:


    Beispiel Firefox:

Es gibt sicherlich noch viele weitere Argumente warum HTTPS als Protokoll verwendet werden sollte, aber ich denke das sollte Ermutigung zunächst genug sein.

Welche Schritte sind nötig für eine Umstellung auf HTTPS (SSL)?

Vor jedem Schritt sollte zur Vorsicht ein Backup der Site/des Blogs gemacht werden. Backups können meist im Admin-Bereich des Hosters gesteuert / angestoßen werden.

Eigentlich sind es nur zwei Schritte die für eine Umstellung nötig sind:

  1. SSL Zertifikat beziehen und am Webserver installieren
  2. Site auf Mixed Content prüfen (gibt es eingebundene Inhalte z.B. Bilder die über http bezogen werden)

SSL Zertifikat

Ohne zu tief in die Thematik SSL Zertifikat einzutauchen, gibt es jedoch einige Fakten derer man sich bewusst sein sollte. Je nach „Stärke“ des Zertifikats werden im Zertifikat mehr oder weniger Informationen angeboten und sind somit unterschiedlich vertrauenswürdig (z.B. Onlinebanking vs. Blog).

Wichtig ist aber, dass sobald SSL aktiv ist (hierzu ist das Zertifikat nötig), eine verschlüsselte Verbindung aufgebaut wird. Es gibt kostenlose Zertifikate von (https://letsencrypt.org/), die meisten anderen Anbieter von Zertifikaten sind kostenpflichtig. Für ein letsencrypt Zertifikat benötigt man meist einen Shell Zugang (SSH / Putty). Admin Oberflächen wie Plesk bieten auch eine grafische Oberfläche für die Einrichtung von letsencrypt Zertifikaten, das wird hier aber nicht näher beschrieben.

Wer jetzt ??? über dem Kopf hat, sei folgendes gesagt:

Die meisten Hoster bieten über ihre Admin-Site (meist die Seite auf der auch neue Domains bestellt werden können) einen einfachen Mechanismus an, über den ein Zertifikat bestellt und installiert werden kann. Hier ist z.B. ein Tutorial für Strato:

Tutorial für Strato

und für 1und1 hier:

Tutorial für 1und1

Den Weg über den Hoster zu gehen, ist auch aus einem anderen Gesichtspunkt sinnvoll. Zertifikate sind nur für eine begrenzte Dauer gültig und müssen dann erneuert werden. Das übernimmt der Hoster normalerweise und verlängert die Zertifikate automatisch bevor diese ablaufen (aber ein neues Zertifikat kostet natürlich dann auch wieder Geld). Inzwischen sind auch häufig schon die Kosten für ein Zertifikat im Grundpreis für das Hosting enthalten, sodass nicht immer wieder das eigene Budget belastet wird.

Die Bereitstellung und Installation des Zertifikats am Webserver dauert meist ein wenig (vermutlich aber nicht länger als einen Tag) und wird in der Regel komplett durch den Hoster durchgeführt. Ihr müsst hier also kein technisches Wissen mitbringen. Diesen Schritt würde ich als unkritisch einstufen (man kann hier also nicht viel kaputt machen). Danach ist die Domain (Blog/Site) sowohl über http://domain.de als auch über https://domain.de erreichbar.

Viele empfehlen das Einrichten einer sogenannten 301-Weiterleitung. Was ist das? Wird die Site mit http aufgerufen, erfolgt eine automatische Umleitung auf https, sodass die Site/ der Blog nur noch über https erreichbar ist. Spricht: Es wird http://domain.de aufgerufen und der Benutzer wird automatisch auf https://domain.de geleitet. Dieser Schritt ist richtig und notwendig, ich warte jedoch ca. 1-2 Wochen bis ich die Umleitung aktiviere, damit ich erstmal in Ruhe die Seite prüfen kann. Aktiviert wird diese 301-Weiterleitung meist auch im Admin-Bereich des Hosters.

Mixed Content

Wenn die Domain via HTTPS erreichbar ist, muss sie auf sogenannten Mixed Content geprüft werden. Von Mixed Content spricht man, wenn in eine Site/Blog Elemente via http eingebunden sind und somit nicht verschlüsselt übertragen werden. Firefox zeigt dann zum Beispiel folgende Warnung in der URL:

Besteht ein Blog/eine Site schon länger, ist vermutlich entsprechend viel Content über die Jahre eingestellt worden. Alle Beiträge händisch  zu korrigieren wäre dann sehr zeitaufwendig. Zum Glück ist das nicht notwendig. Es geht einfacher!

Für WordPress gibt es zwei Wege den Mixed Content zu migrieren. Für den ersten Weg benötigt man Zugriff auf die Datenbank (MySQL) der WordPress Installation. Dann können die Tabellen mit eigenen SQL-Scripts migriert werden. Diesen Weg bevorzuge ich, da hier auch vor der Migration ein Dump (direktes Backup) der Datenbank „gezogen“ werden kann. Ein gutes Tutorial für die Migration via SQL findet sich hier:

Tutorial für die Migration

Jetzt sind wir vermutlich wieder bei den ???, die über Deinem Kopf kreisen. Gute Nachricht:ie Umstellung kann auch mittels eines WordPress Plugins durchgeführt werden.

Plugin: Velvet Blues Update URLs

Diesen Schritt sehe ich etwas kritischer (hier kann man etwas kaputt machen, also vorher unbedingt ein Backup erstellen).

Was man hier unbedingt wissen sollte:

Im Step 2 (siehe Bild) gibt es 6 Auswahlmöglichkeiten (Checkboxen). Man kann das Plugin mehrfach ausführen und sich so langsam herantesten, wobei sich das Plugin nicht merkt für welche Auswahl es ausgeführt wurde (die Checkboxen sind bei einem erneuten Aufruf des Plugin alle wieder leer). Das muss man sich selber merken/aufschreiben. Die im Screenshot zwei ausgewählten URL-Typen sollten auf jeden Fall umgestellt werden (ich migriere aber immer alle 5 URL Typen, bis auf den letzten). Bei den Übrigen könnte man sich herantasten.

Die letzte Checkbox (Update ALL GUIDs) sollte auf keinen Fall ausgewählt werden! Das ist eine Einstellung für Entwickler und wird auch von der WordPress Dokumentation nicht empfohlen.

Was kommt in die Felder Old URL und New URL:

Old URL ist die aktuelle http Adresse http://domain.de bzw. http://www.domain.de

New URL ist die https Adresse https://domain.de bzw. https://www.domain.de

Welche URL Ihr habt, könnt ihr in den WordPress Einstellungen einsehen:

Hinweis: Es ist zwar sicherlich nicht gut, beide Kombination (mit und ohne www) auszuprobieren aber es sollte auch nichts passieren wenn man es mal macht. Von einer „Mischung-Migration“ z.B. old URL http://domain.de zu new ULR https://www.domain.de rate ich jedoch ab.

Nach jedem Schritt kann über den Browser geprüft werden, ob die Mixed Content Warnung noch erscheint, da die Änderungen sofort wirksam sind:

Alle URLs „sauber“ migriert:

In meiner Version des Velvet Blues Update URLs Plugin deaktiviert sich das Plugin nach jedem Lauf. Vermutlich eine Sicherheitseinstellung, aber dennoch etwas verwirrend. Um das Plugin anschließend wieder zu aktivieren rufe über die WordPress Sitebar à „Plugins“ auf. Hier kannst Du das Plugin wieder aktivieren, indem Du auf den Link „aktivieren“ klickst. Anschließend kannst Du das Plugin über die WordPress Sitebar Werkzeuge wieder aufrufen.

In einem letzten Schritt noch die WordPress Einstellungen prüfen und auf https anpassen (falls hier noch nicht https steht):

Herzlichen Glückwunsch. Die Umstellung von http auf HTTPS ist fertig.

Aber nicht vergessen: Wenn alles getestet ist und funktioniert, noch die 301-Weiterleitung aktivieren (oben beschrieben).

Habt Ihr Fragen? Dann kommentiert einfach. Es ist „quasi“ unmöglich, für alle Hoster der Welt eine Klickanleitung zu schreiben. Beschäftigt euch mit dem Thema! SEO ist wichtig, aber die erwähnte Gesetzeskonformität und der Schutz der Login-Daten wiegen sicher schwerer.

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.