The issue referred to in this thread was fixed before 1.2.4 even came out. (was the last 1.2.3 release) Other login issues I have not been able to see or reproduce for myself. There is some SSL related issue going around which I’ve yet to see a good correlation as to what’s causing it. I just don’t have enough info to go on right now, especially since it’s not happening to me. =/
How can I be of assistance ?
Daniel,
I just turned off SSL and have the same issue. I am open to helping any way I can to get this fixed, I can make my server available if needs be. I really need a little guidance on how I can help you to solve this for me… if you follow that!
Stefan
Turned off SSL? How did you do that? The openfire server settings (client ssl connections and such) shouldn’t affect MSN connections. What version of java do you both have? What OS?
Sorry Daniel - assumed by “There is some SSL related issue going around” you meant SSL from Jabber client to server. My mistake.
imac:~ stefan$ java -version
java version “1.5.0_13”
Java™ 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-237)
Java HotSpot™ Client VM (build 1.5.0_13-119, mixed mode, sharing)
Mac OS X 10.5.5 (9F33)
Appreciate your kind assistance - Stefan
I’m having the same kind of problem starting from last saturday when I decided to upgrade to 3.6.0, my users are loving me 
But I have a strange thing to report: I’m on linux, ubuntu 6.06, with Java 1.6 (Java HotSpot™ Client VM (build 1.6.0-b105, mixed mode, sharing)) and while waiting for this issue to be understood and solved, I tried to install and configure the EMail Listener plugin, linking it to my local cyrus imap server.
Well, if I told the plugin to use SSL, debug.log was telling me it could’t find SimpleSSLSocketFactory.
After reading this discussion, and your message, I wondered if the same problem was affecting IM, and grepped the debug logs:
2008.09.20 19:01:47 MSN: Exception occurred for r.maurizzi@xxxxxxx.it : java.net.SocketException: java.lang.ClassNotFoundException: org.jivesoftware.util.SimpleSSLSocketFactory
2008.09.20 19:01:47 MSN: IO error: java.net.SocketException: java.lang.ClassNotFoundException: org.jivesoftware.util.SimpleSSLSocketFactory
So I was thinking: maybe somewhere in the installation of OpenFire 3.6.0 on linux the libraries are not correctly installed? Or maybe something on my platform (ubuntu 6.06) or my installation procedure or installed product is causing it to misbehave?
HTH,
Roberto
A few more details:
jabber:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 4.0 (etch)
Release: 4.0
Codename: etch
jabber:~# java -version
java version “1.6.0_06”
Java™ SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot™ Client VM (build 10.0-b22, mixed mode, sharing)
Find my debug output here:
Can I do any thing else ? tcpdump, what ever ?
THANK YOU.
This thread helped me to figure out why the msn transport on my (newly installed, first time) openfire server was hosed.
Thank you to whoever mentioned debug logs. I managed to turn them on. Saw the same error about the SSL store. I’m on FreeBSD running a diablo vm (diablo-jdk-1.6.0.07.02). I first found my cacerts file and added a startup flag to my openfire startup script (added -Djavax.net.ssl.trustStore=/usr/local/diablo-jdk1.6.0/jre/lib/security/cacerts to $openfire_javaargs)… same deal.
I then used keytool ( cd /usr/local/diablo-jdk1.6.0/jre; bin/keytool lib/security/cacerts ) and my CACERTS FILE WAS EMPTY 
I had an ancient jdk 1.3.1 install in /usr/local/ so i pinched the cacerts file from there (10 certs), copied it over, and its now working great.
All transports working fine. My guess is if you are seeing this error you need to root around your cacerts file with keytool and make sure its readable, has content, etc. if you have an empty one and no other place to find it you can download any java jdk/jre and it should contain a cacerts file that will work. If you have custom CA certs etc you probably already know the wrinkles that’ll present…
THANK YOU. openfire just rocks. have been pounding my head with jabber-1.6 for a couple of years and this is just a treat.
Ive attached my cacerts file. you should NOT TRUST IT. if you must, use it to make sure you’ve found your problem and then go get your own. I could be a miscreant or something. usual place for it is (jre home)/lib/security
-matt
cacerts (7365 Bytes)
Thank you. That fixed it.
You will find a complete cacerts in Ports - /usr/ports/java/jdk16/files/cacerts. I just copied that.
Question is — what changed to make this a problem? Did this just “suddenly start having issues”?
The only thing that possibly changed was the 3.6.0a upgrade from 3.6.0.
=D That would have had nothing to do with this though. Oh well. Thought maybe 3.5.2 to 3.6.0 might have introduced some global SSL setting that we’re rnning into problems with, or something along those lines. hrm
I doubt any OS change could have affected this right? Its all JRE right?
An OS change could definitely have caused it if something like those cacerts are missing in the new OS. It’s possible that one JRE on one OS doesn’t behave exactly the same as on another OS, though this is rare and usually is a bug and would have been fixed by the OS/distribution. ;D
I can’t confirm this with my debian etch setup. Java certs are in place but it does not work.
Is there something I could dig into for you on my Mac OS X? I’m a z/OS guy … my Java and *nix knowledge is not deep but I have no problems with some guidance.
Well, I reply to myself to say… I’m an idiot
I omitted the rather fundamental detail that my server runs with XMPP SSL port bound to 443, to be able to bind to it from behind a strict HTTPS proxy/firewall combination.
Since I’m extremely ignorant about Java (and quite allergic too, I must say ) I don’t know how I’m supposed to give openfire enough rights to be able to bind to port 443 and then have it drops its privileges.
So, I googled a little, found nothing, and I simply copied the running command line of the server from “ps ax” and launched it “manually” as root (this system is noncritical, and mainly serves as a way to “escape” from the aforementioned firewall and use MSN )
Running as root, openfire changes the ownership of some files in /etc/openfire: I simply gave back ownership of this file to user openfire group openfire, restarted openfire with its init.d script… and MSN worked. No SSL over 443 obviously.
After that, I stopped again the server, and restarted it as root with the same command line as before… this time it bound port 443 and MSN was still working…
I don’t know what exactly changed, except the ownership of openfire.xml and available-plugins.xml.
BTW, if someone can point me to some docs on how to enable openfire to bind to privileged port under unix, I’ll be more than happy to do it “right”
Ciao,
Roberto
Solved: My OpenFire is located in a DMZ and forced to use a proxy for http and https. I’ve added the java commandline options:
-Dhttp.proxyHost=proxy
-Dhttp.proxyPort=port
-Dhttps.proxyHost=proxy
-Dhttps.proxyPort=port
-Dhttp.proxyUserName=user
-Dhttp.proxyPassword=pass
Now it works again.
Excuse me for this stupid questions. How do I add those java command line options??? Obviusly, I don’t know java. Please your help, I have the same problem with the msn connection (openfire 3.6.3 on SLES 10, spark 2.5.8 on WinXP, gateway.jar 1.2.4d)
Thanks for advise.
I too was seeing this on a brand new install of 3.6.3 on FreeBSD 7.0. I followed the guidance of “pfftdives” post and it fixed it for me too. Here’s a break down of my steps:
openfire [~]# locate cacerts
/usr/local/diablo-jdk1.6.0/jre/lib/security/cacerts
/usr/ports/java/diablo-jdk16/work/diablo-jdk1.6.0_07/jre/lib/security/cacerts
/usr/ports/java/jdk16/files/cacerts
openfire [~]# cd /usr/local/diablo-jdk1.6.0/jre/lib/security
openfire [/usr/local/diablo-jdk1.6.0/jre/lib/security]# mv cacerts cacerts.old
openfire [/usr/local/diablo-jdk1.6.0/jre/lib/security]# cp -p /usr/ports/java/jdk16/files/cacerts .
openfire [/usr/local/diablo-jdk1.6.0/jre/lib/security]# /usr/local/etc/rc.d/openfire restart
That did the trick. MSN transport now working.
-Steffan