XMPP certificates + Openfire 3.5.1 = no go?

Openfire Openfire Support
21

Hey Gato,

In that case we found the root problem. The certificate needs to be regenerated so that the XMPP extension (ie subjectAltName) matches your XMPP domain.

Indeed – I’m waiting for that at the moment; seems nobody ever tried using the XMPP.net generated certificates on a subdomain before.

All in all though, it did bring some other things to light as well about the certificate manager and/or handling of fallback (like multiple CN’s). Thanks for your support and help here, and bearing with me.

Mark.

22

Hey Mark,

Sure thing. Your case was a good opportunity for improving Openfire and possibly the certificate generation for subdomains by the CA.

Thanks,

– Gato

23

forgive me for not taking the 30 minutes to read this entire thread in-depth, but it sounds like this problem might have been identified (when detailing openfire’s ssl cert validation logic) and a solution proposed in this post to openfire-dev 4 months ago.

just curious because i believe that other post might have been overlooked as there was never any reply to it or acknowledgment of it.

Message was edited by: unlisted to fix cut & paste link error as pointed out by wolfbeest

24

I think you meant http://www.igniterealtime.org/community/thread/31512 ?

25

Hi Gato,

I’ve been working with Peter and Eddy to get the ICA routine to spit out the correct extensions; I’ve got my cert re-issued with the correct jabber server domain in the extensions, and Openfire doesn’t complain anymore – Success!.. or… not?

Looking at S2S - things were still not encrypted.

Enabling debug, making sure certificate verification was off as well (to exclude a trust problem while negotiating TLS), I got the following output, trying 2 different remote servers:

2008.06.17 19:10:29 LocalOutgoingServerSession: OS - Trying to connect to jabber.anywise.com:5269(DNS lookup: jabber.anywise.com:5269)

2008.06.17 19:10:29 LocalOutgoingServerSession: OS - Plain connection to jabber.anywise.com:5269 successful

2008.06.17 19:10:29 LocalOutgoingServerSession: OS - Indicating we want TLS to jabber.anywise.com

2008.06.17 19:10:29 LocalOutgoingServerSession: OS - Negotiating TLS with jabber.anywise.com

2008.06.17 19:10:30 LocalOutgoingServerSession: OS - TLS negotiation with jabber.anywise.com was successful

2008.06.17 19:10:30 LocalOutgoingServerSession: OS - Error, no SASL mechanisms were offered by jabber.anywise.com

2008.06.17 19:10:30 LocalOutgoingServerSession: OS - Going to try connecting using server dialback with: jabber.anywise.com

2008.06.17 19:10:30 ServerDialback: OS - Trying to connect to jabber.anywise.com:5269(DNS lookup: jabber.anywise.com:5269)

2008.06.17 19:10:30 ServerDialback: OS - Connection to jabber.anywise.com:5269 successful

2008.06.17 19:10:30 ServerDialback: OS - Sent dialback key to host: jabber.anywise.com id: 3344141079 from domain: jabber.wolfbeast.com

2008.06.17 19:10:30 Connect Socket addr=/81.175.86.202,port=49150,localport=5269

2008.06.17 19:10:30 ServerDialback: RS - Received dialback key from host: jabber.anywise.com to: jabber.wolfbeast.com

2008.06.17 19:10:30 ServerDialback: RS - Trying to connect to Authoritative Server: jabber.anywise.com:5269(DNS lookup: jabber.anywise.com:5269)

2008.06.17 19:10:30 ServerDialback: RS - Connection to AS: jabber.anywise.com:5269 successful

2008.06.17 19:10:30 ServerDialback: RS - Asking AS to verify dialback key for id20b1cc58

2008.06.17 19:10:31 ServerDialback: RS - Key was VERIFIED by the Authoritative Server for: jabber.anywise.com

2008.06.17 19:10:31 ServerDialback: RS - Closing connection to Authoritative Server: jabber.anywise.com

2008.06.17 19:10:31 ServerDialback: RS - Sending key verification result to OS: jabber.anywise.com

