Mein holpriger Weg zum sicheren Weblog. SSL-Zertifikat und damit auch https wird immer aktueller. Da ich mein Weblog auf einem eigenen Server zu Hause betreibe, machte ich mir schon seit einiger Zeit Gedanken, auch mal gelegentlich ein SSL-Zertifikat für mein Weblog zu erhalten. Ich nehme zwar nicht an, dass sich irgend jemand da draussen viel davon verspricht, mein Weblog zu klonen oder sonst wie zu missbrauchen und so vielleicht ungerechtfertigt an Kreditkartennummern, Passwörter oder gar Geld zu gelangen. Es ging mir eher darum, nicht gelegentlich als unseriöses Weblog von den gängigen Browsern übergangen zu werden. Zudem beruhigt es ja nicht nur den Besucher, wenn die Adresszeile im Browser grün aufleuchtet (oder wenigstens Teile davon).

Ausgangslage:

• Ein Link, welchen ich bei Google+ auf mein Weblog gesetzt hatte, wollte einfach nicht verlinken. Nicht nur vom Browser “Chrome” aus dem Hause Google, auch der Internetexplorer (Edge) von Microsoft wollte nicht auf das Weblog verlinken. Warum, weiss ich bis heute nicht, habe ich nicht herausgefunden. Andere Links auf das gleiche Posting, zum Beispiel bei Facebook oder Twitter, wurden anstandslos weiter geleitet und das Posting zeigte sich im Browser.
• Ein Check bei SSLLABS ergab für mein Weblog das Rating “T”, T wie Trash, oder Abfall

Ab dann war mein Interesse zur Lösung dieses Problems geweckt. Auch dieser eine Link bei Google+ sollte anstandslos gelesen werden können und das Rating wollte ich unbedingt aus dem Abfallkübel holen.

Die Suche nach dem Weg:

• Doch welches Zertifikat brauche ich überhaupt? Was sind die Preise? Wer bietet was an? Das Angebot ist erst einmal unüberschaubar. Diverseste Leistungen und Angebote, die Preisspanne von fast Null bis fast unendlich.
• Mein Synology – Server kann die Ausstellung eines Gratis-Zertifikates von Letsencrypt anstossen und importieren. Alles automatisch. Hat aber leider nicht den erhofften Erfolg gebracht.
• Nach viel Surfen im www, Vergleichen von Angeboten, Studium von vielen Erklärungen entscheide ich mich für ein Zertifikat, alleine für die Domaine “als-aargauer-unterwegs.ch”, ausgestellt von SwissSign und verkauft von der PSW-Group.
• Die Zertifikatsanforderung (CSR, Certificate Signing Request) stellt mir meine Synology-Software bereit. 

Die Zertifikatsanforderung kann ich in einem Onlineformular an die PSW-Group übermitteln, zusammen mit einer Kopie meiner ID-Karte und einer geschwärzten Kopie des Elektrizitätswerkes (Industrielle Betriebe) an meine Adresse. Damit wird überprüft, dass “ich, ich” bin, dass es die Adresse wirklich gibt und diese auch mit dem Whois-Eintrag der Domaine übereinstimmt. Nach der Prüfung dieser Eingabe erhalte ich von SwissSign einen Link für den Download des Zertifikates. Diesen Link muss ich nach Erhalt eines E-Mails auf die Domaine “als-aargauer-unterwegs.ch” zuerst aber noch validieren. Das Zertifikat kann ich dann mit der Software auf meinem Synology importieren. In meinem Falle bestand das Zertifikat allerdings aus mehreren Dateien, teils im Codeformat “ANSI”, teils “UNICODE” andere im “UTF”-Format. Der Synology-Server akzeptiert aber nur UTF-Format. Nur Umformatieren half nichts. Die Dateien mussten auch noch anders zusammengesetzt werden. Da stand mir der Support der PSW-Group via TeamViewer bei. Die Domaine “als-aargauer-unterwegs.ch” war nach wenigen Klicks auf das neu erworbene Zertifikat zugewiesen.

Ein erster Klick auf den “verursachenden” Link bei Google+ zeigte tatsächlich das begehrte “https://” in der Browser-Zeile. Zwar nicht grün, aber das kann ja höchstens noch an einer fehlenden Umleitung auf dem Server liegen. Alles paletti.

Paletti?

