Nachdem wir nun nach und nach Webseiten auf HTTPS umstellen, möchte ich mein Wissen und meine Erfahrungen allen zur Verfügung stellen, die ihre wordpress-Webseite mit genügend technischem Hintergrundwissen eigenständig mit HTTPS versehen wollen. Denn es gibt durchaus mehr Fallen zu umgehen und Vorgehensweisen zu beachten, als es zunächst den Anschein hat.

In diesem Beitrag erkläre ich mein Vorgehen und meine Checkliste, damit der Umzug auf HTTPS reibungslos funktionieren kann. Er erhebt keinen Anspruch auf alleinige Wahrheit, mag noch optimiert werden, muss nicht für alle Installationen Gültigkeit haben und muss möglicherweise je nach Webhoster angepasst werden bzw. es könnten noch weitere Fallen auftauchen, die mir bisher noch nicht bekannt sind. Die Checkliste ist einigermaßen ausführlich und dient mir bei unseren Projekten als sicherer Handlungsablauf.

Rechtlicher Hinweis: Die Umstellung erfolgt auf eigenes Risiko und natürlich wissen wir, dass der Handelnde vollumfänglich haftet, nicht der Ideen- oder Auftraggeber. 🙂

Eigentlich ist es ja ganz einfach, möchte man meinen: bei WordPress in den Einstellungen - Allgemein den beiden Einträge der URL der Webseite ein ’s‘ hinzufügen und fertig:

Leider weicht die harte Webmaster Realität davon ab – dieses Vorgehen ist nicht empfohlen, ebenso wenig empfehle ich irgendwelche HTTPS-plugins, von denen es einige gibt. Ich behalte bei solcherlei Eingriffen lieber selbst die Kontrolle. Warum, das ergibt sich aus meinen nachfolgenden Ausführungen.

#1 – Zertifikat besorgen

Dies kann man bereits einige Zeit vorher beantragen, da die Umstellung / Aktualisierung der Webserver (DNS-Einträge) bis zu 48h dauern kann. Das übliche DV-Zertifikat (Domain Validierung) ist meist sofort nach Beantragung einsatzbereit. Da ich bislang nur mit DV-Beantragungen zu tun hatte, werden auch nur diese nachfolgend betrachtet. Die Validierung für eine Organisation für ein OV-Zertifikat ist nicht nur teurer, sondern dauert auch länger aufgrund des Prüfverfahrens der Adresse der Organisation.

Umstellung durchgeführt, aber manche DNS-Server haben die Information noch nicht innerhalb der 48h erhalten. Folge: der Aufruf der Webseite mit HTTPS läuft zwangsläufig in einen hässlichen Fehler, so als ob die Webseite gar nicht existieren würde.
Autsch-Faktor: 10

Mein Vorgehen ist, das DV-Zertifikat online zu erlangen und gleich auf dem Webserver zu installieren. Erst nach Ablauf der 2 Tage führe ich dann die eigentliche Umstellung durch.

Ein Zertifikat oder treffender formuliert: die SSL-Verschlüsselung, besteht immer aus privatem und öffentlichen Schlüssel (Key) sowie dem eigentlichen Zertifkat (CRT). Öffentlicher Key und Zertifikat werden dem Server oder Hoster übergeben und vom Browser bei Besuch der Seite „geprüft“.

Manche Zertifikate, oft die günstigeren, benötigen zusätzlich noch ein Zwischenzertifikat (CA), auch sog. Root- oder Intermediate-Zertifikat. Dieses ist ebenfalls auf dem Webserver zu installieren.

Vertrauenswürdig oder nicht?!

Man sollte meinen, dass eine „Zertifizierung“ einer dafür berufenenen offiziellen Stelle bereits ausreicht. Nein! Denn auch die Zertifizierungsstelle muss noch mal extra durchzertifiziert werden. Klingt komisch? Ja – ist aber so!

