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.
I had troubleshooted a similar scenario in red hat linux environment, the keystore corrupted on every repeated restart of my app. We did a linux spin up and rebounced all the linux servers, and then the issue disappeared…
Linux cloud 3.2.0-77-generic #112-Ubuntu SMP Tue Feb 10 15:22:22 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION=“Ubuntu 12.04.5 LTS”
I am using openfire_3.9.3_all.deb, MySQL database with LDAP auth backend and I get exactly the same result as Samuli got 8 years ago!!! Openfire user does have R/W permission to keystore, truststore, security folder, etc. Whenever I restart openfire: the self-signed (openfire created) certs are gone.
Before filing new one, it should be investigated further, to try to find out what the real cause is. Do you get the same error as reported on [OF-30] Fix generating of the self-signed certificates after truststore deletion - Jive Software Open Source ? I’m not savvy with Linux, but can this be a symlink problem as reported above? What Java is in use (Oracle’s, OpenJDK)?