Der Firmenrechner flüsterleise, die Notebooks und mobilen Geräte machen auch keine Laute, der kleine Home-Server ist nur ganz dezent warzunehmen, aber der Desktop PC „brüllt“ durch den Raum – dabei ist es gar nicht mal so warm und wirklich was zu tun hat der Rechner auch nicht.

Laute Rechner sind ein allgemein bekanntes und gerne behobenes Problem und jetzt hab ich mich auch daran gemacht, weil mir die Kiste einfach auf den Geist gegangen ist und man auch beim normalen Fernsehen nicht einmal mehr den Rechner laufen lassen konnte, weil er einfach alles übertönt hat.
(mehr …)

Scheinbar hat mich gerade etwas der Zertifikat-Wahn überkommen.
Mit und mit werden alle vHosts auf HTTPS umgestellt – zusätzlich hab ich nun für zwei besondere Seiten eine Client-Zertifikat-Authentifizierung eingerichtet und unserem GitBlit-Server auch noch eins spendiert. Achja.. und HSTS ist nun auch an.

Aber alles wäre ohne die netten Blogger im Netz nicht möglich gewesen:

Der PHP-Gangsta hat mir bei der Client-Zertifikat-Authentifizierung mit seinem Blog sehr geholfen: PHP Gangsta – Client-Zertifikate als Login-Ersatz
Allerdings hab ich meine CA etwas anders aufgesetzt und auch aes256 anstatt des3 verwendet. Da die Maschine aber (sinnigerweise) eh aus ist, ist das alles halb so wild.

Zudem hat er mich inspiriert mal über HSTS nachzudenken und ein anderer Kollege hat die notwendigen Config-Zeilen für den Indianer geliefert:
Pregos – Blog – HSTS mit Apache

Und beim GitBlit hat ein englischsprachiger Kollege geholfen: PointUp.it – Certifikate in Gibtlit installieren. Allerdings muss das an manchen Stellen auch etwas angepasst werden. Ich hab hier ein paar Stunden dran vertan, bis alles so war, wie der Application-Server es haben wollte. Der Trick ist hier, dass auch die Intermediate-Zertifikate mit in dem pkcs12-Container drin sind, damit die Certificate-Chain komplett ist. Ich habe dies einfach über das PFX-Tool von StartCom erledigt, da dies auch brav die ganze Chain (vermutlich aber nur die eigene) hinzufügt.

Den dann über
keytool -importkeystore -srckeystore [vonStartCom.p12] -srcstoretype pkcs12 -destkeystore serverkeyStore.jks
keytool -list -keystore serverKeyStore.jks
keytool -changealias -keystore serverKeyStore.jks -alias "startcom pfx certificate" -destalias class2_2015


importiert und einen „netten“ Aliasnamen gegeben. Anschließend den Alias in der gitblit.properties eintragen, und schon rennt das neue Zertifikat.

Wenn ich jetzt noch herausfinde, wie ich den Gitblit auf HTTPS-Only respektive die entsprechende Weiterleitung umbiege.. dann bin ich glücklich!

Einmal i-MSCP geupdatet und schon neuer Ärger: Nach dem Update lief erst einmal wieder alles – zumindest größtenteils.

– Das neue Release 1.2.0 kommt ohne eine 00_master.conf für den Apachen. Das heißt: Beim Aufruf des Hostnamens landete man auf meiner (dieser) Seite. Blöd, weil das Zertifikat dafür sinnigerweise nicht ausgelegt ist.
– Ohne die 00_master.conf mochte auch das Plugin für DynDNS nicht mehr. Also ging das auch erstmal nicht mehr.

Abhilfe schafft eine selbstverfasste 00_master.conf die alles was „böse“ ist auf ne 404-Seite leitet (wohin auch sonst? 😉 ) und für die Webmail-User einen geeigneten Redirect bietet.
Nun geht auch, nachdem man die URL geändert hat, DDNS wieder. Alles tutti! Ich bin aber trotzdem gespannt, wann das Team um nuxwin ein Update mit den Fixes dazu herausbringt.

Da ich ja schonmal dabei war, hab ich direkt das Class2-Zertifikat eingespielt im Backend. Das ging übrigens auch ganz einfach. Gestern morgen kam die Mail von PayPal mit der Zahlungsaufforderung und kurze Zeit später (~ 2 Stunden) war ich Class2-Confirmed. Wie ich schon geschrieben habe: Einfacher geht’s kaum!