Das bedeutet konkret, dass das verwendete Zertifikat auch offiziell als vertrauenswürdig eingestuft sein muss. Meist geschieht dies direkt, manchmal aber über übergeordnete Zertifikate, die dann aber auch zusätzlich auf dem Webserver installiert werden müssen. Hier spätestens wird die gesunde Toleranz stark beansprucht. Daher verlinke ich hier auch nur auf weiterführende Informationen:

Was ist ein vertrauenswürdiges SSL-Zertifikat?

Das Zertifikat ist installiert, die Webseite umgestellt, alles freut sich grün –  aber leider ist das Zertifikat nicht „vertrauenswürdig“, was nicht jede Platform meldet, aber dazu führen kann, dass ein hässliches PopUp den Webseitenbesucher zB. auf Androidgeräten zurückstösst:


Autsch-Faktor: 8

Variante eins: der Webhoster kümmert sich. Diese meist kostenpflichtige Variante (in manchen Tarifen aber bereits auch enthalten) ist sicher die einfachste, aber nicht unbedingt die günstigste. Unabghängig davon müssen dennoch manuell Änderungen vorgenommen werden. Wer sich hierfür entscheidet sollte seinen Webhoster fragen und dennoch über die nachfolgenden Punkte Bescheid wissen.

Variante zwei: (günstiges) DV-Zertifikat selbständig erwerben. Hierzu habe ich positive Erfahrungen mit dem Portal sslmarket.de gemacht. Es gibt dort auch vom Anbieter RapidSSL ein kostenloses Zertifikat testweise für einen Monat zum ausprobieren, das man bei Gefallen anschließend kostenpflichtig verlängern kann. Bei RapidSSL sollte zuvor noch eine fest vorgegebene E-Mail admin, administrator, hostmaster, webmaster oder postmaster@meine-domain.com vorhanden sein, mit der die Zertifikatsstelle die Domain validiert. Weiterhin kommt man auch nicht daran vorbei, sich die Schlüssel eigenständig zu erbasteln. Das kann man auf seinem lokalen Rechner durchführen oder auch im Internet z.B. hier bei csr-generator.com (interessanterweise eine nicht verschlüsselte Webseite 🙂 ).

Variante drei: kostenloses Zertifikat über Let’s encrypt. Angedacht ist dies vor allem für Webmaster, die einen eigenen Shell-Zugang zu ihrem Server haben. Für alle anderen gibt es (derzeit?) den Komfortverlust der manuellen, wenn auch kostenlosen Erneuerung alle 90 Tage, was schon etwas schmerzt. Die Erstellung des Zertifikats wird enorm erleichtert über Platformen wie ZeroSSL, auf der man innerhalb von zwei Minuten ein fertiges DV-Zertifikat im Stil von Let’s Encrypt gebacken bekommt, das zudem noch ein hohes A-Ranking aufweist, also technisch hoch angesehen ist, wie es nicht alle kostengünstigen Anbieter erstellen.

Rechnet man allerdings vier mal im Jahr eine je 15 minütige Zertifikatsverlängerung in Stundensatz um, so eignet sich dies aus betriebswirtschaftlicher Sicht wirklich nur für Idealisten. Ein teurerer eigener Managed Server wiederum bietet die Möglichkeit der automatisierten Verlängerung.

#2 – Datensicherung

Nur noch wenige Narren versuchen sich ohne Datensicherung durchs digitale Leben zu schlawinern. Es gibt inzwischen so viele hervorragende und hochkomfortable Sicherungsmechanismen in WordPress, dass ich an dieser Stelle nicht detaillierter darauf eingehe.

Da mein Vorgehen zu einem späteren Zeitpunkt eine Suche&Ersetze-Funktion auf tiefster Datenbankebene vornimmt, ist hier besondere Sorgfalt bei der Sicherung der Datenbank nötig. Und auch hier sei erinnert: ein Backup, das man über ein Restore nicht wiederherzustellen weiß und erfolgreich getestet hat, hat keinen Wert.

