Am 11.11.2015 habe ich damit begonnen meine WordPress Seite auf HTTPS umzustellen. Eines vorweg – das Ganze ist schon mit einem gewissen Zeitaufwand verbunden. Zumal, wenn man so etwas zum ersten Mal ohne Vorkenntnisse angeht. Meine Seite ist übrigens bei all-inkl.com gehostet und die Erläuterung beschreibt diesen Weg.
Zu allererst muss man die Voraussetzungen zu einer SSL-Verschlüsselung schaffen. Dazu habe ich die Zusatzoption SSL-Erweiterung hinzugebucht, da diese in meinem Vertrag nicht enthalten war. Dann wurde beim chinesischen Anbieter WoSign ein SHA-2 Zertifikat erstellt. Das geht ganz einfach. Nach Anlegen eines Accounts gibt man die CSR aus den Einstellungen des SSL-Schutzes ein. Nun wird von WoSign das Zertifikat erstellt, welches dann sofort zum Download bereit steht.
Den Inhalt der CRT und der Zwischenzertifikate kopiert man dann und fügt diese in die Option des SSL-Schutzes beim Hoster (all-inkl.com) ein. Nun wird SSL aktiviert und die eigene Seite sollte nun über das erstellte Zertifikat erreichbar sein.
Als Nächstes stellt man in WordPress unter Einstellungen => Allgemein beide URLs auf https://domain.de.
Nun werden folgende SQL-Befehle in der Datenbank ausgeführt, um alle alten Adressen mit https:// zu versehen.
|
1 |
UPDATE wp_options SET option_value = replace(option_value, 'https://domain.de', 'https://domain.de') WHERE option_name = 'home' OR option_name = 'siteurl'; |
|
1 |
UPDATE wp_posts SET guid = replace(guid, 'https://domain.de','https://domain.de'); |
|
1 |
UPDATE wp_posts SET post_content = replace(post_content, 'https://domain.de', 'https://domain.de'); |
|
1 |
UPDATE wp_postmeta SET meta_value = replace(meta_value,'https://domain.de','https://domain.de'); |
Dabei müssen natürlich diese vier Befehle an die eigene Domain sowie die Änderungen der Einstellung der URLs in WordPress an die eigene Domain angepasst werden. Um nun HTTPS zu erzwingen werden der .htaccess folgende Einträge gesetzt.
|
1 2 3 |
RewriteEngine On RewriteCond %{HTTPS} !=on RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] |
Ist dies geschehen, hat man es fast geschafft. Im Backend wird schon ein grünes Schloss in der URL signalisieren, dass die Seite nun zu 100% verschlüsselt ist. Im Frontend hingegen, wird dies nicht so einfach sein. Nun wird es je nach Aufbau der Seite etwas zeitaufwändig. Man muss nun alle alten HTTP-Adressen in HTTPS per Hand ändern. Probleme können hier u.a. Grafiken machen. Dazu ist es auch ratsam alle Plugins zu deaktivieren und alle Widgets von der Seite zu nehmen. Ist nun das Schloss immer noch nicht grün, so kann es, wie schon erwähnt, auch an einem verwendeten Logo liegen. Auch hier ist der Pfad auf HTTPS umzustellen. Zur Not schaut man sich den Quellcode der Seite an und sucht nach den Fehlern. Ist dann alles soweit in Ordnung, können nach und nach alle Plugins aktiviert und Widgets wieder gesetzt werden.. Bei jedem Schritt überprüft man die Schloss-Anzeige in der URL. So kann man gut herausfinden, ob ein Plugin oder Widget evtl. Probleme macht. Ist dies der Fall, so muss man sich auf die Suche nach dem Fehler machen.
Das Plugin WP Maintance Mode musste bei mir deinstalliert und wieder installiert werden, bevor die Grafiken richtig verschlüsselt wurden.
Ich habe das nun alles soweit geschafft und meine Seite bietet nun die von mir gewünschte Sicherheit.
Ein kleiner Hinweis noch am Rande. Wenn man PIWIK zur statistischen Erfassung einsetzt und das Tool nicht mehr trackt, dann ist es ratsam das PIWIK-Verzeichnis hinter das WordPress-Verzeichnis zu hängen. In dem Fall wäre PIWIK dann über die Adresse https://www.domain/piwik/ erreichbar und sollte dann korrekt arbeiten.
Das ist bei uns kostenlos und, wie es mir scheint, auch wesentlich einfacher, Uberspace: https://wiki.uberspace.de/webserver:https#nutzung_eigener_tls-zertifikate
Na dann lass mich, wenn es soweit ist, an deinen Erfahrungen teil haben. 😉
Erstmal ist der HiFiBerry dran. Dann kommt das Nächste. Hoffentlich ergibt sich da nicht ein ähnlicher Ärger wie oben beschrieben.
Ich weiß doch! Und auch da freue ich mich schon auf neuen Lesestoff!
Hi, deine Webseite wird mir als nicht sicher angezeigt, wenn ich sie mit einem aktuellen Chrome besuche. Da stimmt irgendwas noch nicht.
PS: Serverzertifikat ist nicht vertrauenswürdig.
Bei mir ist mit Chrome alles ok..
Ich verwende Version 46.0.2490.86 (64-bit) – ohne Probleme. Ich habe über verschiedene Endgeräte getestet. Komisch! Welche Einstiegsseite betrifft das?
Benutze Chrome Version 46.0.2490.86 (64-bit) auf einem Mac (auch aktuell). Als Einstieg habe ich http://osbn.de/ gewählt. Auch bei der Abo Bestätigung gerade über die Mail kam die gleiche Warnung noch einmal.
Dafür habe ich im Moment keine Lösung. Wie gesagt, auf allen getesteten Endgeräten (Windows, Linux, Android und iOS) funktioniert es bei mir problemlos.
Vielleicht melden sich ja noch mehr Leser. Ich habe keine Idee woran es liegen kann.
Hmm, eben ging es für eine Sekunde. Nochmal neu geladen und schon wieder die Warnung. Zertifikat wurde von einer „unbekannten Instanz signiert“ (Zitat aus den Zertifikatinformationen).
https://www.dropbox.com/sh/ph43ibspv250eck/AACOgFDEAwmZywSiBSmMVynNa?dl=0
Gleiches auf iPad mit Safari und Android 6.0 und Chrome mit und ohne Wlan.
Hallo Ben, kannst du bitte nochmal antesten?
Jetzt ist alles grün 😉
Die im Artikel erwähnten Brückenzertifikate sind rausgerutscht bzw. wurden nicht übernommen. Meine Internetverbindung ist im Moment nicht die beste. Deshalb wurden die Einträge nicht gespeichert. Danke für den Hinweis, Ben!!!
Klaro! Gerne 😉
Beim Mobile Chrome 46 auch rot.
Es scheint kein Intermediate korrekt konfiguriert, somit kann je nach Browser/OS keine Chain of Trust hergestellt werden. Siehe: https://www.sslshopper.com/ssl-checker.html#hostname=Intux.de
Beim Apache muss das Intermediate mit dem Parameter SSLCertificateChainFile hinzugefügt werden. Wenn es bei deinem Host keine solche Option gibt, kannst du das Intermediate-Zertifikat gaz einfach unter dein eigenes kopieren, das sollte dann eigentlich reichen.
—–BEGIN CERTIFICATE—–
(dein Zertifikat im PEM Format)
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
(das Intermediate von WoSign [Common Name: WoSign CA Free SSL Certificate G2] im PEM Format)
—–END CERTIFICATE—–
Danke für den Link, Schroeffu.
Schaut Euch Let’s Encrypt mal an
Echt jetzt ? Ein China-Zertifikat ? Und du denkst, deine Seite ist jetzt sicher ? Zu soviel naiver Doofheit fällt mir nichts ein. Pseudo-Admins wie dich sollte man zu einem Internet-Führerschein verdonnern.
Und das nur wenige Tage, wo Lets Encrypt startet – die paar Tage hättest du auch warten können.
PS:
Grüße an die MITM-Mitleser aus dem Reich der Mitte !! Danke für die Nudeln …
Dir ist aber schon klar, dass die Chinesen nur den Zertifikat Request unterschrieben haben und nicht den private key haben?
„Nach Anlegen eines Accounts gibt man die CSR aus den Einstellungen des SSL-Schutzes ein.“ Liest sich so, als hätte er den CSR von seinem Hoster bekommen, der dann auch den private key erstellt hat. Was natürlich auch suboptimal ist, anderseits kommt der Hoster fast immer auch ohne Fragen an die Daten ran, wenn er kriminell genug ist. 😉
Wie soll man das mit der Datenbank ändern, wenn man nur über phpmyadmin Zugriff auf die Datenbank hat?
Na einfach mit https://„domain“/phpmyadmin sollte es nach der Anleitung funktionieren.