Nicht 100% umgestellter Content auf https:// ist böse. Der Browser verweigert je nach dem alles, was mit http:// Content zu tun hat.

Nicht 100% umgestellter Content auf https:// ist böse. Der Browser verweigert je nach dem alles, was mit http:// Content zu tun hat.

Inzwischen ist es problemlos möglich, kostenlose und offiziell signierte Zertifikate über 3 Jahre Gültigkeit zu erhalten. Aus meiner Sicht spricht nichts mehr dagegen, meinen eigenen Blog http://schroeffu.ch auf HTTPS-only https://schroeffu.ch umzustellen. Gesagt, getan.

Aber halt! Ganz so schnell geht es leider nicht. Dem WordPress fehlt ein gescheites Werkzeug, um die Umstellung reibungslos durchzuführen. WordPress liefert an vielen Stellen nach der einfachen Umstellung trotzdem noch http:// URLs aus, weil diese hart kodiert in der Datenbank wp_posts verbleiben. Das ist sehr gefährlich, denn bei zu viel HTTP Content auf einer verschlüsselten Webseite liefert der Browser (Chrome ist ein Paradebeispiel dafür) die Webseite nicht korrekt aus. Das endet dann richtig hässlich, wie mein zufällig gefundes Beispiel im Bild zeigt. Aber auch das ist lösbar.

Risiken? Ja! Am Ende des Artikels gehe ich auf weitere Risiken beim Einsatz von HTTPS-only ein. Misstrauische Webmaster mögen bitte diesen Teil zuerst lesen.

1. Kostenloses, offiziell signiertes Zertifikat generieren

Wie das funktioniert (es ist kinderleicht), beschreibe ich in meinem Artikel Kostenlose SSL Zertifikate mit 3 Jahren Gültigkeit erstellen lassen. Bei korrekter Durchführung besitzt man am Ende ein .crt Zertifikat, ein .key PrivateKey und das Chain-File.

2. Apache um VirtualHost HTTPS 443 erweitern

Mein Apache 2.4 auf Debian 8 hatte Port 443 bereits aktiviert. Unter Umständen muss die Zeile #Listen 443 in /etc/apache2/ports.conf aktiviert werden.

sudo a2enmod ssl

Die Konfiguration eines VirtualHost schaut bei jeder  Webseite anders aus, ich kann hier also keine Pauschallösung zeigen. Im Prinzip sollte die Konfiguration von dem bestehenden VirtualHost auf Port 80 übernommen bzw. abkopiert werden. Dort hinzu fügt man die zusätzlichen SSL Informationen ein, welche mindestens folgende sein müssen:

<VirtualHost *:443>
SSLEngine on
SSLCertificateFile /etc/ssl/localcerts/mydomain.crt
SSLCertificateKeyFile /etc/ssl/localcerts/mydomain.key
SSLCertificateChainFile /etc/ssl/localcerts/mydomain.ca-bundle

ServerName mydomain.com
ServerAlias www.mydomain.com ww.mydomain.com w.mydomain.com
ServerAdmin root@mydomain.com

DocumentRoot /my/document/root
<Directory /my/document/root>
#balabala
</Directory>

#balabala

</VirtualHost>

Soweit, so einfach. Den Apache restarten, bis die Domain unter https://mydomain.com erreichbar ist. Doch freue dich nicht zu früh 😉 , es braucht noch einige Handarbeit.

3. WordPress Einstellungen auf HTTPS ändern

Jetzt folgt das WordPress spezifische. Als erstes muss in den Einstellungen > Allgemein die URL 2x auf https://mydomain.com korrigiert werden.

https_in_wordpress_settings

Diese Änderung schluckt WordPress problemlos, aber damit ist es keineswegs getan. Noch immer publiziert WordPress viele Bilder als unsichere http:// Links, die Startseite mit HTTPS wird mit Google Chrome vermutlich nicht korrekt dargestellt.

4. Alle WordPress URLs auf HTTPS ändern

Die problematische Darstellung wird hiermit korrigiert. Mein WordPress hatte über 1000 URLs in der MySQL Datenbank noch mit http:// anstatt https:// hart kodiert referenziert. Es gibt viele Plugins und viele Ideen dieses Problem zu beheben, aber ganz ehrlich, alle sind doof bis auf die direkte Datenbank-Query Möglichkeit. Doch keine Angst, um nicht selbst ein MySQL Query zusammenstricken zu müssen, empfehle ich das

