Server Certificates "corrupt" every time when restarting Openfire

Openfire Openfire Support
1

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:

cc7365574f58b6daa40f8dcff08b6f2e keystore (before restart)

cc7365574f58b6daa40f8dcff08b6f2e keystore (after restart)

If I create Server Certificates via the Admin Console, they are generated and clients can login again. We do not use CA signed ones, only self signed.

Now the question is, why is this happening? Am I missing something configuration-wise here? Many thanks in advance!

2

alpineweiss,

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 ?

daryl

3

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.

4

alpineweiss,

This still sounds like a file permission issue. What user is running the openfire server? Did you do a RPM install? Try running

rpm -V openfire

and see if it reports anything

daryl

5

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.

Any suggestions will be greatly appreciated.

6

Hello,

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.

Cheers

-Alpinweiss-

7

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.

My error log looks like so:

2008.08.16 13:54:07 [org.jivesoftware.openfire.net.SSLConfig.(SSLConfig.java:104)] SSLConfig startup problem.
storeType: [JKS]
keyStoreLocation: [/usr/share/openfire/resources/security/keystore]
keypass: [changeit]
s2sTrustStoreLocation: [/usr/share/openfire/resources/security/truststore]
s2sTrustpass: [changeit]

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)

8

Still having the same issues after upgrading to 3.6.2.

The logs and permissions are the same. Any ideas?

9

Solution for me was such:

  1. Delete certs in AdminWEB interface.

  2. Restart openfire

  3. Delete /opt/openfire/resources/security/keystore file

  4. Generate new cert from web interface.

10

I have the same problem with 3.6.4 on debian using posgtres.

permissions are 644 on /usr/share/openfire/resources/security/keystore and owned by user openfire who is the user that openfire runs with.

I tried the fix suggestion below but it will not work for me.

Cheers!

11

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?

12

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…

~cb

13

I think this should be related to OF-30 and fixed in the next release.

14

Is it safe to use your patch on top of the latest release tarball? If so I will updated the openSUSE rpms so that others don’t face this issue…

15

Hi Peter,

yes, I’ve attached a patch which should work with the Openfire 3.6.4 src tarball.

Best regards

Guenther

16

I have the same issue as the OP, however the property ‘xmpp.socket.ssl.keypass’ does not exist?

Should I add it?

17

I set up SSL using the process described here:

http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/ssl-guid e.html

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…

can I make the answer any more vague for you?

~cb

18

If you are running on SUSE please make sure that you use updated openfire packages from:

http://download.opensuse.org/repositories/server:/messaging/


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.

19

No there is no symlink…

I’m running Centos 5.4 and the RPM version as downloaded from this website…

20

Hi all,

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 tryied everything wrote here without success.