2008.06.17 19:10:31 ServerDialback: AS - Verifying key for host: jabber.anywise.com id: 3344141079

2008.06.17 19:10:31 ServerDialback: AS - Key was: VALID for host: jabber.anywise.com id: 3344141079

2008.06.17 19:10:31 ServerDialback: OS - Validation GRANTED from: jabber.anywise.com id: 3344141079 for domain: jabber.wolfbeast.com

2008.06.17 19:10:54 CertificateManager: SubjectAltName of invalid type found: EMAILADDRESS=postmaster@wolfbeast.com, CN=jabber.wolfbeast.com, OU=Domain validated only, O=Moonchild Productions, L=SkxC3xB6vde, ST=O, C=SE

2008.06.17 19:10:54 CertificateManager: SubjectAltName of invalid type found: EMAILADDRESS=postmaster@wolfbeast.com, CN=jabber.wolfbeast.com, OU=Domain validated only, O=Moonchild Productions, L=SkxC3xB6vde, ST=O, C=SE

============================

2008.06.17 19:18:16 LocalOutgoingServerSession: OS - Trying to connect to jabber.org:5269(DNS lookup: jabber.org:5269)

2008.06.17 19:18:16 LocalOutgoingServerSession: OS - Plain connection to jabber.org:5269 successful

2008.06.17 19:18:16 LocalOutgoingServerSession: OS - Indicating we want TLS to jabber.org

2008.06.17 19:18:17 LocalOutgoingServerSession: OS - Negotiating TLS with jabber.org

2008.06.17 19:18:18 LocalOutgoingServerSession: OS - TLS negotiation with jabber.org was successful

2008.06.17 19:18:18 LocalOutgoingServerSession: OS - Error, no SASL mechanisms were offered by jabber.org

2008.06.17 19:18:18 LocalOutgoingServerSession: OS - Going to try connecting using server dialback with: jabber.org

2008.06.17 19:18:18 ServerDialback: OS - Trying to connect to jabber.org:5269(DNS lookup: jabber.org:5269)

2008.06.17 19:18:18 ServerDialback: OS - Connection to jabber.org:5269 successful

2008.06.17 19:18:18 ServerDialback: OS - Sent dialback key to host: jabber.org id: 1469403149 from domain: jabber.wolfbeast.com

2008.06.17 19:18:19 Connect Socket addr=/208.68.163.214,port=37026,localport=5269

2008.06.17 19:18:19 ServerDialback: RS - Received dialback key from host: jabber.org to: jabber.wolfbeast.com

2008.06.17 19:18:19 ServerDialback: RS - Trying to connect to Authoritative Server: jabber.org:5269(DNS lookup: jabber.org:5269)

2008.06.17 19:18:19 ServerDialback: RS - Connection to AS: jabber.org:5269 successful

2008.06.17 19:18:20 ServerDialback: RS - Asking AS to verify dialback key for idc5dbc6ec

2008.06.17 19:18:20 ServerDialback: RS - Key was VERIFIED by the Authoritative Server for: jabber.org

2008.06.17 19:18:20 ServerDialback: RS - Closing connection to Authoritative Server: jabber.org

2008.06.17 19:18:20 ServerDialback: RS - Sending key verification result to OS: jabber.org

2008.06.17 19:18:20 ServerDialback: AS - Verifying key for host: jabber.org id: 1469403149

2008.06.17 19:18:20 ServerDialback: AS - Key was: VALID for host: jabber.org id: 1469403149

2008.06.17 19:18:20 ServerDialback: OS - Validation GRANTED from: jabber.org id: 1469403149 for domain: jabber.wolfbeast.com

2008.06.17 19:18:20 Connect Socket addr=/208.68.163.214,port=37031,localport=5269

2008.06.17 19:18:21 ServerDialback: RS - Received dialback key from host: jabber.org to: jabber.wolfbeast.com

2008.06.17 19:18:21 ServerDialback: RS - Trying to connect to Authoritative Server: jabber.org:5269(DNS lookup: jabber.org:5269)

2008.06.17 19:18:21 ServerDialback: RS - Connection to AS: jabber.org:5269 successful

