powered by Jive Software

iChat over secure connection to openfire 3.3.3 no worky work

All kidding aside, I can not establish a secure connection from latest stable iChat, using a proven working, good, internal jabber account on our openfire server, to our internal server running centOS 4.5, all updates, and openfire 3.3.3.

I believe that I have tried every possibility of the security settings and none work. Turns out we actually havent been using iCaht much but now have the need for it. We have been using Adium or Spark on most of our client’s machines for the last year or so, but … here is the thing, I know for a fact that I did test this scenario about a year ago, whatever version of wildfire that that was, and it worked. I woder what is different today, sure lots has changed, but dont know which side has changed in such a way as to not allow this to work. I tried connecting to ports 5222 & 5223 in lots of configurations inside iChat.

Any insight from someone who has this working is most appreciated.

Completely off the topi, is anyone using iChat with openfire & using the video (ie: iSight) during their chat? I am headed to Asia for a while & I really need to

get video cracking & really prefer that that video stay secure & internal.

Thanks so much.


Jason Sjobeck


I have more information. This actually works perfectly from one of the other machines in the office (brand new iMac) but not from the machine in question. Both are identical as far as we know for OS & softwares. One works, one doesnt. This is the openfire debug log from the machine that doesnt work trying to log-in via iChat:

2007.10.28 22:03:06 EXCEPTION

java.net.SocketTimeoutException: Read timed out

at java.net.SocketInputStream.socketRead0(Native Method)

at java.net.SocketInputStream.read(Unknown Source)

at com.sun.net.ssl.internal.ssl.InputRecord.readFully(Unknown Source)

at com.sun.net.ssl.internal.ssl.InputRecord.read(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(Unknown Source)

at com.sun.net.ssl.internal.ssl.AppInputStream.read(Unknown Source)

at org.mortbay.io.ByteArrayBuffer.readFrom(ByteArrayBuffer.java:168)

at org.mortbay.io.bio.StreamEndPoint.fill(StreamEndPoint.java:99)

at org.mortbay.jetty.bio.SocketConnector$Connection.fill(SocketConnector.java:190)

at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:277)

at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:203)

at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)

at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:217)

at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475) 2007.10.28 22:03:06 EOF

Turns out to not really matter what 3.x version of server youre running, it will not work. I found out today, so thought I’d close out this thread for any one else, as well as for my own notes (I often google for my own posts a year later when need it again) that the issue is that ichat simply will not encrypt properly on tcp/5222 with openfire server. It wants/requires tcp/5223. If you open the firewall to tcp/5223 it pops right on. Dont know why it took me this long to experiment with that, but it was a combination of things, since I was hoping to be legacy-free, I was forcing everything to TLS on tcp/5222. Guess we cant as long as want iChat to work.

For any one who cares, I have posted this:


Thanks all.