powered by Jive Software

Openfire Server to Server breakdown

I run two openfire servers, which recently have been certificated through GoDaddy so that we can remove the requirements for no-auth on certificates, and reject self-signed certificates. One thing that has gotten me lately is why two the two servers are not talking to each other.

One server runs an AD authentication on an internal network across a firewall. Inside and outside the company, my users can connect just fine. However, this server will not initiate a connection to my other server outside the AD domain, outside the network. I’ve snagged this from the error log on the AD jabber server:

2008.07.08 10:16:03

org.jivesoftware.openfire.net.SocketReadingMode.negotiateTLS(SocketReadingMode.j ava:77)

Error while negotiating TLS:

org.jivesoftware.openfire.net.SocketConnection@682ef9 socket:

Socket[http://addr=/64.151.114.100,port=40797,localport=5269|http://addr=/64.151.114.10 0,port=40797,localport=5269] session:

org.jivesoftware.openfire.session.LocalIncomingServerSession@b14eb

status: 1 address: servepath.com/51155dfe id: 51155dfe

javax.net.ssl.SSLException: Unsupported record version Unknown-47.115at com.sun.net.ssl.internal.ssl.EngineInputRecord.bytesInCompletePacket(EngineInpu tRecord.java:97)at com.sun.net.ssl.internal.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:754 )at com.sun.net.ssl.internal.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:669)at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:607)at org.jivesoftware.openfire.net.TLSStreamHandler.doHandshake(TLSStreamHandler.jav a:212)at org.jivesoftware.openfire.net.TLSStreamHandler.start(TLSStreamHandler.java:158) at org.jivesoftware.openfire.net.SocketConnection.startTLS(SocketConnection.java:1 66)at org.jivesoftware.openfire.net.SocketReadingMode.negotiateTLS(SocketReadingMode. java:74)at org.jivesoftware.openfire.net.BlockingReadingMode.readStream(BlockingReadingMod e.java:127)at org.jivesoftware.openfire.net.BlockingReadingMode.run(BlockingReadingMode.java: 63)at org.jivesoftware.openfire.net.SocketReader.run(SocketReader.java:120)at java.lang.Thread.run(Thread.java:619)

Now, 64.151.114.100 is the right server, and it is one of the IPs that I have assigned to it, but that server also has four other IPs, one of which I’ve assigned to openfire and that’s 69.59.146.86. I’ve specified in my openfire.xml the network designation:

<network>

<interface>69.59.146.86</interface>

</network>

I did make sure the commenting was removed, and I have restarted my jabber server. I’ve made sure that all records are going to the right place, so here are my SRV entries too:

xmpp-server.tcp.cat6wired.net. 14400 IN SRV 0 0 5269 secure.cat6wired.net.

jabber.tcp.cat6wired.net. 14400 IN SRV 0 0 5269 secure.cat6wired.net.

xmpp-client.tcp.cat6wired.net. 14400 IN SRV 0 0 5222 secure.cat6wired.net.

secure.cat6wired.net. 14400 IN A 69.59.146.86

Now as I understand it, SRV records shouldn’t matter in this case, becase this server is actually hosting my domain records for the domain in question (cat6wired.net). This server acts as the ns (ns3 and ns4), and a dig on the srv records will show the full info which I won’t paste here.

What I’m wondering, is why does the AD jabber server persistently think that the server its connecting to is the address 64.151.114.100? Shouldn’t it connect to address 69.59.146.86? Am I going to have to hack the AD box and put in an entry into /etc/hosts to patch this? Help is appreciated.

~Brian

Hi Brian,

Openfire should handle the DNS SRV records properly. So it seems that this does not work. Did you restart the server which tries to connect to 64.151.114.100? Java usually caches DNS entries forever.

With JM-711 there is an option to specify host=ip:port entries for Openfire, this could help you to work around the issue.

The “” setting affects the wrong server and only the bind address, it has nothing to do with the address your remote server tries to connect to.

LG

Well, after resetting my openfire to bind to all IPs, I still wasn’t able to get communication running.

Going back to my server properties page, I noticed the little yellow triangle at Server Name that said “Found RSA certificate that is not valid for the server domain”. I’ve gotten a UCC certificate which validates across 5 domains, including the hostname that I’ve elected to give this server. After importing it, i saw the other self-signed keys get removed, and thought nothing of it. I am attempting to get these two to talk without having to populate the lines for accepting self-signed certificates and not verifying certificiates (which I had to enable to get the two servers to talk).

Any help here? If we need to start from ground zero to get this functional please let me know and I’ll start from the begining.

to get rid of the message about the ‘not valid for this domain’ next to my server name on the server config, I’ve specified xmpp.domain and xmpp.fqdn, but now my Fastpath setup no longer works (this is why I didnt’ do it before). Seems the more I try and fix the more I might be breaking =)

My primary concern is getting server to server to talk using the UCC certificates via GoDaddy from my work server and my personal server so I have a working model and process for deploying more servers. Next would be the Fastpath server integration, but any help on the primary problem would be helped greatly.

Well I think part of the problem is stemming from the fact that I use a Godaddy UCC certificate. I’ve since turned that certificate in, and upgraded to a wildcard domain certificate. I noticed that its RSA signed, and not DSA signed (because my key was generated RSA), do you know how to convert a RSA key to a DSA key for SSL certificates? That way I can add the DSA signed key and certificate generation to fulfill the apparent “missing” line that openfire keeps squaking about.

Good news is now I can talk to Jabber.org (though I didn’t test this before) and its completely secure. I still see lines in there about not liking the SSL certificate… I wonder if jabber.org doesn’t check certificate validity.

I self resolved this problem. It was a problem stemming from incompatibility with UCC certificates.

If anybody is still on this thread, did you get UCC certs to work with openfire?