SSL keystore seemingly corrupts itself on exit

I originally tried following the Openfire documentation for importing certificates via the command line keytool; i’d attempted to do this the first time, after configuring the server and then shutting it down. I added the certificate via keytool and upon restarting the server, saw through the web interface and in the logs/error.log that the keystore was considered corrupt.

I shutdown the server and removed all of the files in resources/security (in an effort to force regeneration). I started the server, logged in via the web interface, went to the security certificates page; it was naturally complaining of a corrupt keystore (since none existed, i presume) and asked it to generate its own keys. It did, and presented them in the reloaded web view.

After of intermediary hunting, it is always replicable to perform the above paragraph, then shutdown the server, do nothing, and start the server. Starting the server now complains about the keystore being corrupt (even though it just created the keystore itself during its last life cycle, and it was untouched by other processes).

I added a stack traced dump to catch block in the openfire class SSLConfig from where the error was coming (, recompiled and deployed the jar). The stack trace is:

java.io.EOFException
at java.io.DataInputStream.readInt(DataInputStream.java:358)
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:627)
at java.security.KeyStore.load(KeyStore.java:1150)
at org.jivesoftware.openfire.net.SSLConfig.(SSLConfig.java:99)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl.isClientSSLListenerEnabled( ConnectionManagerImpl.java:584)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl.createClientSSLListeners(Co nnectionManagerImpl.java:379)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl.createListeners(ConnectionM anagerImpl.java:92)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl.start(ConnectionManagerImpl .java:826)
at org.jivesoftware.openfire.XMPPServer.startModules(XMPPServer.java:600)
at org.jivesoftware.openfire.XMPPServer.start(XMPPServer.java:466)
at org.jivesoftware.openfire.XMPPServer.(XMPPServer.java:161)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessor Impl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructor AccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at java.lang.Class.newInstance0(Class.java:350)
at java.lang.Class.newInstance(Class.java:303)
at org.jivesoftware.openfire.starter.ServerStarter.start(ServerStarter.java:106)
at org.jivesoftware.openfire.starter.ServerStarter.main(ServerStarter.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja va:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.exe4j.runtime.LauncherEngine.launch(Unknown Source)
at com.install4j.runtime.Launcher.main(Unknown Source)

As far as configuration, my environment is:

Openfire 3.5.2
1.5.0_14 Sun Microsystems Inc. – Java HotSpot™ Server VM
jetty-6.1.x
OS / Hardware: Linux / i386

and the system properties i have set were xmpp.socket.ssl.active to ‘true’ and xmpp.socket.ssl.keypass to the correct password.

Any ideas?

(Staring at the stack trace, the exception is caused its attempt to read the truststore and not the keystore, which is 0 bytes on the file system. Should this file not be empty even though i have no client certificates?)

Any chance this is on Debian? I see 2 other threads with similar problems on debian. One of them is my own.

So far, no response and no solution.

Nej - this is on fedora. After a stumbling install and run attempt, and zero response here, my passing fancy in installing this has passed… at least it’s debug-able with the source code… meh