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