3.6.4 SASL failing secure connection Server to Server

So I’m having this wonderful issue resulting int he following logs:

2009.05.26 22:24:14 LocalOutgoingServerSession: OS - Trying to connect to easytospell.net:5269(DNS lookup: xmpp.easytospell.net:5269)
2009.05.26 22:24:14 LocalOutgoingServerSession: OS - Plain connection to easytospell.net:5269 successful
2009.05.26 22:24:14 LocalOutgoingServerSession: OS - Indicating we want TLS to easytospell.net
2009.05.26 22:24:14 LocalOutgoingServerSession: OS - Negotiating TLS with easytospell.net
2009.05.26 22:24:14 LocalOutgoingServerSession: OS - TLS negotiation with easytospell.net was successful
2009.05.26 22:24:14 LocalOutgoingServerSession: OS - Stream compression was successful with easytospell.net
2009.05.26 22:24:14 LocalOutgoingServerSession: OS - Error, EXTERNAL SASL and SERVER DIALBACK were not offered by easytospell.net
2009.05.26 22:24:14 OutgoingSessionPromise: Error sending packet to remote server:
<message id="Gf4Y6-64" to="richard@easytospell.net/work" from="mengesb@cat6wired.net/spark" type="chat">
<body>ping</body>
<thread>3LVJkI</thread>
<x xmlns="jabber:x:event">
<offline/>
<composing/>
</x>
</message>
java.lang.Exception: Failed to create connection to remote server
at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.sendPacket(OutgoingSessionPromise.java:252)
at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.run(OutgoingSessionPromise.java:216)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Now, when we do not enable TLS, all works fine, and judging from the messages above the TLS negotiation is just fine as well… but its waiting on either my host, or his host for SASL … but we’re both perplexed.

I’m running CentOS 5.3 with the latest updates, the other server is running Debian 5 with the latest updates. Here are some package informations:

CentOS 5.3:

[ @ ~]# rpm -aq | grep tls ; rpm -aq | grep sasl
gnutls-1.4.1-3.el5_2.1
gnutls-1.4.1-3.el5_2.1
cyrus-sasl-plain-2.1.22-4
cyrus-sasl-gssapi-2.1.22-4
cyrus-sasl-md5-2.1.22-4
cyrus-sasl-devel-2.1.22-4
cyrus-sasl-lib-2.1.22-4
cyrus-sasl-plain-2.1.22-4
cyrus-sasl-2.1.22-4
cyrus-sasl-2.1.22-4
cyrus-sasl-md5-2.1.22-4
cyrus-sasl-devel-2.1.22-4
cyrus-sasl-gssapi-2.1.22-4
cyrus-sasl-lib-2.1.22-4
gnu-crypto-sasl-jdk1.4-2.1.0-2jpp.1

Debian 5:

libgsasl7          0.2.26-2          GNU SASL library
libssl0.9.8        0.9.8g-15+lenny1  SSL shared libraries
openssl            0.9.8g-15+lenny1  Secure Socket Layer (SSL) binary and

So, while the OpenSSL versions are slightly off (minor revisions from E to G) and his default SASL library being GNU based, and I have CYRUS but I do have the Gssapi libraries and gnu jdk libraries installed… why isn’t this connecting on the same level?

My certificate is a wildcard domain certificate from Godaddy (.cat6wired.net) and the other server’s is also Godaddy (.easytospell.net). Not sure what we’re missing here… unless something just isn’t matching - does Debian need the cyrus libraries or I need to get the GNU libraries? Help would be greatly appreciated as we’re quite confused.

On a similar note, despite downloading manual rpms for libgsasl-0.2.29-1.el5.i386.rpm and libgsasl-0.2.29-1.el5.x86_64.rpm it seems CentOS 5.3 won’t allow these to be installed:

