Mein Jabber-Server (openfire) hatte ein selbstsigniertes Zertifikat, noch dazu im Oktober abgelaufen.
Und da Florian einen Kontakt auf jabber.ccc.de hat, der aber nicht ging, war es Zeit, das richtig zu machen.
Also habe ich mir einen CSR erzeugt und den bei startssl.com eingekippt. Die gaben mir dann freundlicherweise ein Class1-Zertifikat zurück — und nun begann der Kampf. Openfire ist java, und das hat für das gesamte Keymanagement ein Dreckstool namens keytool. Nach Stunden habe ich es dann doch hinbekommen, die Zertifikate einzubauen.
Man benötigt das Zertifikat natürlich, dazu noch das Zwischenzertifikat von startssl, das es hier gibt.
Wir wechseln nach /opt/openfire/resources/security.
Dann werden die beiden Zertifikate zusammengeworfen:
cat /etc/ssl/private/xmpp.sokoll.com.startssl.crt /etc/ssl/private/sub.class1.server.ca.pem > xmpp.pem
Und jetzt kommt der große Trick: keytool kann zwar PEM-Zertifikate importieren, aber keine privaten Keys. Also muß ein Bundle aus den beiden Zertifikaten und dem privaten Key im PKCS#12-Format erzeugt werden, dafür nehme ich openssl:
openssl pkcs12 -export -in xmpp.pem -inkey /etc/ssl/private/xmpp.sokoll.com.startssl.key -out xmpp.p12
Den alten keystore habe ich einfach mit rm keystore weggeworfen.
Nun können wir auch einen neuen keystore mit privatem Key und den beiden Zertifikaten erzeugen:
keytool -importkeystore -deststorepass changeit -destkeypass changeit -srckeystore xmpp.p12 -srcstoretype PKCS12 -srcstorepass changeit -srcalias 1 -destalias sokoll.com -destkeystore keystore
Ja, das Paßwort zu meinem keystore lautet “changeit”, falls jemand das braucht 😉
Openfire neustarten, die neuen Zertifikate sollten in der Admin-UI auftauchen.
Soweit, so gut, gleich mal nachsehen, wie das von außen aussieht. So. viel grün, könnte aber grüner sein 🙂 Das “Warning: Server allows RC4 when using TLS 1.1 and/or TLS 1.2. Grade capped to A-.” stört aber. RC4 will man meines Wissens nicht. Und SSLv3 will man nach Poodle auch nicht, wenn auch das für XMPP irrelevant sein dürfte.
Doch wo stellt man das aus? Hm, in der JRE, bei mir in /usr/lib64/jvm/java‑1.7.0‑openjdk‑1.7.0/jre/lib/security/java.security. Ich habe ans Ende einfach ein jdk.tls.disabledAlgorithms=RC4, MD5, SHA1, DSA, RSA keySize < 2048 drangepappt, und ja, es sieht besser aus.
Allerdings sieht es so gut aus, daß mein Client (Jitsi) sich nicht mehr verbinden mag — wahrscheinlich wegen des fehlenden TLSv1.1.
Für Tipps, wie ich das hineinbekomme, aber ohne SSLv3, bin ich dankbar.
Ich manage meine Java-Keystores mit Portecle.
Das ist doch ne GUI. Sowas kommt mir nicht auf den Server 😉
Tja, dann halt doch Dreckstool. Hilftjanüscht.
Vielleicht doch besser Prosody einsetzen. Lässt sich einfach administrieren und geht ohne Java-Krams.
Nach einigem Krampf: Bei der letzten Aktualisierung hat StartCom ein falsches Intermediate-Zertifikat mitgeschickt (für Class 2 anstelle von Class1)
Man muß darauf achten, daß der CN im Intermediate identisch zum Issuer beim Server-Zertifikat ist.
Das Intermediate habe ich mir dann einfach ergoogelt.
Client2Server: https://xmpp.net/result.php?id=103604
Server2Server: https://xmpp.net/result.php?id=103571