Hi All,
Specifications:
Openfire 3.10.2 on Windows Server 2012 R2 Std.
StartCom SSL certificate imported and valid
Web access on 9091 functional and certificate presenting as valid
XMPP access on 5222 functional and certificate presenting as valid
I’ve made it to the point where my Openfire installation if functioning for my purposes, and I wanted to lock down the keystore and truststore with a randomly-generated password. I use keytool to change the default password on both the truststore and keystore from ‘changeit’ to a random password generated by KeyPass. Passwords are 16 characters in length with alphanumerics and symbols.
Per the documentation, I modified the xmpp.socket.ssl.trustpass and xmpp.socket.ssl.keypass values from the web console with the passwords I generated from KeyPass. I also selected to encrypt these values.
At this point, after a service restart, the web interface is unavailable on both 9090 and 9091 and XMPP access with or without encryption on both 5222 and 5223 is not functional.
I am seeing the following error in the error logs:
2015.08.23 09:53:13 org.jivesoftware.openfire.session.LocalClientSession - Client session rejected. TLS is required but no certificates were created.
No other logs indicate an error.
My question is twofold:
Is there a syntactical limitation for the keystore password? Can it not contain certain characters or is it limited to a specific length?
And two, how do I reset my server properties to remove the trustpass and keypass values without having access to the web console? I changed the passwords back to ‘changeit’ in the local console, but the web server is still not accessible. It is, however, showing as listening on 9090 in netstat.
Any help would be appreciated.
Update #1:
Foiled by the Windows firewall! I managed to get to the web console on 9090, but now I’m getting HTTP Error 500 Java IO exception after login.
Update #2:
Apparently my initial keystore change back to the default was not successful and the old “complex” password was still intact. I changed the passwords for the keystore and truststore back to the default, and I’m back in the console.
My previous question, however, still remains: is there a limitation for the keystore password?
Update #3
I’m not sure if there’s something programmatically flawed or if I’m doing something improper. I set the keystore password to just a very basic ‘welcome1’ without any success. The same issue occurs each time. Is anyone aware of a problem with protecting the keystore with a password other than the default of ‘changeit?’
At this point, I’m going to leave the functional installation as-is with the defaults.