[ @ ~]# yum localinstall libgsasl-0.2.29-1.el5.i386.rpm
Loaded plugins: fastestmirror
Setting up Local Package Process
Examining libgsasl-0.2.29-1.el5.i386.rpm: libgsasl-0.2.29-1.el5.i386
Marking libgsasl-0.2.29-1.el5.i386.rpm to be installed
Loading mirror speeds from cached hostfile * base: centos-distro.cavecreek.net * updates: mirror.stanford.edu * addons: mirrors.kernel.org * extras: linux.mirrors.es.net
Resolving Dependencies
--> Running transaction check
---> Package libgsasl.i386 0:0.2.29-1.el5 set to be updated
--> Processing Dependency: libidn.so.11 for package: libgsasl
--> Processing Dependency: libntlm.so.0 for package: libgsasl
--> Running transaction check
---> Package libgsasl.i386 0:0.2.29-1.el5 set to be updated
--> Processing Dependency: libntlm.so.0 for package: libgsasl
---> Package libidn.i386 0:0.6.5-1.1 set to be updated
--> Finished Dependency Resolution
libgsasl-0.2.29-1.el5.i386 from libgsasl-0.2.29-1.el5.i386.rpm has depsolving problems
  --> Missing Dependency: libntlm.so.0 is needed by package libgsasl-0.2.29-1.el5.i386 (libgsasl-0.2.29-1.el5.i386.rpm)
Error: Missing Dependency: libntlm.so.0 is needed by package libgsasl-0.2.29-1.el5.i386 (libgsasl-0.2.29-1.el5.i386.rpm)
[ @ ~]# yum localinstall libgsasl-0.2.29-1.el5.x86_64.rpm
Loaded plugins: fastestmirror
Setting up Local Package Process
Examining libgsasl-0.2.29-1.el5.x86_64.rpm: libgsasl-0.2.29-1.el5.x86_64
Marking libgsasl-0.2.29-1.el5.x86_64.rpm to be installed
Loading mirror speeds from cached hostfile * base: centos-distro.cavecreek.net * updates: linux.mirrors.es.net * addons: mirrors.kernel.org * extras: linux.mirrors.es.net
Resolving Dependencies
--> Running transaction check
---> Package libgsasl.x86_64 0:0.2.29-1.el5 set to be updated
--> Processing Dependency: libntlm.so.0()(64bit) for package: libgsasl
--> Finished Dependency Resolution
libgsasl-0.2.29-1.el5.x86_64 from libgsasl-0.2.29-1.el5.x86_64.rpm has depsolving problems
  --> Missing Dependency: libntlm.so.0()(64bit) is needed by package libgsasl-0.2.29-1.el5.x86_64 (libgsasl-0.2.29-1.el5.x86_64.rpm)
Error: Missing Dependency: libntlm.so.0()(64bit) is needed by package libgsasl-0.2.29-1.el5.x86_64 (libgsasl-0.2.29-1.el5.x86_64.rpm)
[ @ ~]# ls -la /usr/lib*/sasl2/libntlm.so*
lrwxrwxrwx 1 root root    17 May 26 23:14 /usr/lib64/sasl2/libntlm.so -> libntlm.so.2.0.22
lrwxrwxrwx 1 root root    17 May 26 23:25 /usr/lib64/sasl2/libntlm.so.0 -> libntlm.so.2.0.22
lrwxrwxrwx 1 root root    17 May 26 23:14 /usr/lib64/sasl2/libntlm.so.2 -> libntlm.so.2.0.22
-rwxr-xr-x 1 root root 32640 Jan  7  2007 /usr/lib64/sasl2/libntlm.so.2.0.22
lrwxrwxrwx 1 root root    17 May 26 23:14 /usr/lib/sasl2/libntlm.so -> libntlm.so.2.0.22
lrwxrwxrwx 1 root root    17 May 26 23:26 /usr/lib/sasl2/libntlm.so.0 -> libntlm.so.2.0.22
lrwxrwxrwx 1 root root    17 May 26 23:14 /usr/lib/sasl2/libntlm.so.2 -> libntlm.so.2.0.22
-rwxr-xr-x 1 root root 31516 Jan  7  2007 /usr/lib/sasl2/libntlm.so.2.0.22

Seems my own system won’t believe that it has linkage to the right libraries… grant it my version is 2.0.22, it should still have accepted the solink… but oh well.

Thought this could be a resource as to why, but i doubt it.

So if someone can offer me a solution that points at that as the problem i’ll consider migrating to a completely matching architecture where both systems are the same OS, patch level, and security package settings, but that doesn’t really seem to be the whole probelm as TLS is obviously working according to the logs.