in 3.7.0 there is still the same problem.
after restart of the server - sometimes it works - sometimes not…
is the batch above also usable for 3.7.0??
thx
christopher
I upgradet to 3.7.1 - same problem again…
solved the problem.
do not use IBM-java!!
use sun-java instead and everything works fine…
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…
Hi,
Just to say: me too, using up-to-date package:
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.
Should/could someone (me?) file a bug somewhere?
Only a few dedicated users can file bugs.
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)?
Except the “truststore deletion” part, looks the same, also got “java.io.IOException: Keystore was tampered with, or password was incorrect” message afterwards. I have tested on a test environment, clean install, just created the self-signed certs on Openfire web gui, restart http server clicking where suggested on GUI and certs are gone - as far as the gui can tell me, did not check on filesystem.
root@cloud:~# java -version
java version “1.7.0_75”
OpenJDK Runtime Environment (IcedTea 2.5.4) (7u75-2.5.4-1~precise1)
OpenJDK 64-Bit Server VM (build 24.75-b04, mixed mode)
root@cloud:~#
Edit: no symlinks on /etc/openfire/security, but found this one:
/usr/share/openfire/resources/security -> /etc/openfire/security/
Never enough to stress that openfire user has R/W permissions on all files under /etc/openfire.
Thanks for you attention.
I don’t have Ubuntu LTS version at hand. Only have a VM with Ubuntu 14.10. It has Oracle’s Java 1.7.0_21 installed and i have also tested with Oracle’s 1.7.0_51 which i have extracted from Spark tar.gz package - Ignite Realtime: Download Landing I have also downloaded tar.gz package of Openfire 3.9.3, extracted it and tested both with the system Java and with jre folder from that Spark package, which i copied inside the Openfire folder. Was using the embedded database variant. In both runs i didn’t had issues with corrupted certificates after the server restart.
Can you test at least in your testing environment by copying jre folder from Spark package into your Openfire folder (it then should use it instead of the system’s OpenJDK, you can check this on the start page of Admin Console)?
Hi,
Have tested some variations including your suggestion and found out that the problem lies on my actual MySQL DB. In all attempts I was deploying a new machine but using the same remote MySQL server, with actual data on it. When I forgot that DB and went to internal DB (no MySQL) everything works as expected no matter what Ubuntu version, apache restart, machine reboot, etc.
I will still test with an empty MySQL DB to see what happens, but could you please speculate what can be wrong on my actual data? What relation exists between certificates and any data stored on MySQL?
Thanks, best regards.
Well, i don’t know what in the database could have such effect. But i was testing only with the embedded one option (have no MySQL database to test with, embedded db is the simplest/fastest way for me to test).
Hi, thanks,
So I ended up reinstalling openfire on the original server ignoring actual database and using internal DB instead, solved. Thanks for your time.
Regards.