What could be the reason when restarting Openfire 3.5.0 the Server Certificates are “corrupted”? Obviously the client logins will not succeed since TLS/SSL is required in client end.
When having closer look into the Admin Console, in Server Settings => Server Certificates there is an error message:
Unable to access certificate store. The keystore may be corrupt.
One or more certificates are missing. Click here to generate self-signed certificates or here to import a signed certificate and its private key.
In /opt/openfire/resources/security the keystore file is present (before and after restart) and the md5sums are exactly the same than before restart:
This really sounds like a file permission issue. Does the user that runs Openfire have write access to your files in /opt/openfire/resources/security ?
File permissions are not the issue - checked that of course before posting this issue User who is running Openfire has RW rights to /opt/openfire/resources/security directory.
As said, every time I restart the server using /etc/init.d/openfire start|stop I need to generate the server certificates. I have done this via web GUI.
I have been experiencing the same behavior. Initially with 3.5.0 and now with 3.5.1
rpm -V openfire reports the following:
S.5…T c /opt/openfire/conf/openfire.xml
S.5…T c /opt/openfire/resources/security/keystore
S.5…T c /opt/openfire/resources/security/truststore
I’m guessing the keystore/truststore/openfire.xml files are showing up b/c they are probably the only files that have been modified (openfire configuration and regenerating the key the server can’t access). Clients are not securing connections when the error ocurs.
I have created specific user regarding our user management policy. This user has been configured to /etc/sysconfig/openfire to OPENFIRE_USER directive. This same user has rw rights to /opt/openfire/resources/security. Openfire was installed from RPM, Linux kernel version is 2.6.9-55.ELsmp and using Sun Java 1.6.0_05-b13.
Having the same problem with openfire 3.5.2 installed under debian. I don’t really care about certificate, the built in ones are good enough. But they don’t work.
I’ve checked my permissions to /etc/openfire/security/keystore.
The openfire user has rw rights, openfire is the user underwhich java is running.
Additionally, when I create a new certificate from the GUI, the keystore file is created or updated. So I know it has write permissions.
2008.08.16 13:54:08 [org.jivesoftware.openfire.container.AdminConsolePlugin.startup(AdminConsolePlu gin.java:121)]
java.io.IOException
at org.jivesoftware.openfire.net.SSLConfig.getKeyStore(SSLConfig.java:267)
at org.jivesoftware.openfire.container.AdminConsolePlugin.startup(AdminConsolePlug in.java:96)
at org.jivesoftware.openfire.container.AdminConsolePlugin.initializePlugin(AdminCo nsolePlugin.java:170)
at org.jivesoftware.openfire.container.PluginManager.loadPlugin(PluginManager.java :448)
at org.jivesoftware.openfire.container.PluginManager.access$300(PluginManager.java :47)
at org.jivesoftware.openfire.container.PluginManager$PluginMonitor.run(PluginManag er.java:1014)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:280)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:135)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101 (ScheduledThreadPoolExecutor.java:65)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodi c(ScheduledThreadPoolExecutor.java:142)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Schedu ledThreadPoolExecutor.java:166)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java: 650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
2008.08.16 13:54:48 [org.jivesoftware.openfire.http.HttpBindManager.createSSLConnector(HttpBindMana ger.java:158)] Error creating SSL connector for Http bind
java.io.IOException
at org.jivesoftware.openfire.net.SSLConfig.getKeyStore(SSLConfig.java:267)
at org.jivesoftware.openfire.http.HttpBindManager.createSSLConnector(HttpBindManag er.java:134)
at org.jivesoftware.openfire.http.HttpBindManager.configureHttpBindServer(HttpBind Manager.java:258)
at org.jivesoftware.openfire.http.HttpBindManager.start(HttpBindManager.java:90)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl.startHTTPBindListeners(Conn ectionManagerImpl.java:523)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl.startListeners(ConnectionMa nagerImpl.java:136)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl.access$000(ConnectionManage rImpl.java:54)
at org.jivesoftware.openfire.spi.ConnectionManagerImpl$1.pluginsMonitored(Connecti onManagerImpl.java:108)
at org.jivesoftware.openfire.container.PluginManager.firePluginsMonitored(PluginMa nager.java:533)
at org.jivesoftware.openfire.container.PluginManager.access$800(PluginManager.java :47)
at org.jivesoftware.openfire.container.PluginManager$PluginMonitor.run(PluginManag er.java:1024)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:280)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:135)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101 (ScheduledThreadPoolExecutor.java:65)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodi c(ScheduledThreadPoolExecutor.java:142)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Schedu ledThreadPoolExecutor.java:166)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java: 650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
I also have the same problem with openfire 3.6.4 running with PostgreSQL on SLES 11. I have tried both sun and ibm versions of java just in case it was an issue with the ibm jvm that install by default on SLES but it didn’t make any different. I have checked the file permissions and they are fine (writable by the openfire user) and keytool correctly shows that certificates in the keystore. Any ideas?
I found a work around to this issue (worked for me anyway). I am running openfire 3.6.4 on Ubuntu 9.10 (used the .deb install package) with a MySQL backend.
Apparently - whever the server is stopped it alters the variable that stores the password for the keystore (xmpp.socket.ssl.keypass).
At first I was able to just go into the Web front-end and choose to edit that from the System Properties page (just clicking edit and save did the trick). Once that worked out I added a mysql script to the start/stop script so that it would happen automatically (I ran the mysql script at both stop and start just to cover my bases).
The MySQL code I used is contained in a file called ‘openfire_reset_keystore.sql’ (using the default value of changeit for the keystore pass). That code is below:
##code to reset openfire keystore
update openfire.ofProperty set openfire.ofProperty.propValue = ‘changeit’ where openfire.ofProperty.name = ‘xmpp.socket.ssl.keypass’
and the Ubuntu upstart script was modifed as such:
case “$1” in
start)
echo -n "Starting $DESC: "
mysql -u openfire -pYOURPASSWORD openfire < /etc/init.d/openfire_reset_keystore.sql
start
echo “$NAME.”
;;
stop)
echo -n "Stopping $DESC: "
stop
mysql -u openfire -pYOURPASSWORD openfire < /etc/init.d/openfire_reset_keystore.sql
echo “$NAME.”
;;
Hopefully this helps - I can clarify if necessary.
I’m not much of a java junkie so I haven’t tried to trace back where the error actually occurs, but hopefully a developer is monitoring this thread…
and in the process changed the keystore password from changeit to something else.
I actually haven’t tried it with the default password, so I have that variable set already - but my guess is even if you set the variable to changeit - it shouldn’t hurt…and I would also suspect that leaving it unset would work as well…
These packages have the patch applied, and also have recently had an issue fixed regarding the keystore incorrectly being a symlink to the client truststore (caused by fdupes) which was confusing openfire. (See thread at http://www.igniterealtime.org/issues/browse/OF-30 for more details). If you have such a symlink on an existing installation, please delete it and regenerate your SSL certs.
I have the same issue. But after trying a lot of things what I did, after a restart, was to recreate the self signed certificates.
But the last time also this was wrong.
In fact looks true that something is wrong with the trustore file. What I did now was backuop the old file and touch a new one. After this it worked again. But If I try to stop the server the problem comes again.