XMPP/Jabber, jetzt aber richtig

Mein Jabber-Ser­ver (open­fire) hat­te ein selbst­si­gnier­tes Zer­ti­fi­kat, noch dazu im Okto­ber abge­lau­fen.
Und da Flo­ri­an einen Kon­takt auf jabber.ccc.de hat, der aber nicht ging, war es Zeit, das rich­tig zu machen.
Also habe ich mir einen CSR erzeugt und den bei startssl.com ein­ge­kippt. Die gaben mir dann freund­li­cher­wei­se ein Clas­s1-Zer­ti­fi­kat zurück — und nun begann der Kampf. Open­fire ist java, und das hat für das gesam­te Key­ma­nage­ment ein Drecks­tool namens key­tool. Nach Stun­den habe ich es dann doch hin­be­kom­men, die Zer­ti­fi­ka­te ein­zu­bau­en.

Man benö­tigt das Zer­ti­fi­kat natür­lich, dazu noch das Zwi­schen­zer­ti­fi­kat von starts­sl, das es hier gibt.
Wir wech­seln nach /opt/openfire/resources/security.
Dann wer­den die bei­den Zer­ti­fi­ka­te zusam­men­ge­wor­fen:

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: key­tool kann zwar PEM-Zer­ti­fi­ka­te impor­tie­ren, aber kei­ne pri­va­ten Keys. Also muß ein Bund­le aus den bei­den Zer­ti­fi­ka­ten und dem pri­va­ten Key im PKCS#12-Format erzeugt wer­den, dafür neh­me ich opens­sl:

openssl pkcs12 -export -in xmpp.pem -inkey /etc/ssl/private/xmpp.sokoll.com.startssl.key -out xmpp.p12

Den alten keysto­re habe ich ein­fach mit rm keysto­re weg­ge­wor­fen.
Nun kön­nen wir auch einen neu­en keysto­re mit pri­va­tem Key und den bei­den Zer­ti­fi­ka­ten erzeu­gen:

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 mei­nem keysto­re lau­tet “chang­eit”, falls jemand das braucht 😉
Open­fire neu­star­ten, die neu­en Zer­ti­fi­ka­te soll­ten in der Admin-UI auf­tau­chen.

Soweit, so gut, gleich mal nach­se­hen, wie das von außen aus­sieht. So. viel grün, könn­te aber grü­ner sein 🙂 Das “Warning: Ser­ver allows RC4 when using TLS 1.1 and/or TLS 1.2. Gra­de cap­ped to A-.” stört aber. RC4 will man mei­nes Wis­sens nicht. Und SSLv3 will man nach Pood­le auch nicht, wenn auch das für XMPP irrele­vant sein dürf­te.
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 ein­fach ein jdk.tls.disabledAlgorithms=RC4, MD5, SHA1, DSA, RSA key­Si­ze < 2048 dran­ge­pappt, und ja, es sieht bes­ser aus.
Aller­dings sieht es so gut aus, daß mein Cli­ent (Jit­si) sich nicht mehr ver­bin­den mag — wahr­schein­lich wegen des feh­len­den TLSv1.1.
Für Tipps, wie ich das hin­ein­be­kom­me, aber ohne SSLv3, bin ich dank­bar.

0

5 Comments

Add a Comment
  1. Ich mana­ge mei­ne Java-Keysto­res mit Por­te­cle.

    0
    1. Das ist doch ne GUI. Sowas kommt mir nicht auf den Ser­ver 😉

      0
      1. Tja, dann halt doch Drecks­tool. Hilft­ja­nüscht.

        0
  2. Viel­leicht doch bes­ser Pro­so­dy ein­set­zen. Lässt sich ein­fach admi­nis­trie­ren und geht ohne Java-Krams.

    0
  3. Nach eini­gem Krampf: Bei der letz­ten Aktua­li­sie­rung hat Start­Com ein fal­sches Inter­me­dia­te-Zer­ti­fi­kat mit­ge­schickt (für Class 2 anstel­le von Class1)
    Man muß dar­auf ach­ten, daß der CN im Inter­me­dia­te iden­tisch zum Issu­er beim Ser­ver-Zer­ti­fi­kat ist.
    Das Inter­me­dia­te habe ich mir dann ein­fach ergoo­gelt.
    Client2Server: https://xmpp.net/result.php?id=103604
    Server2Server: https://xmpp.net/result.php?id=103571

    0

Schreibe einen Kommentar

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