Openfire 3.5.0: reboot causes server to lose track of keystore

Just upgraded to Openfire 3.5.0 and generally like what I see. However, there is one very problematic issue I have having. Any time the server is rebooted, the server can no longer find the SSL/TLS keystore. This means that every time the server is rebooted, I have to regenerate new self-signed certificates through the admin console.

The host server is a virtual machine (VMware ESX 3.x) running CentOS 5 linux.

I cannot seem to get the server to see any certificates that I generate using keytool. Nor am I able to import any certificates using the import-certificate.jsp. Therefore, I am in a situation where I can only get TLS to work with self-signed certs that go away the moment the server reboots.

Will someone please let me know what is going on here and how it can be resolved.

Andy

Hi Andy,

Are you seeing any messages come to the Openfire log files? My guess is that your openfire instance is running as a different user than who owns the keystore file.

daryl

I have this exact problem as well. It began when I uninstalled the deb on ubuntu hardy and reinstalled to clear up all the conf files. I was testing it out and didnt like the embedded db so I nixed the install and reloaded the deb. It runs on a mysql 5 server now and ever since I can init the keystore when I start up and it will work until I /etc/init.d/openfire restart. So until then I cannot use ssl mode. My goal is to completely disable the HTTP admin console and require SSL only connections to the server. This is for ver 3.5.1.

It appears that after installing openfire on another test box, that the box I have an issue with did NOT create client.truststore AND truststore is 0 bytes. Any possible fixes or suggestions to try?

For some reason the reinstall did not create the client.truststore or truststore files properly. I mearly cp’d them from another successful installation, checked that the certs where right in the “Server Certificates” section of the admin console and it was. This was MY workaround. Still the install and setup process should have corrected this which it did not. Must be a bug in the .deb, so who ever maintains that may want to dig a bit.