So, als Teil des Wunsches doch vemehrt Verschlüsslung einzusetzen, ist jetzt das Blog SSL-verschlüsselt, sowohl http also auch https gehen. Es gibt hier zwar nichts wirklich schützenswertes, aber ich denke, dass jeder im Netz jetzt versuchen sollte soviel Kommunikation wie möglich zu verschlüsseln, egal wie unwichtig sie sein mag. Auch wenn es Gerüchte gibt, dass die Geheimdienste auch so einiges entschlüsseln können, sollte es doch ein Ziel sein, soviel Krypto-Rauschen zu erzeugen, dass evt. die Effektivität des Abhörens und Knackens runter geht. 

Technisch sind momentan zwei Punkte erwähnenswert:

Server Name Indication (SNI)

Da ich mehrere Sites auf diesem Server unter der gleichen IP hoste, kann ich eigentlich nur eine Domain verschlüsseln. Denn eigentlich wird die Verschlüsselung ausgehandelt bevor der Webserver weiss welche Site/Domain angefragt wurde. Server Name Indication (SNI) ist eine neuere Erweiterung und löst das Problem, so dass man mehre SSL-Zertifikate mit einer IP-Adresse hosten kann. Das einzige Problem ist jetzt nur, das Windows XP mit allen Internet Explorer Versionen das nicht kann. Und dann immer eine Fehlermeldung anzeigt ("There is a problem with this website's security certificate"), die man aber zumindestens wegklicken kann. Akzeptabel für mich.

Natürlich könnte man für alle Domains auf dem Server das gleiche Zertifikat (gerne auch Self-Signed) nutzen, aber dann würde viel mehr Browser Fehler anzeigen, und gerade der Firefox Dialog dürfte für DAUs Endstation sein. 

SNI einrichten ging supereinfach. Man muss einfach nur weitere Virtual Hosts mit eigenen Zertifikaten einrichten. Ich hätte mit größerem Aufwand gerechnet.

Grüne Browser-Adresszeile

Das andere Problem ist die gewünschte grüne oder auch gelbe (hauptsache "sicher") Browser-Adresszeile. Momentan kann ich die nicht bekommen, da der Blog leider "mixed content" hat, also sowohl verschlüsselten als auch unverschlüsselt Inhalt hat. An sich ist der Blog komplett "self-hosted", aber leider sind auch der Zählpixel der VG Wort und rechts der Kickstarter-Iframe eingebunden, und die sind beide unverschlüsselt. Kickstarter ist erstmal kein Problem, die können auch https, es ist nur Fleissarbeit alle URLs umzuschreiben. VG Wort ist ein anderes Problem. Die können momentan wohl kein https. Aber ich frag mal nach. Viel Hoffnung hab ich bei so einer Organisation aus dem letzten Jahrtausend ja nicht.  Da bleibt nur die Entscheidung "grüne Browserzeile" oder Zählpixel.

Ansonsten läuft evilazrael.de gerade mit einem kostenlosen 30-Tage Testzertifikat von Comodo. Ich hab gerade einen Anbieter gefunden der nur 5 USD/Jahr haben will. Da hab ich gerade eine Presales-Anfrage hingeschickt. Wenn die positiv zurück kommt, dann tausch ich das Zertifikat gegen ein richtiges aus. 

Nachtrag 07.08.2013

Eine Antwort von CheapSSLs.com habe ich zwar nicht bekommen, aber deren Comodo Zertifikate bieten zum Glück auch die Unterstützung für die Domain selber und das www. davor. Interessanterweise gehört CheapSSLs.com zu Namecheap, dort sind die gleichen CAs um einiges teurer. Für das Zertifikat selber wird 100% auf die Comodo Infrastruktur zurück gegriffen. Für ein 5-Jahres Zertifikat zahlt man nur 25USD (also 5USD/Jahr), was bislang das günstigste ist, was ich gefunden habe. 

Die Kickstarter iframes hab ich schon auf https umgebastelt, bleibt noch das VG Wort Problem. Bin mal gespannt, wann ich von denen eine Antwort kriege. 

Nachtrag 11.08.2013

CheapSSLs läuft einem wie ein kleines Hündchen nach und gibt noch mal 10% Rabatt mit dem Coupon-Code MissedYou. Boah, ich hasse Retargeting. 

Meine Lieblingshassdatenbank hat mich heute wieder geärgert. Auf der Arbeit hab ich gestern den Advantage Database Server (ADS) von 7.1 auf 8.1 geupdatet. Lief alles sauber. Heute wollte ich dann die PHP Installation upgraden, da mit dem neuen ADS auch PHP > 5.0 unterstützt wird.

Naja, angefangen, altes deinstalliert, PHP als ISAPI Modul installiert und phpinfo() Seite aufgerufen, kein Problem. ADS Modul für PHP installiert, phpinfo() aufgerufen, alles OK. Das Intranetportal aufgerufen und dann hing das Skript. Beim Verbinden zur DB hängte sich immer das Skript auf. Testweise PHP mal wieder als CGI installiert, gleiches Problem. Interessanterweise funktionierte das Skript an der Konsole tadellos mit dem gleichen PHP-Interpreter. Nach einigen Herumprobieren wollte ich dann das alte PHP mitsamt dem alten ADS Modul installieren, aber das lief auch nicht mehr.

Mittlerweile in Panik geraten (weil ich Depp das am Produktivsystem gemacht hatte), hab ich zeitweise sogar eine Apache Installation versucht, mit genau den gleichen Ergebnis : Weder als Modul noch als CGI lies sich keine Verbindung aufbauen, aber an der Konsole liefen genau die gleichen Exen ohne Probleme.
Dann wieder Umstieg auf IIS und dann kam der Durchbruch, beim Testen an der Konsole kam die Fehlermeldung das eine zum ADS gehörige DLL wohl zu alt wäre.. Die Vermutung lag da nahe, das vielleicht die Server und die Konsole andere Umgebungen definierten und evt. andere DLL-Suchreihenfolgen hatten. Mal alle alten DLLs auf der Kiste gesucht und gelöscht und zack lief alles wieder. Das war mal wieder ein schönes Beispiel für die DLL-Hell. Aber wieso PHP und die beiden Webserver keine Fehler oder Warnungen wo geloggt haben, das bleibt wohl ein Geheimnis...