Gloox and SASL issues

Openfire Openfire Support
1

I’'m not sure who is at all familiar with the gloox jabber client library, but I am using it right now to try and create a simple jabber client that communicates across an Openfire server to a pidgin client at the other end. However, I cannot get past the authentication stage.

Luckily, gloox has a loghandler which prints out the actual xml messages being sent back and forth, or so I think. The following is a conversation between two different machines, with openfire running on one, and my attempt at a gloox client on the other:

log: level: 1, area: 32, notice: no SRV record found for 192.168.0.4, using default port.

log: level: 0, area: 32, connecting to 192.168.0.4 (192.168.0.4:5222)

log: level: 0, area: 16384,

message_test: disconnected: 15

auth failed. reason: 6

ce: 17

I have a few of questions about this:

  1. The certificate is said to come from the server, which I specified as ‘‘192.168.0.4’’ - why is the issuer listed as localhost.localdomain?

  2. Why is the certificate listed as being valid until December 1969 (I know the significance of this date) instead of a later date?

  3. if the date is not the reason for lack of authentication, does anyone know what might be causing it? Can I set up the server not to use SASL at all?

Thank you all for your time.

2

While the date and cert should not cause DIGEST-MD5 to fail, it does seem to indicate there might be some issue with the clock on the server, or was when the certs were generated (at install time). Also, Openfire thinks its hostname is localhost.localdomain (this is your problem, see below)

Make sure your host name and clock settings are correct, then go to the server admin page, and make sure the server domain is correct. Then under Server Certificates you should have the ability to generate new self-signed certs that match up correctly.

The problem you are encountering is that DIGEST-MD5 uses whats called a “digest-uri” . The client (gloox) is setting the digest-uri to “xmpp/192.168.0.4”. The problem is the server has no idea what 192.168.0.4 is, so it rejects the authentication. Try getting your hostname’'s and xmpp domain names all straightened out, and see if that helps.