Trouble with (private) CA signed certificate

Openfire Openfire Support
1

Hi,

I’m having some trouble with openfire accepting my signed certificate. I took the following steps:

(using keystore found in /usr/share/openfire/resources/security)

  1. made a backup of old keystore file )

  2. deleted standard RSA/DSA from keystore

  3. imported my root CA : keytool -import -trustcacerts -alias root -file mroot.crt -keystore keystore

  4. generated certificate using : keytool -genkey -keystore keystore -alias fqdn -keyalg RSA

  5. made a certificate request : keytool -certreq -keystore keystore -alias fqdn -file certificatefile.req

  6. imported the request and signed it using my own root ca

  7. copied and imported the signed certificate : keytool -import -keystore keystore -alias fqdn -file signedrequest.pem

keytool -list -alias fqdn shows private key entry for the proper hostname.

after server restart however I get the following error when looking at the certificate requests in the admin console : java.security.InvalidKeyException: Supplied key (null) is not a RSAPrivateKey instance

I’m not really sure how openfire goes about determining which certificate to use, but the both the cn and alias match the openfire servername

any advice would be greatly appreciated,

Kind regards

Jeroen Wilke

1 Like
2

This is quite odd, when I log on into the https admin console, and look at the certificate, it shows me the proper certificate signed by my own ca. When I look at all my clients, they are now all using encrypted communication.

It’s just when I press “server certificates” in server settings that I get the “**java.security.InvalidKeyException: Supplied key (null) is not a RSAPrivateKey instance” **error.

so a.t.m. it does seem to be working, in spite of the error I get when trying to display the certificates via the web console…

3

I have prepared a patch for this, there is also a workaround - you should delete all certificiate entries not associated with private key from the keystore - see

1 Like
4

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?

Thanks!

Bill