The trustAnchors parameter must be non-empty (Problem connecting MSN Transport on Mac Openfire 3.5.2)

Openfire Plugins Kraken - IM Gateway
1

I am new to this, so if I am just being an idiot please forgive me, but I can’t seem to get the MSN transport to work on my local copy of Openfire. As far as I can tell it never successfully completes the login process. Turning on the debug logs gives the only exception as:

2008.07.02 22:04:46 MSN: IO error: javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

Which is immeadiately followed by a Disconnecting message so I assume this is where the problem lies, but I have no clue as to what to do about it. I am including a larger snip from the log in case it contains anything relevant:

2008.07.02 22:04:46 MSN: IO error: javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

2008.07.02 22:04:46 MSN: Exception occurred for wolf.gilbert@mac.com : javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

2008.07.02 22:04:46 MSN: Session messageReceived for wolf.gilbert@mac.com : USR 3 TWN S ct=1215054286,rver=5.5.4177.0,wp=FS_40SEC_0_COMPACT,lc=1033,id=507,ru=http:%2F% 2Fmessenger.msn.com,tw=0,kpp=1,kv=4,ver=2.1.6000.1,rn=1lgjBfIL,tpf=b0735e3a873df b5e75054465196398e0

2008.07.02 22:04:46 session 26 received message USR 3 TWN S ct=1215054286,rver=5.5.4177.0,wp=FS_40SEC_0_COMPACT,lc=1033,id=507,ru=http:%2F% 2Fmessenger.msn.com,tw=0,kpp=1,kv=4,ver=2.1.6000.1,rn=1lgjBfIL,tpf=b0735e3a873df b5e75054465196398e0

2008.07.02 22:04:46 MSN: Session messageReceived for wolf.gilbert@mac.com : CVR 2 8.1.0178 8.1.0178 8.1.0178 http://msgruser.dlservice.microsoft.com/download/5/6/4/5646481F-33EF-4B08-AF00-4 904F7677B89/EN/Install_WLMessenger.exe http://get.live.com

2008.07.02 22:04:46 session 26 received message CVR 2 8.1.0178 8.1.0178 8.1.0178 http://msgruser.dlservice.microsoft.com/download/5/6/4/5646481F-33EF-4B08-AF00-4 904F7677B89/EN/Install_WLMessenger.exe http://get.live.com

2008.07.02 22:04:45 MSN: Session messageReceived for wolf.gilbert@mac.com : VER 1 MSNP11 CVR0

2008.07.02 22:04:45 session 26 received message VER 1 MSNP11 CVR0

2008.07.02 22:04:45 MSN: Session messageSent for wolf.gilbert@mac.com : USR 3 TWN I wolf.gilbert@mac.com

2008.07.02 22:04:45 session 26 sent message USR 3 TWN I wolf.gilbert@mac.com

2008.07.02 22:04:45 MSN: Session messageSent for wolf.gilbert@mac.com : CVR 2 0x0409 winnt 5.1 i386 MSNMSGR 8.1.0178 MSMSGS wolf.gilbert@mac.com

2008.07.02 22:04:45 session 26 sent message CVR 2 0x0409 winnt 5.1 i386 MSNMSGR 8.1.0178 MSMSGS wolf.gilbert@mac.com

2008.07.02 22:04:45 MSN: Session messageSent for wolf.gilbert@mac.com : VER 1 MSNP11 CVR0

2008.07.02 22:04:45 session 26 sent message VER 1 MSNP11 CVR0

2008.07.02 22:04:45 MSN: Session established for wolf.gilbert@mac.com

2008.07.02 22:04:45 session 26 established

Any help would be gratefully accepted,

Thanks,

Wolf.

2

doubletake What in the hell is that? =) Would you mind sharing what you are running it on/under:

  • Operating System:

  • Java version:

  • 32-bit or 64-bit:

That’s all I can think of at the moment. (I know it’s a mac, but which version?)

3

Mac Book Pro (latest rev.) OSX 10.5.4.

java -version gives:

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 is 64 bit, and I think this is a 64 bit Java, but don’t hold me to that. If you know how to check I’d be happy to look it up for you.

Wolf.

4

Were you running it before the 10.5.4 upgrade? Was it working fine then?