Ich nutze das plugin BackWPUp oder führe die Sicherung manuell beim Hoster in phpMyAdmin durch.

Die Sicherung lässt man ausfallen und verlässt sich auf die Software oder man sichert, aber kann leider das Backup im worst case nicht wieder herstellen.
Autsch-Faktor: 10

#3 – An HTTPS herantasten

Dieser Schritt mag dem Hardcore-Tekkie unnötig erscheinen, mir gibt er besonders bei Webseiten-Ausfallzeit-empfindlichen Projekten bzw. Kunden ein gutes Gefühl. Denn jetzt wird es ernst. Hier auch der Hinweis, dass ab jetzt die Webseite etwas „flackert“ bzw. nicht gaaaanz rund läuft, bis der Prozess vollständig abgeschlossen ist – daher sollte diese Übergangsphase möglichst zügig abgewickelt werden und zu unkritischen Zeiten stattfinden.

Ich gehe, nachdem ich die Datensicherung als Fangnetz und das Zertifikat vor über 2 Tagen installiert habe, ins WordPress backend unter Einstellungen - Allgemein und füge das begehrte ’s‘ von https bei beiden Einträgen hinzu:

Danach muss ich mich erneut im backend anmelden und prüfe nun im ersten Schritt, ob ich im Frontend auch (kurzzeitig) das grüne Vorhängeschloss-Symbol vorfinde und die Webseite noch erreichbar ist. Das sollte sie sein. Hier vergewissere ich mich nur, ob ich bisher alles richtig umgesetzt habe. Ist mehr so ’ne emotionale Sache … 😉

Gleichwohl muss ich auch prüfen, dass der Browser aufschreit und mahnend mit gelbem Vorhängeschloss warnt, dass hier auf einer prinzipiell verschlüsselten Seite noch unverschlüsselte Elemente zu finden sind. Ja, das sind sie, denn wir haben ja noch nicht in einer Bulk-Operation sämtliche Datenbankeinträge auf https umgestellt. Da WordPress die Links nicht relativ sondern z.B. in den Posts als absolut ablegt (warum eigentlich?), sind Grafiken und interne Verlinkungen alle noch auf dem alten http://.

Diese Verifikation sollte wie gesagt nicht überraschen, aber ich weiß nun sicher, wo ich stehe und dass Zertifikat, Server, WordPress, der Browser und ich sich einig über den derzeitigen Status sind.

Sollte hier aus irgendeinem Grund WordPress aussteigen und die Webseite nicht mehr angezeigt werden, keine Panik. Entweder in der Tabelle options die beiden Einträge wieder zurücksetzen oder in der wp-config.php die beiden Zeilen einfügen (meine-seite.com natürlich mit der richtigen Domain ersetzen):
define('WP_HOME','http://meine-seite.com');
define('WP_SITEURL','http://meine-seite.com');

Anschließend ist der vorige Zustand wieder hergestellt und das Problem kann in Ruhe analysiert und behoben werden.

Baustellenseite wird erzeugt und viel zu lange in dieser Phase stehen gelassen … Sorgfaltsverletzung fällt auf.
Autsch-Faktor: 3

#4 – Datenbankoperation Suche & Ersetze

Nachdem wir jetzt wissen, dass eigentlich alles bereits funktioniert, kommt die Suche-Ersetze-Operation direkt in der Datenbank. Das liegt daran, dass es noch jede Menge Einträge in der Datenbank gibt, in der die Domain noch mit http:// referenziert wird, auch wenn ich die Änderung auf https:// bereits in den Einstellungen wordpress mitgeteilt habe.

Dazu nutze ich das plugin Search & Replace von Inpsyde GmbH. Es verfügt über einen Testmodus und bietet detaillierte Information über Änderungen sowie Export/Import und Operationen nur über bestimmte Tabellen. Zudem war Frank Bültge an der Entwicklung mit beteiligt, was für sehr gute und saubere Codequalität spricht – ein absolutes MUSS bei solch empfindlichen Eingriffen.