welches nach der Installation unter Werkzeuge > Better Search Replace verfügbar ist.
Achtung: Die Datenbank sollte vorher backupped werden! Wer sich hier vertippt, hat ein Problem.

Der letzte Haken ist gut, um nur einen Testlauf durchzuführen. Wenn man sicher ist, was man tut, kann der Haken entfernt werden. Auf keinen Fall etwas falsches eingeben, das kann die Datenbank zerstören!

Vorher die DB backuppen! Auf keinen Fall etwas falsches eingeben, das würde den Inhalt der Datenbank zerstören!

Der letzte Haken ist gut, um nur einen Testlauf durchzuführen. Wenn man sicher ist, was man tut, darf der Haken entfernt werden. Vertippe dich bloß nicht! Diese Umschreibung muss mindestens 2x gemacht werden: Einmal für http:// (wie im Bild) und einmal für http://www.
Bei Verwendung eines Cache-Plugins, sollte jetzt der Cache geleert & bestenfalls neu generiert werden.

5. Nach unsicheren HTTP URLs suchen

Die einfachste Möglichkeit sind die beliebten HTTP-Crawler, wie sie WhyNoPadlock.com oder JitBit.com anbieten. Das Ziel muss sein, dass 100% alle URLs von deinem Webserver mit HTTPS an den Browser geschickt werden.

Falsch (Google Chrome/Chromium):

wrong_insecure_content2

Richtig (Google Chrome/Chromium):

correctly_secure_content

6. Plugin: SSL Insecure Content Fixer

Ich sehe dieses Plugin als Notlösung an, wenn auch leider ganz oft eine Notwendigkeit. Je nach WordPress Theme bzw. viele Plugins zeigen immer noch URLs auf http:// anstatt https://. Diese sind dann nicht in der Datenbank notiert, sondern in Files unterhalb wp-content/themes/* und wp-content/plugins/* geschrieben. Das Plugin SSL Insecure Content Fixer schafft hier Abhilfe und kann unter Einstellungen > SSL Insecure Content Fixer zu noch drastischeren Rewrites genötigt werden.

Achtung beim Einsatz eines Cache Plugins!

  • Beim Einsatz von W3 Total Cache sollte die Option Cache SSL (https) requests aktiviert werden.
  • Andere Caching-Plugins könnten ähnliche Optionen bereitstellen.

Ich empfehle den Einsatz eines Cache Plugins. Auf schroeffu.ch setzte ich WP Super Cache ein mit Preload Funktion. Dadurch befinden sich von SSL Insecure Content Fixer erzeugte Korrekturen immer im aktuellen Cache.

Spätestens jetzt sollte deine Webseite keinen HTTP Content mehr wiedergeben und mit HTTPS auf allen Browsern & Mobilen Geräten korrekt dargestellt werden.

7. HTTP deaktivieren

Man sollte prinzipiell nicht HTTP und HTTPS auf einer Domain zeitgleich erlauben. Klar, das ist selbstverständlich möglich, aber tun sollte man es nicht. Und deshalb empfehle ich eine Rewrite-Rule, die innerhalb des VirtualHosts von Port 80 gesetzt wird.

 #### REDIRECT TO SSL , EVERYTHING! ####
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}$1 [L,R=301]
#### DONE! ####

Damit wird jeder Request von HTTP nach HTTPS weitergeleitet. HTTP ist damit für diese Domain «deaktiviert».
Übrigens: R=301 bedeutet «Permanent Redirect», also meinen wir es sehr ernst und Google wird die URLs schon bald im Index korrigieren.

8. HTTPs bei Google Webmaster (Console) hinzufügen

Zu guter Letzt sollten Webmaster mit einem Google Console Account (Google Webmaster) die neue HTTPS Erreichbarkeit der eigenen Domain hinzufügen. Über Property Hinzufügen oben Rechts kann https://mydomain.com hinzugefügt werden:

Google Webmaster (Google Search Console) sollte über die neue Domain-Erreichbarkeit unterrichtet werden.

