HTTPS Umstellung des Blogs

HTTPS muss heute sein, die Datenschützer werden ganz hellhörig, wenn Daten (zum Beispiel aus dem Kontaktformular) im  Klartext übertragen werden. Also ran an das Thema HTTPS Umstellung.

Das ist zwar bei so einem Privatblog nicht so dramatisch, aber wie schnell wird so ein Blog auch mal professionell genutzt, und schon darf man mit Abmahnungen rechnen.

Außerdem macht das nach außen inzwischen schon einen seltsamen Eindruck, wenn die Seiten im Browser als unsicher oder gefährlich angesehen werden.

Und da es hier mein Spielblog ist, hab ich es einfach mal probiert. Und siehe da, es war sehr viel einfacher als befürchtet.

6 Schritte führen hier zum  Erfolg:

(I) Das Zertifikat
Let’s Encrypt sei Dank (https://letsencrypt.org/). Sie können hier ein kostenloses Zertifikat bekommen. Außerdem wird „letsencrypt“ inzwischen von vielen Hostern implizit unterstützt. Ich habe das Glück, dass mein Provider eine direkte Let‘s Encrypt Anbindung ermöglicht. Eine Anmeldung im cPanel und Aktivierung eines Zertifikates von Let’s Encrypt und serverseitig ist schon alles erledigt.

Wird das nicht direkt vom Provider unterstützt, kann man sich dort auch manuell ein Zertifikat besorgen, und muss dann mit dem Provider klären, wie man es aktiviert.

Das ist dann etwas unschön, vor allem weil diese Zertifikate nur 3 Monate gültig sind, danach müssen sie verlängert werden. Macht man es manuell, so muss man auf jeden Fall selbst daran denken, macht es der Provider, so ist es evtl. eine automatische Geschichte (hoffe ich). Ich werde in 3 Monaten mal prüfen was passiert.

Diese Zertifikate erlauben eine gesicherte Verschlüsselung, aber nicht mehr. Unternehmen wie Paypal oder ähnlich Große erscheinen in den Browsern oft mit grünem Firmennamen. Wenn man so etwas will, benötigt man kostenpflichtige Zertifikate mit Organisationsvalidierung (OV) oder erweiterter Validierung (EV). Das ist aber für den Privatgebrauch nicht notwendig, da reicht die simple Verschlüsselung völlig.

(II) Die WP Config

Wenn man möchte, so kann man in der wp_config den Eintrag

define(‚FORCE_SSL_ADMIN‘, true)

einbauen. Dieser erzwingt https für die Blog-Administration. Dies auch ohne die nachfolgenden Maßnahmen. Ich hab es nur zu Testzwecken mal probiert, um zu sehen, dass Zertifkate etc. korrekt sind, dann habe ich es wieder deaktiviert, weil ich die ganze Seite (und nicht nur den Admin-Part) forciert auf https betreiben will. Dazu später mehr.

(III) Und wieder Migration

Nun ist wieder DB Migrate dran. Ich habe damit nur die Links innerhalb des Blogs von http auf https umgestellt, also „http://UweSprenger“ nach „https://UweSprenger“ verändert. Ich habe keine generelle Umstellung „http:“ nach „https:“ vorgenommen und rate auch davon ab, näheres dazu unter Punkt (V).

(IV) Und wieder htaccess

Die Zwangsumleitung auf http kann in der htaccess kann mit den folgenden Einträgen erreicht werden.

RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Und wenn in anderen Umleitungen der htaccess noch http Verwendung findet, so sollte das gleich auf https geändert werden, sonst wird einmal mehr „redirected“. Das betrifft zum Beispiel den Eintrag, der meine Domainänderung begleitet hat. Siehe dazu  hier:

https://uwesprenger.de/wordpress-domain-aendern/

Erst wenn es keine Möglichkeit mehr gibt, das Blog mit http zu nutzen, ist die HTTPS Umstellung wirklich erfolgt.

Nachsatz: Man findet auch Empfehlungen die Rule

RewriteCond %{HTTPS} !=on

zu verwenden. Darauf bin ich hereingefallen, weil sie richtig aussieht, aber so nicht funktioniert. Die Negierung ist ausschliesslich „!“ und nicht „!=“. Richtig wäre:

RewriteCond %{HTTPS} !on

Wie man solche Fehlerchen identifizieren kann, hab ich ja schon im vorigen Beitrag erwähnt: WordPress Multisite Migration.

(V) Und nun kommt die Frickelei:

Also theoretisch ist man jetzt fertig, wenn man sehr viel Glück hat, praktisch aber nicht.

Es wird so sein, dass in euren Seiten Ressourcen von außerhalb geladen werden. Zum Beispiel Bilder, Videos oder Scripte, die über einfaches http referiert sind. Das führt zu dem sog. „mixed content“ Problem, auf das die Browser unschön reagieren:

Manche fragen nach, ob auch „unsichere Inhalte“ dargestellt werden sollen, manche weisen nur darauf hin, andere lehnen den unsicheren Inhalt komplett ab. Das hängt vom Browser und den Sicherheitseinstellungen ab.

Das kann auch dazu führen, dass Teile des Layouts nicht mehr stimmen, Bullets oder kleine Bildchen, die von außen geladen werden und plötzlich nicht mehr da sind.

Diese Quellen für den „mixed content“ muss man nun aufspüren und eliminieren.

Zur Sucher ruft man die Webseiten so nacheinander  im Browser auf und switched in den DEBUG Mode (Rechte Maus/Element untersuchen o,ä.). Unter Konsole findet man dann die Warnhinweise auf solche Stellen mit ihren konkreten Quellen.

Das können dann sein:

  • PHP Code aus Plugins, die einen Aufruf auf Skripte mit http statt mit https beinhalten
  • Stylesheets, die Bilderchen oder Fonts (Google Fonts) mit http einbinden.
  • Bei mir bin ich auf eine Referenz zu den Google Fonts gestoßen, die ich deaktiviert habe, weil im entsprechenden Plugin der für meinen Anwendungsfall nicht notwendig war. (Ist auch aus DSGVO Themen anzuraten).
  • Auch ein kleines Overlay-Bild aus einem Youtube Code hatte ich noch per http eingebunden, Youtube funktioniert aber auch problemlos mit https.
  • Selbst konfigurierte Inhaltesind ebenfalls möglich. Auf meiner Webseite läuft ein kleiner Slider in der Sidebar, da habe ich ein Webcam-Bild eingebunden, welches leider nicht über https erreichbar war.

Stößt  ihr auf solche Stellen, so habt ihr folgende Handlungsalternativen

  • Prüfen ob ihr das betroffene Plugin noch braucht, vielleicht ist es unnötig, veraltet, vielleicht gibt es bessere und gepflegtere
  • Prüfen ob eine einfache Anpassung des Links auf „https“ funktioniert
  • Es einfach drin lassen 🙁

Das „drin“ zu lassen ist aus meiner Sicht aber keine Alternative. Es verunsichert Anwender der Seite, wenn der Browser von unsicheren Inhalten o.ä. spricht oder wenn immer wieder eine Intervention des Anwenders nötig ist, um die Seite anzuzeigen. Mit etwas Phantasie findet man sicher einen Workaround für das Problem.

Übrigens betreffen diese Probleme nicht reine http links zu anderen Seiten, da diese erst einmal keine Fremdressourcen in eure Seite laden. Daher auch mein Rat, unter 3. nicht generell alle http Aufrufe auf https zu ändern. Man weiß nie, ob die referierten Seiten überhaupt https unterstützen.

Wenn man auf diese Weise so durch seine Seiten geht und diese prüft, findet man bei der Gelegenheit evtl. auch mal den einen oder anderen Java-Script Fehler. Und kann ihn gleich mit beheben.

Ich habe in einem Lightbox-Plugin einen solchen gefunden, der wiederum indirekt dazu führte, dass Yoast SEO nicht mehr funktionierte. (ein Problem an dem ich schon einen halben Tag gesucht hatte).

Nun ist euer Blog wirklich HTTPS Ready, die HTTPS-Umstellung komplett.

(VI) Abschluss der Aktion

Es ist jetzt an der Zeit auch die Suchmaschinen  (z.B. GoogleSearch Konsole) über die neuen Adressen (mit https) zu informieren. Einfach eine neue Property  mit neuer Sitemap eintragen und es sollte nicht mehr allzu lange dauern, bis Google eure neuen Namen in den Ergebnissen ausweist.

Wenn alles getan ist, kann das WP DB Migrate Plugin auch wieder deinstalliert werden. Es sein denn, ihr macht ständig Domain Umzüge 🙂

 

Bookmark the permalink.

About Uwe Sprenger

Uwe Sprenger ist ein IT Generalist, der in seiner Freizeit immer gerne neue Möglichkeiten ausprobiert. Und so ist hier dieses Blog zu Wordpress im entstehen. Beruflich bin ich (zur Zeit) intensiv im Lizenz Management unterwegs.  

Schreibe einen Kommentar

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

3 × 5 =