• je länger ich zuwartete, desto schlimmer sah das Weblog aus. Zerschossen, fehlerhaft, das “https:” durchgestrichen, feuerrot, “unsicher” stand da. 
• Ich hatte sowieso vor, WordPress, die Software hinter diesem Weblog, wieder mal auf den neuesten Stand zu bringen. Also die Seite vom Netz genommen und dafür die “Unterhaltsseite” eingeschaltet.
• In den allgemeinen Einstellungen das “https” vor die Domaine gestellt. 
• Update von WordPress und den Plugins
• Da waren noch die Links in den Postings, welche fix mit der Domaine verknüpft sind. Vor allem Links auf die Bilder, alle mit http:, mit dem Plugin “Better Search Replace” geändert auf https:
• Wie ich dann bei Test’s herausfand, hat dieses Plugin allerdings nur die ersten 3000 Links geändert. Ein anderes Plugin “Search and Replace” war da weniger zimperlich, änderte 1000e weiterer Links in den Postings, aber auch in Tabellen, angelegt von weiteren Plugins, wie zum Beispiel MapPress.
• Ein weiterer Test der Seite sah schon mal viel besser aus.

Grüner Balken

Leider geht es weiter:

• Doch schon am nächsten Morgen, war die Seite wieder zerschossen, https: zwar nicht mehr rot und nicht mehr durchgestrichen, aber dennoch, das Weblog kaum lesbar.
• Die Fehlerliste die der Chrome auf Verlangen (F12) ausspuckt, ohne Ende. Viele Warnungen dazwischen.
• Es war eines der Plugins (Contextual Related Posts) welches ein Verzeichnis von ähnlichen Postings an das aktuelle Posting hängt, legt sich einen eigenen Cache an. Den hatte ich beim “Search and Replace” übersehen.
• Dann waren da noch die Widgets, die kleinen Anzeigen am rechten Rand. Immer wieder werden da “Applikationen aus unsicheren Quellen” wie das der Chrome nennt aufgerufen. Schlussendlich und ein bisschen schweren Herzens, muss ich mich dazu entscheiden, die Anzeige von Strava über die letzten Fahrten zu entfernen. 
• Auch die Anzeige von GPSies, es ist zwar nur ein Bild, muss weg.
• Ein weiterer Test sieht wieder gut aus

Die ganz hartnäckigen Fälle:

• Nochmals schlägt das “Contextual Related Posts”- Plugin zu. Ich habe ihm seine eigene Cache-Verwaltung abgestellt.
• Für ganz hartnäckige Fälle habe ich nun auch in der .htaccess – Datei eine Umleitung eingebaut, dass einfach alle Anfragen für meine Domaine auf https:// umgeleitet werden. 
• Das Formular mit dem “Captcha” – Modul machte noch Probleme. Das habe ich jetzt einfach zu “Ich über mich” umgehängt. 

Ein weiterer Test bei SSLLAB vergibt jetzt meinem Weblog immerhin ein Rating von “A”. Besser geht fast gar nicht. 

Rating_A

Performance:

Mit der Umstellung auf “https:” lädt das Weblog spürbar langsamer. Damit musste ich auch rechnen, davon schreiben auch andere im “www”. Der Synology-Server bietet da zwar Möglichkeiten an, das https-Protokoll schneller zu verarbeiten. Das habe ich natürlich angehakt. Ebenfalls das Plugin in WordPress, das “W3-Total-Cache” habe ich versucht besser und abgestimmter einzustellen. Wie ich meine, ist mir dies nicht schlecht gelungen. Das konnte ich bei GTmetrix prüfen und gleich einen 20-seitigen Bericht mit Verbesserungsvorschlägen dazu erhalten. 

Performance

Fazit:

• Auch jetzt wird es noch einzelne Seiten im Weblog haben, die aus Sicht Chrome-Browser kein grünes Schlösschen verdienen. Es sind dies Seiten, bei denen ich die Bilder zum Beispiel bei “flickr” gespeichert habe und von dort anzeigen lasse. In der Regel sind das Bilder aus der Anfangszeit dieses Weblogs. Der Link zu “flickr” ist ein http: – Link, also ein unsicherer Link.
• Künftig werde ich wohl viel vorsichtiger sein, mit der Anzeige von Bildern oder gar Scripten aus fremden Domaines. Zum Beispiel der Link zum Winterpokal von Rennrad-news, dürfte im nächsten Winter hier wohl fehlen. Schon genannt habe ich die Anzeige meiner letzten Fahrten bei Strava, auch diese werden bis auf weiteres hier fehlen. 
• In dem Performancetest des Servers werden oftmals meine “schweren” Bilder bemängelt. Es macht ja schon keinen Sinn, fünf und mehr MB über die Leitung zu schicken, um ein Bild in den Abmessungen von maximal 800×600 Pixels anzuzeigen. Da werde ich künftig wohl schon von Anfang an, die Bilder massiv verkleinern.

Auch wenn die Umstellung von http: auf https: deutlich länger als 10 Minuten dauerte, wie das vielerorts versprochen wird, so habe ich in den letzten Tagen viel gelernt bezüglich der Zertifikate, dem Server, dem Zusammenspiel von WordPress, der Plugins und der dahinterstehenden Datenbank. 

Dieses Weblog am 14.09.