Google Webmaster (Google Search Console) sollte über die neue Domain-Erreichbarkeit unterrichtet werden.

Fertig. Nach diesem Marathon sollte WordPress endlich korrekt, vollständig und ohne Fehlermeldungen im Browser, auf HTTPS umgestellt worden sein.

Risiken? Ja!

Es hat durchaus Risiken, die eigene Webseite auf HTTPS-only umzustellen. Hast du dich jemals gefragt, warum ein riesiges Portal wie z.B. 20min.ch oder Gamestar.de kein HTTPS anbieten? Das hängt oft mit der Werbung zusammen: Werbetreibende blenden Ihre Werbung ganz oft nicht über HTTPS ein, wodurch die Besucher – erneut – eine Browserwarnung erhalten. Große Portale wollen dieses Risiko nicht eingehen.

Am schlimmsten für Blogger wird sein, dass eingebettete Videos ohne HTTPS Untersützung nicht mehr angezeigt werden – in Google Chrome & Mozilla Firefox. Youtube ist dabei nicht das Problem und unterstützt HTTPS seit Jahren, aber eingebettete Videos von Webseiten wie beispielsweise „PC Games Hardware“, welche kein HTTPS anbieten, sind jetzt ein großes Problem.

Ein weiteres Beispiel sind Foren, in denen die User eigene Bilder aus anderen Webseiten, die nicht über HTTPS erreichbar sind, posten. Doch wenigstens dieses Problem ist so gut wie gelöst, inzwischen bieten die besten Foren einen «Image & SSL Proxy» an, wodurch das Bild auf dem eigenen Forenserver als HTTPS erreichbar zwischengespeichert wird.

Daher gilt das Prinzip, nur auf Webseiten worin der Webmaster den Content 100% selbst steuern kann, lohnt sich überhaupt SSL zu erzwingen.

Lohnt sich der Aufwand?

