SSL a nightmare to setup!

Openfire Openfire Support
1

Hey I have been killin myself tryin to setup SSL, currently I reverted to the stock keystore and truststore and followed the SSL guide directions, here is my config and error report.

PLEASE HELP!!! thanks

Server Uptime: Approx 6 minutes – started Jun 25, 2005 12:07:57 PM

Version: Jive Messenger 2.1.5

Messenger Home: /opt/jive_messenger

Server Name: im.domain.com

Server Ports

1: IP:Port, Security: 216.39.90.34:5222, NORMAL

Domain Name(s): im.domain.com

2: IP:Port, Security: 216.39.90.34:5223, TLS (SSL)

Domain Name(s): im.domain.com

Environment

JVM Version and Vendor: 1.5.0_02 Sun Microsystems Inc. – Java HotSpot™ Server VM

Appserver: Jetty/5.1.x

OS / Hardware: Linux / i386

Locale / Timezone: en / Central Standard Time (-6 GMT)

Java Memory

7.66 MB of 63.31 MB (12.1%) used

adminConsole.port 9090

adminConsole.securePort 9091

register.inband false

registration.notification.enabled false

xmpp.auth.anonymous false

xmpp.domain im.domain.com

xmpp.muc.history.type number

xmpp.session.conflict-limit 1

xmpp.socket.plain.port 5222

xmpp.socket.ssl.active true

xmpp.socket.ssl.keypass changeit

xmpp.socket.ssl.keystore resources/security/keystore

xmpp.socket.ssl.port 5223

xmpp.socket.ssl.storeType jks

xmpp.socket.ssl.trustpass changeit

xmpp.socket.ssl.truststore resources/security/truststore

error.log

1

2

3

4

2005.06.25 12:12:15 org.jivesoftware.messenger.net.SocketReadThread.run(SocketReadThread.java:160) Connection closed before session established

Socket[addr=/66.66.123.123,port=63981,localport=5222]

2005.06.25 12:12:30 org.jivesoftware.messenger.net.SocketReadThread.run(SocketReadThread.java:160) Connection closed before session established

83b00f[SSL_NULL_WITH_NULL_NULL: Socket[addr=/127.0.0.1,port=34398,localport=5223]]

I see the obvious problem that SSL is binding to 127.0.0.1 only, but how do i fix that?

2

Which client are you using? Is it Trillian by chance? If so, it’‘s actually a Trillian issue and not JM. They’‘ve found and fixed the issue and it will be released in the near future we’'re told.

Regards,

Matt

3

Gaim or Neos, I dont think its a client issue, port 5223 is only binding on localhost and not the public IP, although 5222 works fine but non ssl

4

I’‘m not familiar with Gaim or Neos, but I was running into the same problem while trying to develop a client application that used SSL to JM. The problem was that I had to use an older JVM (1.3.1_15) and JSSE 1.0.2 is not completely standards compliant (google com.sun.net.ssl.dhKeyExchangeFix). Anyways, my point is that you should check which JVM your client is running under (assuming Gaim and Neos are java clients). If it’‘s older than 1.4, then it is possible that the key exchange isn’‘t working correctly and you’'ll need to fix it (again, google “com.sun.net.ssl.dhKeyExchangeFix”).

5

I think you guys are totally missing my point, as the error log pointed out

port 5222 is binding (open) on the public IP but port 5223 which is the SSL port is only binding to localhost 127.0.0.1.

I did not configure it to do this, the server is running very standard setup. Am I specifying something wrong? I included my entire config, please help I need SSL to use jive.

6

org.jivesoftware.messenger.net.SocketReadThread.run(SocketReadThread.java:160) Connection closed before session established

Socket[addr=/66.66.123.123,port=63981,localport=5222]

2005.06.25 12:12:30 org.jivesoftware.messenger.net.SocketReadThread.run(SocketReadThread.java:160) Connection closed before session established

83b00f[SSL_NULL_WITH_NULL_NULL: Socket[addr=/127.0.0.1,port=34398,localport=5223]]

As you can see above 5222 binds correctly but not 5223, also it says SSL_NULL_WITH_NULL, is that an error?

7

Did you happen to change the default keystore password as instructed in the SSL Guide?

If so…change it back to default (changeit[/b])

There have been a number of reports that changing the keystore password breaks SSL connections, but never an answer why.

Hope this helps.

8

No the password is changeit…

The problem seems to be when SSL port is not opening on my public address, its binding to 127.0.0.1, I can telnet to it from the localhost but not remotely so SSL connections just time out.

Let me try and explain this again, SSL settings are opening up a port but its only listening on the localhost so outside connections to the server’'s public IP fail, because there is no port to connect to!

How would anything to do with the cert itself have to do with the way the server software creates sockets to listen on a specific port.

I am thinking i might take someones advice and try setting the default non-SSL port to -1 and see if the SSL port opens then…

9

also sounds like you could have stunnel running on the server.

we have this set up because not long ago GAIM wouldn’'t connect unless you connected in this manner.

so our stunnel is set up w/ the following lines in stunnel.conf

accept = 5224

connect = 5222

also could be software firewall settings blocking traffic on 5223. Maybe running the lsof -i command to see if any weird stuff is going on.

10

So you’'ve verified what ports are listening on what addresses via netstat right?

If so, then it seems that this is a weird software thing. The fact that Jive throws an error is interesting. Some wild guesses:

– You have some other service squatting on 5223 that gets punted when you try to start JM, and so neither is able to listen at the public address

Did you have some other jabber server dist before installing JM? Are you really starting from a clean slate? Do you have weird stuff in /etc/services?

– Some SSL misconfiguration is causing the error, and even though the machine claims to be listening on 127.0.0.1:5223, you wouldn’'t be able to get encrypted transport if you tried connecting to it

Have you tried connecting on localhost to see if the right thing happens? If not, then you need to go end-to-end and make sure you’'ve got all configuration pieces correct. Others here have heard me harp on this before, but make sure your filesystem permissions are set properly, especially for the keystore.

If you can’‘t get this done any other way, then I concur about stunnel. I use it for Trillian compatibility. It’'s a kludge, but it will work well enough.