2008.06.17 19:18:21 ServerDialback: RS - Asking AS to verify dialback key for id71add5e4

2008.06.17 19:18:21 ServerDialback: RS - Key was VERIFIED by the Authoritative Server for: jabber.org

2008.06.17 19:18:21 ServerDialback: RS - Closing connection to Authoritative Server: jabber.org

2008.06.17 19:18:21 ServerDialback: RS - Sending key verification result to OS: jabber.org

================================

so… even after all that, it still wants to use SASL with the remote server to authenticate… ?

The SubjectAlternativeName of the new certificate is:

Other Name:

1.3.6.1.5.5.7.8.5=0c 14 6a 61 62 62 65 72 2e 77 6f 6c 66 62 65 61 73 74 2e 63 6f 6d

DNS Name=wolfbeast.com

DNS Name=jabber.wolfbeast.com

The bottom two certmanager complaints in the above log are, if I understood correctly, because of the two DNS names. In that case that should be fine.

I’m not sure if I’m missing anything here. Openfire doesn’t complain about the certificate, the othername XMPP extension has jabber.wolfbeast.com in it which matches my XMPP domain, TLS gets negotiated successfully…

Any ideas?

Mark.

UPDATE:

I’ve pulled out the local test server again and actually got encryption working (that one is using a self-signed certificate, openfire 3.5.1 as I didn’t update it yet), with the following in the debug log of jabber.wolfbeast.com after attempting an inbound s2s connection by sending a presence packet to an account there from the test server:

2008.06.17 19:39:15 Connect Socket addr=/192.168.73.88,port=1239,localport=5269

2008.06.17 19:39:18 LocalOutgoingServerSession: OS - Trying to connect to jabtest:5269(DNS lookup: jabtest:5269)

2008.06.17 19:39:18 LocalOutgoingServerSession: OS - Plain connection to jabtest:5269 successful

2008.06.17 19:39:18 LocalOutgoingServerSession: OS - Indicating we want TLS to jabtest

2008.06.17 19:39:18 LocalOutgoingServerSession: OS - Negotiating TLS with jabtest

2008.06.17 19:39:20 LocalOutgoingServerSession: OS - TLS negotiation with jabtest was successful

2008.06.17 19:39:20 LocalOutgoingServerSession: OS - Stream compression not supoprted by jabtest

2008.06.17 19:39:20 LocalOutgoingServerSession: OS - Starting EXTERNAL SASL with jabtest

2008.06.17 19:39:20 LocalOutgoingServerSession: OS - EXTERNAL SASL with jabtest was successful

Maybe it has something to do with compression, since that’s off on the jabtest server?

The thing still is, that SASL shouldn’t be used :stuck_out_tongue: on my LAN it might succeed because the IP address reverse resolves to the correct host name (but on a public network that would be asking too much) – is there a way to completely bypass SASL? I really don’t care if the remote server is “really who they say they are” beyond exchanging server certificate data.

Message was edited by: wolfbeest

26

Hey Mark,

When using TLS for s2s it comes bundled with SASL EXTERNAL. In other words, the s2s options are TLS + SASL EXTERNAL or server dialback. The certificate is being accepted fine. The weird thing is why SASL was not offered by the other server after TLS was negotiated (or may be it was offered but the server failed to read it?). It would be useful if you can print the XML that is being flowing between both servers.

Regards,

– Gato

27

When using TLS for s2s it comes bundled with SASL EXTERNAL. In other words, the s2s options are TLS + SASL EXTERNAL or server dialback. The certificate is being accepted fine. The weird thing is why SASL was not offered by the other server after TLS was negotiated (or may be it was offered but the server failed to read it?). It would be useful if you can print the XML that is being flowing between both servers.

How would I go about capturing the xml data flowing between both servers?

28

Well, after some checking I managed to get an analysis of the start of the communication, it being:

after which the certificates are exchanged, and then some more data but that is, of course, encrypted so there is no way to see exactly what happens after TLS is established.

The only other data exchanged is the plaintext dialback communication, which obviously works, and is irrelevant here.