Java KeyStore Path Missing for Bosh and XMPP

Mark40 · January 13, 2016, 5:27am

Hi there,

Did an upgrade from 3 to 4.0.0 using the deb package on Ubuntu. (dpkg -i). The keystore settings have changed and the default paths for the XMPP client stores and Bosh stores are empty. This causes all ssl/tls related functionality to stop working.

Is there a property I must set? Trying to generate self signed certs in order to get the path set results in:

2016.01.13 07:09:45 org.jivesoftware.openfire.http.HttpBindManager - Error creating SSL connector for Http bind
java.lang.NullPointerException
at org.jivesoftware.openfire.http.HttpBindManager.createSSLConnector(HttpBindManag er.java:246)
at org.jivesoftware.openfire.http.HttpBindManager.configureHttpBindServer(HttpBind Manager.java:518)
at org.jivesoftware.openfire.http.HttpBindManager.start(HttpBindManager.java:193)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl.startListeners(ConnectionMa nagerImpl.java:290)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl.access$000(ConnectionManage rImpl.java:49)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl$1.pluginsMonitored(Connecti onManagerImpl.java:269)
at org.jivesoftware.openfire.container.PluginManager.firePluginsMonitored(PluginMa nager.java:532)
at org.jivesoftware.openfire.container.PluginManager.access$800(PluginManager.java :68)
at org.jivesoftware.openfire.container.PluginManager$PluginMonitor.run(PluginManag er.java:1047)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301 (ScheduledThreadPoolExecutor.java:178)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Schedu ledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)

Mark40 · January 13, 2016, 5:29am

Other errors that I think are related:

2016.01.13 07:09:45 org.jivesoftware.openfire.spi.MINAConnectionAcceptor[socket_c2s_ssl] - Error starting: 5223
java.lang.NullPointerException
at org.jivesoftware.openfire.spi.EncryptionArtifactFactory.getKeyManagers(Encrypti onArtifactFactory.java:57)
at org.jivesoftware.openfire.spi.EncryptionArtifactFactory.getSSLContext(Encryptio nArtifactFactory.java:91)
at org.jivesoftware.openfire.spi.EncryptionArtifactFactory.createServerModeSslFilt er(EncryptionArtifactFactory.java:249)
at org.jivesoftware.openfire.spi.MINAConnectionAcceptor.start(MINAConnectionAccept or.java:123)
at org.jivesoftware.openfire.spi.ConnectionListener.start(ConnectionListener.java: 217)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl.startListeners(ConnectionMa nagerImpl.java:279)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl.access$000(ConnectionManage rImpl.java:49)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl$1.pluginsMonitored(Connecti onManagerImpl.java:269)
at org.jivesoftware.openfire.container.PluginManager.firePluginsMonitored(PluginMa nager.java:532)
at org.jivesoftware.openfire.container.PluginManager.access$800(PluginManager.java :68)
at org.jivesoftware.openfire.container.PluginManager$PluginMonitor.run(PluginManag er.java:1047)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301 (ScheduledThreadPoolExecutor.java:178)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Schedu ledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)

Chris95 · January 13, 2016, 10:41am

The problem seems to be widely spread… I have the same issue under Windows after the upgrade…

Upgrade from 3.10.3 to 4.0.0 completly messed up system

Mark40 · January 13, 2016, 6:14pm

yeah - its seems like it should be easy to fix. It looks like a simple property or config entry. Would be great if the dev team could provide some direction on how to fix this. In the mean time we going to move ahead without openfire on our project and just use jitsi video bridge on its own.

Frank_Shapn · January 13, 2016, 6:54pm

sounds like you may have installed a SSL cert?

