powered by Jive Software

Server-to-Server TLS Problems

I’m working on a deployment of Openfire 3.6.4 where we have one DMZ and a second internal Openfire servers. I have the two set up and communicating. You can search, chat, etc between users on both servers. I have certs (both RSA and DSA) on both servers that were signed by our internal CA. I have loaded the root CA certs into the Truststore, so they show up as in Openfire’s Admin Console as “CA Signed” with green checks.

My problem is when I change the servers’ Security Settings for “Server Connection Security” from “Optional” to “Required”. I leave the “Accept self-signed certificates” checked. Again, both servers show their respective certs as CA signed and good… But they no longer are able to communicate.

The Internal server gives the following error in the logs:

L*og removed due to errors no longer appearing. *

The DMZ server has the following:

2009.05.21 14:29:11 [org.jivesoftware.openfire.session.LocalOutgoingServerSession.createOutgoingSes sion(LocalOutgoingServerSession.java:258)
] Error trying to connect to remote server: Internal.MyDomain.com(DNS lookup: Internal.MyDomain.com:5269)
java.net.ConnectException: Connection timed out: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at org.jivesoftware.openfire.session.LocalOutgoingServerSession.createOutgoingSess ion(LocalOutgoingServerSession.java:253)
at org.jivesoftware.openfire.session.LocalOutgoingServerSession.authenticateDomain (LocalOutgoingServerSession.java:185)
at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.sendPa cket(OutgoingSessionPromise.java:239)
at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.run(Ou tgoingSessionPromise.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, at first that would seem to be DNS (to me), but they connect perfectly fine when not requiring TLS. They are able to do NSLOOKUPs on each other just fine.

Can someone point me in the right direction to get this resolved?

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

Okay, that was based on behavior I was seeing yesterday when I left work. I’ve not changed anything today, but the behavior did change…

The internal server is no longer showing any errors in the logs, and is able to send chat messages to the DMZ user. However, it cannot detect presense information (is the person online or not).

The DMZ server cannot detect presense information, nor can it send any chat messages. It does receive them however. The above error from the DMZ server is still accurate.

Message was edited by: BDeakins