Wichtig ist auch zu berücksichtigen, dass die zu ändernden URLs in der Datenbank teilweise als serialized strings abgelegt werden, was eine normale Textersetzung verunmöglicht.

Der simple Ersetzungsvorgang lautet nun also:
suche
http://www.meine-domain.com
und ersetze es mit
https://www.meine-domain.com

bzw.

suche
http://meine-domain.com
und ersetze es mit
https://meine-domain.com

Weil es so wichtig ist: unbedingt auf die 100% korrekte Schreibweise achten! Buchstabendreher oder andere Unaufmerksamkeiten wären hier fatal.

Hat man fälschlicherweise beide Vorkommnisse in der Datenbank (mit und ohne www), so müssen zwei Ersetzungen erfolgen: zunächst mit oder ohne www vereinheitlichen (für eine korrekte Entscheidung am besten schauen, was google verwendet!) und anschließend Ersetzung durch https. Reihenfolge beachten!

Ich empfehle, das plugin aus Sicherheitsgründen vor möglichen Hackerangriffen nach erfolgreicher Verwendung wieder zu entfernen (wie im übrigen alle nicht verwendeten plugins), wenn es nicht mehr benötigt wird.

Datenbank crasht, Tippfehler beim suchen & ersetzen, Datenbank zu groß, php Scriptlaufzeit zu kurz und bricht vorzeitig ab, die Domain wurde mal mit www und mal ohne www referenziert und nur ein Teil wird ersetzt.
Autsch-Faktor: 7 bis 10

#5 – Anpassen der binär codierten Elemente

Anschließend sollte es keine Vorkommnisse der Domain mit http-Protokoll mehr geben. Sollte! Denn manche Themes haben die Angewohnheit, ihre Einstellungen z.B. über Hintergrundbilder in binärer Codierung zu speichern. Das merkt man dann, wenn man sich die einzelnen Seiten im Frontend betrachtet und feststellt, dass immer noch die gelbe Warnung kommt, nicht alle Elemente seien auf HTTPS. In der Regel wird man dann fündig in den Einstellungen des Themes bei favicon, Logo, Hintergrundbild, Headerbild, etc. Dort einfach das selbe Bild nochmal über die Mediathek laden und speichern, dann sollte HTTPS verwendet werden.

Schlecht programmierte plugins oder Themes verkraften den Wechsel auf HTTPS nicht. Manuelles Korrekturcodieren erforderlich oder Wechsel auf Alternativen.
Autsch-Faktor: 10

#6 – Automatische Umleitung dem Webserver mitteilen

Damit zukünftig alle HTTP Anfragen auch automatisch sauber auf HTTPS umleiten, sollte unbedingt in der Datei .htaccess der (hier fett markierte) Dreizeiler hinzugefügt werden an diese Stelle, die WordPress bereits schon üblicherweise hinein geschrieben hat:


RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !^meine-domain\.com$ [NC,OR]
RewriteCond %{HTTPS} =off
RewriteRule ^(.*)$ https://meine-domain.com/$1 [R=301,L]
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

Wichtig: Schreibweise mit oder ohne www beachten – entweder oder! Und natürlich die richtige Domainschreibweise anstelle von meine-domain.com verwenden. Vorsicht bei Umlauten! Dort muss dann die entsprechende Schreibweise beachtet werden: aus www.bücher.de wird dann nämlich www.xn--bcher-kva.ch.

Es reicht für eine saubere Umsetzung NICHT aus, einzig die beiden wordpress-Einträge auf https umzustellen!

