HTTPS mit Umwegen

So, dieser Blog ist jetzt auch vollständig per HTTPS erreichbar, dank eines kleinen „Schubses“ von Google.

Aber der Reihe nach: Vor einiger Zeit hatte ich ein wenig am Blog umgebaut (es gibt auch seitdem ein neues Theme, falls das noch niemanden aufgefallen sein sollte…) und dabei ein paar Links kaputt gemacht. (Ok, alle Links). Freundlicherweise bekam ich kurz darauf eine Mail von Google, auf meiner Website wäre die Anzahl der 404s ein bisschen angestiegen. Der Fehler war schnell gefunden, und die meisten Links waren wieder heile. Ein paar waren immer noch kaputt, was an dem Theme-Wechsel lag, aber auch die hatte ich recht schnell repariert. Und dann sah es so in der Search Console aus:2016-08-09-21_32_12-search-console-dashboard-http___niklas-rother-de_Irgendwie brach der Traffic von Google „etwas“ ein. Auch Piwik zeigte das gleiche Problem: (Zeigt auch schön, wie viel Traffic von Google kommt…)2016-09-22-23_04_19-niklas-rother-computer-mehr-woche-19-25-september-2016-webanalytik-berDer erste Knick nach unten waren die komplett kaputten Links, dann kam der Zeitraum wo einige Links kaputt waren. Der komplette Absturz passierte, als ich alle Links repariert hatte, und die Reparatur in der Search Console von Google auch bestätigt hatte. Jetzt war ich verwirrt. Alle Links waren in Ordnung und Google wirft mich aus dem Index?! Erst dachte ich, das wäre vielleicht nur ein temporäres Problem weil Google die Seite neu indexieren müsste, aber es wurde nicht besser. Laut Google war auch alles in Ordnung.

Was war passiert? Wie bei allen gemeinen Fehlern eine Kombination von mehreren Ursachen. Erstes Problem: Google unterscheidet streng nach URL, man muss in der Search Console mindestens vier Varianten der URL hinzufügen, wenn man alle „typischen“ Kombinationen haben will: HTTP/HTTPS sowie mit und ohne „www“. Heute habe ich dann gemerkt, das ich sehr wohl noch Traffic von Google bekommen habe, aber auf die HTTPS-Seite! Scheinbar hat Google durch das neu-indexieren spitz gekriegt, dass ich hier mehr oder weniger aus Spaß mal ein Let’s Encrypt Zertifikat installiert hatte (automatisch, über netcup), und hat die Besucher auf die sichere Variante geschickt. An sich natürlich lobenswert. Dort sind also schon mal die Besucher geblieben. Glück gehabt, doch nicht aus dem Index geflogen *phew*.

Nachdem also alle Welt außer mir meine Seite über SSL aufruft, habe ich mir die Seite auch selber mal angeschaut, und dabei leider eine der beliebten „mixed-content“ Warnungen bekommen. Die Seite selber wurde über SSL ausgeliefert, aber leider waren die Bilder über HTTP verlinkt. So weit ich das sehe, speichert WordPress leider die komplette URL im Quelltext des Beitrags, und nicht nur einen relativen Link. Diesen Post schreibe ich jetzt über SSL, daher landen hier auch die richtigen Links drin, aber die alten Posts enthalten alle noch die HTTP-URLs. Im Prinzip ist es recht einfach, das in der Datenbank direkt mit ein paar SQL-Anfragen zu ändern, allerdings scheint WordPress da noch ein paar Querverweise drin zu haben, die mir etwas unklar waren, so dass ich da nicht dran rumspielen wollte. Aber natürlich gibt es auch für dieses Problem ein Plugin, in diesem Fall „SSL Insecure Content Fixer„. Ich musste den Modus dort auf „Content“ stellen, jetzt wird vermutlich der Inhalt jedes Posts per RegEx repariert. Nicht schön, aber effektiv 🙂 So, damit sind die Warnungen weg, und wir haben ein Schloss in der Adressleiste!

Bleibt noch die Frage, warum auch Piwik das Wegbleiben der Besucher anzeigte. Die Besucher waren ja doch da, sie kamen ja nur per HTTPS, und eigentlich sollte Piwik ja auch per HTTPS funktionieren, oder? Zeit für etwas Debugging. Zuerst war ich ein wenig erstaunt, und hatte das Gefühl, es würde gar nicht mehr funktionieren, bis mir aufgefallen ist, das meine Besuche natürlich nicht gezählt werden. Also schnell den Internet Explorer rausgekramt, damit zähle ich als „anonym“ 🙂 Dort zeigte sich das Verhalten, was ich schon befürchtet hatte: Über HTTP funktioniert Piwik, über HTTPS nicht. Daher also der Schwund an Besuchern genau in dem Moment wo Google auf HTTPS umgestellt hat. Leider wollte mir der Internet Explorer auch nicht direkt verraten, warum er das Skript nicht laden wollte… Das Problem war aber schnell gefunden: Piwik ist in einem Subdomain installiert (stats.niklas-rother.de), und leider gilt das Let’s Encrypt Zertifikat nicht für Subdomains! Hier könnte netcup durchaus mal nachbessern, im Prinzip ist das nämlich durchaus machbar, man muss nur alle Subdomains bei der Beantragung mit angeben. Hier müssen sie ihr Tool verbessern, laut Forum haben sie das aber auch schon auf dem Schirm.

Wie also dieses Problem lösen? Man könnte natürlich das Tracking-Skript immer per HTTP laden, aber dann kriegt man vermutlich wieder Warnungen, und schön ist das ja auch nicht. Ein Zertifikat für die Subdomain bekomme ich auch nicht so schnell. Die Lösung: Ein Symlink 🙂 Einfach unter /httpdocs einen Link /httpdocs/stats -> ../httpdocs_stats angelegt, und schon die die Piwik-Installation (auch) über niklas-rother.de/stats erreichbar, und damit gilt das Zertifikat. Diese URL ist jetzt bei WP-Piwik eingetragen, und damit funktioniert alles!

Was lernen wir daraus? 1. „Einfach so“, ungetestet HTTPS aktivieren ist keine so tolle Idee, irgendjemand könnte auf die Idee kommen, Links darauf zu setzen. Und wenn dieser jemand Google ist, sollten die Links funktionieren. Nebenbei: Genau das gleiche Problem hatte ich bei meiner Arbeit bei uniKIK, wo ich aus Spaß auch mal ein Zertifikat installiert hatte, aber ohne automatische Verlängerung. Natürlich hat jemand anders (in dem Fall ein Mensch) angefangen einen Link darauf zu setzen, und als das Zertifikat abgelaufen war, ging der Ärger los 🙁 2. (Zeitliche) Korrelation muss keine Kausalität implizieren. 🙂

Schreibe einen Kommentar

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