5

This was not an upgrade…I installed it today (already had 10.5.4) - it has never worked for me. You got me thinking with the Java question and a little research shows other people (in unrelated applications) having the “trustAchors” after upgrading to Java 1.5.0 WTF problem and “solving” it by moving to 1.5.1 - there is no 1.5.1 for the Mac that I am aware of, but I do have 1.6 loaded. However, even after selecting 1.6 as the system default Openfire still uses 1.5 - is there some setting somewhere that I can set to convince it to use 1.6 instead?

6

Hrm. I would think it would use java 6 by default if you set that in your system. Try editing /usr/local/openfire/bin/openfire.sh on your system. You’ll see a path early on to JAVA_HOME for darwin. Try setting that to the java 6 framework path. Unfortunately I don’t know what that is because apple screwed me on a java 6 upgrade. (I have the last of the core (1) duos, not core 2, and they didn’t bother to offer java 6 for my system.

7

Nothing I have tried seems to make it use the 1.6 version - it could be because 1.6 is 64 bit and if Openfire is running in some 32-bit container perhaps it wouldn’t work??? I know that is the case for Safari even on Mac OS X because Safari is 32 bit…I will mess with it some more over the next day or so…if I come up with anything I will let you know.

Thanks,

Wolf.

8

Ok! Openfire should work dandy with 64-bit and java 6. In fact we prefer java 6, just wasn’t available on mac before. =)

9

Ok, some progress. I changed the link that redirects the CurrentJDK from 1.5 to 1.6 and started openfire from the terminal (as root) and everything worked as planned. It correctly reports 1.6 as the JDK and the transport works correctly now…but…now it will not run correctly when started at boot. Opening the admin console goes directly to the setup routine everytime and the setup routine fails with:

java.lang.NullPointerException

at org.jivesoftware.util.JiveGlobals.deleteXMLProperty(JiveGlobals.java:493)

at org.jivesoftware.openfire.admin.setup.setup_002dprofile_002dsettings_jsp._jspSe rvice(setup_002dprofile_002dsettings_jsp.java:77)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)

at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1093)

at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:11 8)

at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)

at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:66)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)

at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingF ilter.java:42)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)

at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:70)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)

at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:99)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1084)

at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)

at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)

at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)

at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)

at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)

at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollect ion.java:206)

at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)

at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)

at org.mortbay.jetty.Server.handle(Server.java:324)

at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)

at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:843 )

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

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

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

at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)

at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)

Now I am guessing here, but perhaps running the server as root has created some file with a permissions set that the main services can’t read (or perhaps write to) and that’s causing the failure? I would have thought that the main service was running as root when started by launchd, but I am a relative Mac novice so I could be way of base. Any clue what I have don’t to break it now?

Thanks,

Wolf.

10

Ok, problem solved. The earlier issue was a properties file that was created as root (I notice that openfire runs under its own userid - openfire so doing a chown openfire on this file solved that problem, but when openfire came up it still didn’t run as Java 1.6. I did solve this issue (see below)

To recap, there is some issue with the 1.5.0 version of the JDK which causes the original fault in the title - this I can’t fix, but the problem does not occur when running under Java 1.6. To get openfire to run under 1.6 you would normally just download it from Apple (there is an update for OS X 1.5.x - but only for Intel Macs) and then you need to select this JVM as the default (otherwise 1.5.0 is still used). You change the default using the Java Preferences tool in Applications/Utilities/Java. Unfortunately the openfire-launchd-wrapper.sh file (in /usr/local/openfire/bin/extra) ignores the default so you need to edit this file. Change the definition of JAVA_HOME to:

export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Home

and change the invocation line to:

$JAVA_HOME/bin/java -server -jar “$OPENFIRE_HOME/lib/startup.jar” -Dopenfire.lib.dir=/usr/local/openfire/lib&

and now it will obey the Java preferences settings and run in which ever JVM you have defined as preferred. Of course you can also leave the default as 1.5 and change the behavior for just openfire by setting the JAVA_HOME definition listed above to:

export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home

instead (you still need to change the invocation line to use $JAVA_HOME though).

I hope this helps some other poor schmuck

Wolf.

1 Like