Our self-signed certs for Openfire expired a few days ago … I was struggling with getting SSL setup right, and have to say this thread, especially Jeroen’s steps 0-5, helped me most.
After backing up keystore and truststore , I created a new keystore / private key, generated and submitted a (RSA/2048) CSR, received a signed crt and intermediate/root.cer from our CA - I imported the PKCS#7 version of the signed crt.
To import the signed crt, the intermediate/root needed to be in the keystore first (on import, keytool said it was already there, you still say yes to import). One other thing this thread helped with is, the signed crt is imported to the same alias as the private key (I was not doing this initially, and of course SSL was not working properly).
When using the same alias as the private key, when importing the signed cert, keytool responds in a way that let’s you know the reply was added properly, to create a pair. Keytool list will show only the PrivateKeyEntry and Certificate fingerprint for the alias.
The intermediate/root cert is added to the truststore. Again, I think keytool says it’s already there, but add it anyway.
Additionally, removing the root alias from the keystore (after importing the signed crt), as Marcin mentioned, fixes / works around the GUI / “Supplied key (null) is not a RSAPrivateKey instance” exception.
After server is shutdown, replace old keystore and truststore with new ones. Restart.
One other thing I did, since some of our users setup their clients with UID@domain.tld and some with UID@openfire-hostname.domain.tld, is sign the CSR with domain.tld as CN and with a Subject Alternative Name of openfire-hostname.domain.tld. Our xmpp client & server DNS records for domain.tld point to openfire-hostname.domain.tld.
A multi-domain cert (e.g. with Subject Alternative Name) was necessary because in the case of UID@domain.tld client setups, a cert for only openfire-hostname.domain.tld caused a certificate warning in Pidgin, among possible others. With domain.tld as CN and openfire-hostname.domain.tld as Subject Alternative Name, the warning disappeared. Additionally, the web interface cert is 100% trusted because of the Subject Alternative Name.
I didn’t need to install the Java Cryptography Extension (JCE). I am using JDK 1.6.0 and running Openfire 3.7.1.
One thing I wonder about, do any XMPP clients rely on a DSA cert? I have yet to generate the DSA self-signed cert in the admin interface, and so far, everything seems good.
Our CA is only setup for 2048, and I think DSA with keytool maxes at 1024?, so it’s unlikely I could get the DSA CSR verified / signed by our CA.
Any other reason the DSA cert would be required?