In meinen Augen, ja ganz klar! Ich persönlich bin für ein 100% verschlüsseltes Internet, völlig egal ob es nun nötig ist oder nicht! Dazu kommt, dass Google in der eigenen Suchmaschine angeblich HTTPS Webseiten im Ranking bevorzugt.

  • Tom

    Hallo, hier spricht der „Zertifikats-Tom“ 😉

    In Deutschland sollte / muss man seit 1. August 2015 auch aus rechtlicher Sicht auf HTTPS-only umstellen. Mit dem IT-Sicherheitsgesetz wurde in § 13 Abs. 7 TMG sozusagen die TLS-Pflicht für „geschäftsmäßig“ angebotene Telemedien eingeführt. Also etwa für Webseiten, Blogs, Shops, Apps. (Seiten mit Werbung gehören auf jeden Fall dazu!)

    Ich vereinfache mal: Jeder der in Deutschland ein Impressum benötigt, muss sich auch an die neue TLS-Pflicht halten. Das heißt nicht, dass man sich jetzt nur irgendwo schnell ein Zertifikat klicken muss. Viel mehr gilt, sich auch an aktuelle Mindeststandards (gemeint sind wohl BSI/ENISA-Vorgaben oder RFCs) für verschlüsselte Kommunikation zu halten.

    Folglich gilt:
    1.) Private Key mit 4096 bit RSA generieren.
    2.) Ein anerkanntes SHA256-Zertifikat besorgen.
    3.) Kostenloses 3-Jahres Zertifikat gibt’s bei „WoSign“.
    4.) Apache bzw. Nginx konfigurieren.
    5.) Die Seite bei ssllabs.com überprüfen lassen.
    6.) „TLS 1.2“ + „Forward Secrecy“ + „AES-GCM“ + „HSTS“ + „OCSP stapling“ anbieten.
    7.) Diffie-Hellman Parameter für DHE-Ciphersuites auf 4096 bits setzen.
    8.) Als Kurve für ECDHE-Ciphers mindestens secp384r1 einsetzen, welche jedoch als unsicher gilt. Was besseres lässt sich aber im Moment für den Alltag nicht konfigurieren. Dafür müsste man auf TLS 1.3 mit Curve25519 warten.
    9.) Kein SSL 2.0 / 3.0, kein RC4 anbieten (gelten als unsicher!)!

    Gute Argumente, sich an die TLS-Pflicht zu halten…
    1.) Die Vorratsdatenspeicherung kommt! Je mehr Verschlüsselung, desto besser!
    2.) HTTPS-Websites lassen sich sehr schlecht zensieren! (https://www.eff.org/deeplinks/2015/08/russias-wikipedia-ban-buckles-under-https-encryption)
    3.) TLS verschlüsselt nicht nur, sondern schützt auch vor Drive-by-Exploits / MITM-Attacken.
    4.) Es droht eine riesige Abmahnwelle für Websites, die sich nicht an die TLS-Pflicht halten.
    5.) Richtig konfiguriertes HTTPS ist schneller als HTTP (https://www.httpvshttps.com/)
    6.) Suchmaschinen und Browser (hinsichtlich Plugins) bevorzugen HTTPS-Seiten.

    Daher: Stellt auf HTTPS-only um! Seiten, die dies nicht tun, bitte abmahnen!

    • Schroeffu

      Hallo Tom,

      sehr gut erklärt, danke dafür. Ich experimentiere gerade mit HSTS herum und frage mich, wieso wird empfohlen über 180 Tage max-age=15552000 anzugeben? Das ist doch richtig lange. Besucher, die diesen Header bekommen, deren Browser würde ein halbes Jahr nie mehr auf die Idee kommen, die Domain (und Subdomains) mit HTTP Aufzurufen? Und was, wenn der Webseiten Betreiber auf HTTP zurückrudert? Oder später doch noch eine SubDomain ohne HTTPS ausliefert? Wieso nicht einfach 1day max age?

      Header always set Strict-Transport-Security „max-age=15552000; includeSubDomains“

      Grüsse Schroeffu

      • Tom

        Hallo Schroeffu,

        das alte „HTTP“ soll in nächster Zeit komplett sterben. Wie oben beschrieben, macht es daher auch keinen Sinn, seine „HTTPS“ Domain oder Subdomain wieder auf ein „HTTP“ zurückzustellen.

        Im Moment ist es noch so, dass die Browser aus der Eingabe von „domain.de“ automatisch ein „http://domain.de“ machen. Durch den HSTS-Header merkt sich der Browser, dass er in den nächsten XXX Sekunden aus der Eingabe von „domain.de“ bzw. auch aus „http://domain.de“ automatisch ein „https://domain.de“ machen soll.

        In ein paar Jahren wird der HSTS-Header wieder überflüssig, weil alle Seiten dann by default nur noch mit „https://…“ aufgerufen werden. HSTS ist also nur für die Übergangszeit.

        Die Zeitangabe sollte man ruhig auf ein halbes Jahr oder noch länger setzen. Ein paar wenige Tage sind nur für’s Testen sinnvoll.

        Ärgerlich ist es nur für Leute, die sich eine neue Domain holen, bei der der Vorbesitzer einen sehr langen HSTS-Header gesetzt hat und der neue Besitzer nun für diese Domain kein https anbietet. Dann können frühere Besucher eine Zeit lang die Seite nicht aufrufen (weil „http“ gar nicht mehr angesteuert wird).

        Aber es gibt einfach keinen Grund sich länger gegen https zu stellen. Server-Admins müssen das jetzt einfach machen. Und wem das neue „Let’s Encrypt“ Projekt auch zu umständlich ist, muss halt dann auf einen TLS-Proxy-Provider wie CloudFlare zurückgreifen.

  • intux

    Ein sehr interessanter Artikel. Hätte den gern vor der Umstellung meiner Seite gelesen.
    Danke nochmals für den Link gestern. So konnte ich dann ausmachen, dass es noch ein Problem mit den Brückenzertifikaten gab.

    Grüße aus Halle

  • Dennis

    Hi eine Frage. Wie ändert man seine Seite von https auf http um ? Habe jetzt das Problem, das googleboot alles auf https absucht, aber meine alte Seite ist theoretisch noch auf http eingestellt. Zum einen habe Ich meine Seite komplet neu machen lassen, heißt: alles an Artikeln und Texten raus und neue Dinge rein. ja und alte Links sind noch da, bzw werden noch von boots gefunden. habe diese versucht zu löschen, aber google geht immer auf https seiten meiner URL. Das Kotzt mich langsam an und habe mir schon überlegt, neue Domain zu erstellen :- (

    • Schroeffu

      Hi Dennis,
      mir ist auch aufgefallen, Google indexiert generell https wenn https verfügbar, egal ob HTTP auch erreichbar ist. Deshalb sollte man sich für entweder 100% http, oder eben besser https entscheiden, bei Shops eigentlich ein Muss. Betrifft es bei dir http://highflyer-watches.com (wp-login.php) ? Bei WordPress muss man in den üblichen Seiten-Einstellungen > Allgemein die URL 2x (WordPress-Adresse/Website-Adresse) von http auf https ändern (Schritt 3 oben im Artikel). Achtung: Ab diesem Zeitpunkt ist auch der WP-Login nur noch per https erreichbar. Wenn noch alte Bilder oder Plugins aktiv sind die http laden , stimmen auch die Grafiken nicht mehr. Am Besten einfach die Plugins de- und Reaktivieren.

      Viel Erfolg 🙂

    • Schroeffu

      Nachtrag: Sobald die Aufrufe mit HTTPS funktionieren, muss mit einer Redirect-Regel http „deaktiviert“ werden (Step 7 im Artikel oben). Sofern man keinen direkten Zugriff auf den Apache hat kann man beim Hoster die .htaccess Datei damit beschreiben, oder noch besser, dein Hoster hat eine vorgefertigte Funktion „http deaktivieren“ – am besten einfach dort nachfragen, sobald die Haupt- und Unterseiten mit https korrekt aufrufbar sind.

  • Dennis

    Habe mal ein Screenshoot gemacht http://img4web.com/view/DKHMU kannst vielleicht auf dem PC speichern bzw runterladen und ran scrollen, sieht man besser 🙂
    Habe beim Host schon nachgefragt, aber die haben gelacht und gemeint, das ich das SSL Zertifikat kaufen soll 😀
    Aufjedenfall werden neue Seiten mit neuen Artikeln auch Indexiert, Nur wenn man über google auf eine der Seiten Drauf geht, dann kommt man erst auf https dann auf die Richtige http Seite. Ist schon mal gut. lag wahrscheinlich an der .htaccess Datei, wie du gesagt hast

  • Dennis

    Alsoo Die Bilder und Artikel werden noch über Google gefunden und es kommen auch Leute auf die Seite, aber danach auch ins Nirgendwo ( 500 Error) usw 🙂 Habe schon Über das Webmastertool in google , die Alte Seite rausgenommen und neue rein mit http. An Status steht, das die Seite noch Frisch ist und wird bearbeitet.
    Versucht schon Die alten Links mit https://www.google.com/webmasters/tools/removals?pli=1 Alte links zu entehren, auch wenn viele jetzt weg sind, geht der Robot von Google trotzdem auf die https Seite 😀
    Ja und es ist ein Affiliate Shop also kein Normaler Shop. Mit einem Richtigen Shop als unbekannter etwas verdienen zu wollen. heute geht das nicht mehr so einfach, wie vor 10 Jahren 🙂

  • Nils

    Hi,

    bin der Anleitung gefolgt, hatte zurvor eins der kostenlosen WoSign Zertifikate installiert. Die Seite läuft ohne Probleme auf HTTPs, mir ist nur ein Fehler aufgefallen, den ich mir nicht erklären kann. Wenn ich jetzt auf http://www.domain.com/wp-admin gehe (ohne httpS), dann erscheint eine Fehlermeldung:

    „Seite kann nicht geöffnet werden“.

    Gehe ich mit https auf das wp admin, ist es kein Problem. Hab ich vielleicht etwas falsch gemacht?

    LG
    Nils

  • Nils

    Hi,

    es scheint echt irgendwie mit der wp-config zu tun gehabt haben. Mit dem Admin über SSL ging es dann… allerdings hatte ich doch irgendwie mit dem Force To SSL Probleme, mein Shared Hosting hat NGinx und Vanish Cache, kann auch daran liegen.

    Habe jetzt einfach im WordPress die beiden Plugins
    – WordPress Force HTTPS
    – WordPress HTTPS
    installiert, jetzt läuft alles wie geschmiert. Keine Probleme!

    Danke noch mal für die Anleitung.

    LG
    Nils

    • Schroeffu

      Hey Nils,

      darf man fragen welcher Hoster das ist? Nginx mit Varnish ist wie ein Porsche und Ferrari zusammen 🙂 Finde ich genial, ich dachte die üblichen Hoster nutzen immer Apache. Ist deine Seite entsprechend auch Blitzschnell geladen?
      Ich will auf meinen Servern auch bald auf Nginx wechseln, noch ohne Varnish.

      Gruss Schroeffu

  • Martin Schlobach

    Hallo SCHROEFFU,

    das hier ist wirklich die beste Anleitung die ich zu diesem Thema „Umstellen von http zu https“ gefunden habe. Ich habe zwar erst ab Schritt 3 begonnen, da ich ein Serverseitiges Zertifikat habe, aber deine Anleitung war die einzige, die zu dem gewünschten Ergebnis geführt haben. Vielen Dank dafür!

    Martin

  • André

    Hallo! 🙂

    Die Umstellung eines WordPress‘ von http auf https könnte auch durch das Plugin „WP Migrate DB“ geschehen. Dieses Plugin nutze ich z. B. um mein Testwordpress mit den Inhalten der produktiven Seite zu befüllen.

    Das schöne an dem Plugin ist, dass es ein Suchen/Ersetzen anbietet. So könnte man von
    http://domain auf https://domain
    suchen und ersetzen lassen. Die Ersetzung findet beim Export der DB direkt statt.
    Anschließend wird ein tar.gz-File erstellt, dieses kann wieder (z. B. per phpmyadmin) importiert werden.

    Et voilà, WordPress hätte alle links auf https. 🙂

    Viele Grüße
    André

  • Jörg

    Danke für diese sehr gelungene Beschreibung. Hat mir schnell beim Umstellen auf https geholfen.
    Gruß Jörg Müller

  • Oliver Leu

    Danke dir vielmals! Meine Besucher sind jetzt auch sicherer auf meiner Website unterwegs! Die Umstellung verlief problemlos, hab‘ sie zuerst auf einer „unwichtigeren“ Website getestet. Werde jetzt dann noch dasselbe für die Websites meiner Frau machen.
    Wichtig ist es am Ende zu überprüfen, ob auch alle Applikationen ausserhalb von WP korrekt funktionieren und allenfalls dort noch den Schraubenzieher anzusetzen.

    Liebe Grüsse Oli

  • Michael

    Hallo! Wow ich habe gerade einen Blödsinn gemacht.
    Ich habe nicht fertig gelesen und gleich bei WordPress auf HTTPS umgestellt.
    Die Folge war dass nichts mehr ging und von mir Aleine nicht mehr Rückgängig gemacht werden konnte!
    Also Leute Finger weg wenn man keine Ahnung hat. Und das Kontrollkästchen aktivieren um den Testlauf zu starten. Das habe ich versäumt… Naja jetzt läufts zum Glück wieder!
    LG und Danke für den Ausführlichen Bericht

  • Jan

    Hi Schroeffu,
    „Übrigens: R=301 bedeutet «Permanent Redirect», also meinen wir es sehr ernst und Google wird die URLs schon bald im Index korrigieren.“
    -> wie lang denkst du denn wird „schon bald“ sein? Sollte ich mir schon Sorgen machen, wenn es nach 4 Tagen noch nicht bei allen URLs der Seite umgestellt wurde, oder soll ich mich noch ein wenig gedulden?

    • Schroeffu

      Hallo Jan,

      vier Tage dürften meiner Erfahrung nach zu knapp sein. Google verändert die Links von noch funktionierenden Seiten (auch wenn 301 Redirect vorhanden ist) gemächlich, während es 500er oder 400er HTTP-Codes inzwischen extrem schnell bereinigt. Vielleicht kannst du mal testen, und schauen ob ein neuer (Blog) Artikel nach 1-2 Tagen mit HTTPS verlinkt wurde – neue Posts sollten vorneherein mit HTTPs in den Index gehen.

  • Jan

    Danke! Neue Artikel gehen sofort mit https:// rein – ich werd mal weiterhin dran bleiben und das regelmäßig checken…