Achja.. die Telekom-Mätzchen: Es wird ja viel von „Sicherheit“ geredet. Die Telekom hat in den neuen Speedports einen eigenen Weg gefunden, dem Spam entgegen zu treten: „Liste sicherer E-Mail-Server“. IMAP-Traffice geht damit wunderbar, aber der Speedport unterbindet die Kommunikation über SMTP zu Servern, die nicht in der Liste stehen. Die Idee find ich ja super, nur warum steht da nirgendwo bei, dass man, wenn man mal einen vermeindlich „unbekannten“ Server nimmt, den von Hand eintragen muss? Das findet der Otto-Normaluser doch niemals! Vielleicht ist das auch nur eine kleine Masche des Magenta-Riesen um bei Twitter, Facebook und über das gute alte Telefon die Beschwerden entgegen zu nehmen, oder die Leute an die „großen“ Konzerne zu binden.

Ich glaub ich frag bei @telekom_hilft mal nach, wie man auf diese blöde Liste kommt 😀

PS:
Das Problem hat echt schon zu lustigen Foren-Diskussionen, und das sogar schon seit Anfang 2014 geführt. Super Telekom! http://bit.ly/1vG4GIF

Die Zertifikate für das Backend des Servers mit IMAP- und SMTP-Schnittstellen laufen bald aus. Um zukünftig Ärger zu vermeiden mit dem ständigen Anpassen des Hostnamens (statt „mail.example.com“ ist das Zertifikat nur auf den Hostnamen des Servers ausgestellt) hab ich mich dazu entschlossen eine Class 2 Validation bei StartCom durchzuführen.

Das ging in der Tat bisher ganz easy:

– Bei StartCom einloggen (oder anmelden..)
– Ausweisdokumente fotografieren / scannen
– Zahlungsmethode hinterlegen.

Nach wenigen Minuten kam eine Mail von den Jungs, wann sie mich unter der angegebenen Telefonnummer erreichen können – weitere Minuten später klingelte das Telefon und ich hatte einen Menschen von StartCom am Rohr. Er stellte mir ein paar Fragen, um sicherzugehen, dass ich das auch ich bin und sagte mir dann, dass ich in wenigen Minuten die „Zahlungsaufforderung“ bekäme.

Blöderweise hat bis gerade die Validierung meines PayPal-Kontos noch nicht geklappt. Woran das jetzt liegt, wüsste ich gerne.
Ich hoffe, dass im Laufe des Tages sich daran was ändert, sonst muss ich wohl doch meine Kreditkarte ausgraben.

Aber davon abgesehen, ist es nirgends einfacher und günstiger ein Class-2-Zertifikat zu bekommen. Und mit knapp 50 Euro geht das echt klar.
Ich bin mal gespannt, ob und wann das mit dem Geld über die Bühne geht.

Natürlich hat dieser Blog sein Zertifikat verdient – noch ist es ein Class 1 von StartCom wird aber ganz bald zum Class 2 geändert. Dazu gehört natürlich ein nach allen mir bekannten Regeln der Kunst abgesicherter Server um Heartbleed und Poodle und wie die ganzen netten Lücken heute benannt werden auch heißen mögen.

Am Theme wird sich auch noch Einiges ändern. Bis jetzt ist das nur eine Quick-and-Dirty-Lösung, aber lieber das als nichts 🙂

Nach dem Einspielen des Zertifikats und Aktivieren der Umleitung auf SSL ein erster kleiner Schock: Es sieht etwas zerwürfelt aus. Der Grund liegt natürlich auf der Hand: Wenn schon SSL, dann auch richtig. Firefox und Chrome mögen unverschlüsselten Content gar nicht – und das ist ja auch gut so. Also fix noch die Domain im WordPress-Backend geändert, die Seite neu geladen und der Chrome war glücklich. Nur der Firefox tat sich natürlich wieder schwer. Nach einigen harten Reloads war das ganze auch nicht besser, bis ich darauf kam, dass Cachify hier wohl noch eine kleine Rolle mitspielt: Cache geleert und auf der Fuchs ist wieder feurig glücklich. Und weiter geht’s 😉