try copying over your OLD_OPENFIRE/resources/security/* files (truststore client.truststore and keystore) to your new installation, and restart Openfire.

(you did do a backup first… right?)

Mark40 · January 13, 2016, 7:07pm

Hi Frank,

Thank for the reply. Yes we have a backup but it doesn’t solve the problem for us. Our certificates and keystore are fine. We even recreated the stores just to be safe but still no luck. We have also tried a clean install with the same results. The paths for the “XMPP Client Stores” and “BOSH (HTTP Binding) Stores” under “TLS/SSL Server Certificate” and unpopluted/empty. There appears to be no way to update these paths from the web gui as the input boxes are disabled.

When trying to do anything with the certs, like trying to generate a self signed cert. results in an error. This is for the entries with missing paths. The other entries work fine and display the keystore certs and truststore certs as well.

How can I update the config for the missing paths?

thanks

Michael_Schlueter · January 14, 2016, 1:46am

Hi Mark,

it took me a few hours but now it works again with openfire 4.0. Log into the webadmin interface. You need to add the following properties manually to the system properties:

xmpp.socket.ssl.client.keypas -> your password for the keystore

xmpp.socket.ssl.client.keystore -> the location of the keystore (for it is /usr/share/openfire/resources/security/keystore)

xmpp.socket.ssl.client.trustpass -> your passwort for the truststore

xmpp.socket.ssl.client.truststore -> the location of the truststore (for it is /usr/share/openfire/resources/security/truststore)

Cheers, Michael

JoHnY2 · January 14, 2016, 12:43pm

Thank you! I had the same issue, this has fixed it.Problem with upgrade to 4.0.0

By the way, the truststore, at least on my server, does have the default java truststore password, “changeit”. Since it is just a small private installation with several users, I wasn’t particularly paying attention to security, so I don’t know if openfire was asking to specify the truststore pass at the time of the installation but I have ignored it or if it couldn’t be specified in older versions.

Mark40 · January 14, 2016, 4:41pm

works for me too - thanks Michael. Didn’t notice those properties were blown away during the upgrade when you use your own certificates. It also seems the paths are removed when you delete the default self-signed certs to add your own in a fresh install.

Cheers

Michael_Schlueter · January 14, 2016, 8:12pm

Did some more tests with @Daryl Herzmann today. Most probably only the properties for the passwords are needed:

xmpp.socket.ssl.client.keypass -> your password for the keystore

xmpp.socket.ssl.client.trustpass -> your passwort for the truststore

guus · January 15, 2016, 10:54am

If no explicit paths are defined for a particular store, a fallback mechanism should have kicked that would eventually cause the (paths to be used from the) Server Federation Stores. I’m somewhat puzzled by the fact that those properties were not empty for you, while other paths were.

Sadly, none of the stack traces that are already in this discussion relate to the root cause of the problem (instead, they describe a result). I’d be interested in other stack traces, which are likely logged around the time that Openfire started. I suspect (but am not sure) that the ones that I am after include any of these as part of the error message:

Unable to instantiate identity store for type

or

Unable to instantiate trust store for type

If you could provide those, that would be helpful. I’m also interested in a scenario that I can create locally to reproduce the problems. Thoughts?

Michael_Schlueter · January 15, 2016, 5:37pm

Hi Guus,

here are the first stack traces after starting openfire:

2016.01.14 00:49:42 WARN [main]: org.jivesoftware.openfire.keystore.CertificateStoreManager - Unable to instantiate identity store for type ‘SOCKET_C2S’

org.jivesoftware.openfire.keystore.CertificateStoreConfigException: Unable to load store of type ‘jks’ from file ‘/usr/share/openfire/resources/security/keystore’

at org.jivesoftware.openfire.keystore.CertificateStore.(CertificateStore.jav a:83)

at org.jivesoftware.openfire.keystore.IdentityStore.(IdentityStore.java:47)

at org.jivesoftware.openfire.keystore.CertificateStoreManager.initialize(Certifica teStoreManager.java:50)

at org.jivesoftware.openfire.XMPPServer.initModules(XMPPServer.java:566)

at org.jivesoftware.openfire.XMPPServer.start(XMPPServer.java:453)

at org.jivesoftware.openfire.XMPPServer.(XMPPServer.java:169)

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessor Impl.java:57)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructor AccessorImpl.java:45)

at java.lang.reflect.Constructor.newInstance(Constructor.java:526)

at java.lang.Class.newInstance(Class.java:383)

at org.jivesoftware.openfire.starter.ServerStarter.start(ServerStarter.java:105)

at org.jivesoftware.openfire.starter.ServerStarter.main(ServerStarter.java:56)

Caused by: java.io.IOException: Keystore was tampered with, or password was incorrect

at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:772)

at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:55)

at java.security.KeyStore.load(KeyStore.java:1226)

at org.jivesoftware.openfire.keystore.CertificateStore.(CertificateStore.jav a:77)

… 12 more

Caused by: java.security.UnrecoverableKeyException: Password verification failed

at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:770)

… 15 more

2016.01.14 00:49:42 WARN [main]: org.jivesoftware.openfire.keystore.CertificateStoreManager - Unable to instantiate trust store for type ‘SOCKET_C2S’

org.jivesoftware.openfire.keystore.CertificateStoreConfigException: Unable to load store of type ‘jks’ from file ‘/usr/share/openfire/resources/security/truststore’