Die Änderungen bewirken gar nichts, die Seite ist immer noch über HTTP erreichbar – Cache gelöscht? .htaccess ist ’ne Diva und mag zB. keine Doppeltangaben: sich an das korrekte Format gehalten? Autsch-Faktor: 4. Erst Monate später wird das Abgleiten im google Ranking bemerkt (Autsch-Faktor: 7) und nicht in Zusammenhang gebracht mit einer Fehlkonfiguration der .htaccess (Autsch-Faktor: 10).

#7 – Alle Seiten und Unterseiten auf grün prüfen

Sofern alles nach Plan lief, sollten nun sämtliche Seiten sauber auf verschlüsseltem HTTPS laufen und auch nur dort erreichbar sein. Ich empfehle das manuelle durchklicken in einem Cache geleerten Browser und gleich auch nochmal stichprobenartig auf einem Smartphone.

Sollte es immer noch gelbe Warnungen des Browsers geben auf eingebettete unverschlüsselte Elemente auf einer Seite, so kann man sich detaillierte Hinweise anzeigen lassen bei Firefox über rechte Maustaste ‚Element untersuchen‘ – ‚Konsole‘. Dort stehen dann entsprechende Fehlermeldungen in der Art ‚Die Seite wurde über HTTPS aufgerufen, hat aber unsicheren Inhalt soundso geladen …‘

Als krönenden Abschluss empfehle ich nach erfolgreicher manueller Prüfung die kostenlose, externe, automatisierte Prüfung auf trustworthyinternet.org (ssllabs.com). Die eignet sich auch als Dokumentation über die erfolgreiche Umstellung für Kunden:

Nicht alle (Unter)Seiten sind korrekt verschlüsselt und führen zur Abwertung bei Browser, Besuchern und google.
Es existieren extern eingebundene Inhalte (z.B. per
Autsch-Faktor: 6 bis 8

#8 – google u.ä. anpassen

In Tracking- und Auswertungs-Tools wie z.B. google webmaster sollten die Änderungen über die Umstellung auf HTTPS bekannt gemacht werden.

das Webmastertool wird darüber nicht explizit informiert und liefert falsche Ergebnisse mit (mir) unbekannten Seiteneffekten.
Autsch-Faktor: 4


#9 – Verlängerung des Zertifikats

Je nach dem, wo und wie das Zertifikat erstellt wurde und mit welcher Laufzeit, müssen unterschiedliche Tätigkeiten durchgeführt werden, um es zu verlängern. Im besten Falle wird dies automatisch vom Webhoster erledigt, ansonsten wird man meist per E-Mail vom Zertifikatsanbieter daran erinnert und muss entsprechend handeln.

Einfach vergessen: Browser und google finden das echt doof.
Autsch-Faktor: 7




Wie so oft in der Softwarekonfiguration, so wird auch bei der Umstellung einer Webseite auf HTTPS die Sorgfalt und das ruhige reflektieren und durchspielen und genaue Tests den GAU verhindern. Es ist ein kleiner aber feiner Eingriff mit großer Auswirkung, wenn’s nicht richtig gemacht wird. Ich hoffe, dieser Artikel bewahrt vor so manchem Crash und hilft, die Ängste vor dieser meist leider notwendigen Operation zu mildern und macht Mut, sich dessen anzunehmen.

Ergänzungen, Korrekturen und Fragen? Ich freue mich über konstruktive Kommentare, die uns und anderen damit vielleicht weiter helfen wird!

Un pensiero su “Anleitung zur Umstellung auf HTTPS – Checkliste für Tekkies”

  1. „Erst Monate später wird das Abgleiten im google Ranking bemerkt (Autsch-Faktor: 7) und nicht in Zusammenhang gebracht mit einer Fehlkonfiguration der .htaccess (Autsch-Faktor: 10).“

    Getroffen! Danke für die Infos, scheinbar hatte ich in der htaccess tatsächlich etwas falsch gemacht. Und das vor einem halben Jahr… Jetzt bin ich mal gespannt, ob sich das google Ranking wieder verbessert.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Durch die weitere Nutzung der Seite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen