Certificates yet again

I’'ve found quite alof of threads about certificates and how to import them. Though none of them contain a solution to my problem as far as I can tell.

I have an RSA private key and a certificate signed by my own CA. I use this route as it is easier to maintain than self-signed certificates. I use OpenSSL for generating the csr and signing it. Let’'s say the domain is gazonk.example.com and that the server is jabber.gazonk.example.com.

I get the same error as many others:

“No available certificate or key corresponds to the SSL cipher suites which are enabled.”

  1. imported my ca certificate. keytool -import -trustcacerts -keystore keystore -alias myrootcert -file /etc/ssl/certs/myrootcert.pem

  2. generated the csr. I did set CN to the domain.

  3. signed the csr

  4. imported the certificate: keytool -import -keystore keystore -alias gazonk.example.com -file /etc/ssl/misc/jabber.gazonk.example.com.pem

  5. pasted said certificates in the web interface

  6. removed the John Doe certificates.

  7. restarted wildfire

  8. “No available certificate or key corresponds to the SSL cipher suites which are enabled.”

I have read information that claims that the web interface breaks the keystore but I don’'t know any other way to edit the information. Alot of the information in general found about this issue on the forums seem to relate to much older versions with other problems.

I believe this is the same as Jadestorm wrote in http://www.jivesoftware.org/community/message.jspa?messageID=117808#117808 with the difference that I get errors. How do I proceed?

Even though it seems unlikely I believe wildfire took all the spare cpu power I had left.

I tried restarting Wildfire but it immediately consumed 100% cpu even after a few minutes when everything should be started. I reverted the keystore to the John Doe certs and next restart it was down to normal again.

I had the exact same problems a few weeks ago, and had to revert the total keystore if i wanted Wildfire to work again. The procedure i followed was the same as yours. So basically, i’'m also bacrk on the John Doe certs, and am unable to provide SSL to my users.

Me too, same thing. I am trying to use m own CA. No luck … but I don’'t get 100% CPU either.

It seems the Keyman tool from IBM is the way to do it.

Some hints for how I did, it might be easier ways but this worked. I used the demoCA in OpenSSL.

  1. generate a new CA or use your existing

  2. request a new certificate, set CN to your jabber domain.

  3. sign the request. You now have key and certificate in PEM format.

  4. convert to pkcs12: openssl pkcs12 -export -out cert.p12 -inkey newkey.pem -in newcert.pem

  5. download keyman from http://www.alphaworks.ibm.com/tech/keyman

  6. start keyman and open the wildfire keystore

  7. delete the John Does certificates

  8. import your CA certificate

  9. import cert.p12

  10. save the keystore (it seems you have to do 7-9 in that order or else you will not be able to save the keystore)

  11. don’'t touch anything regarding to the certificates in the web interface

  12. restart wildfire

  13. log in!

Hopefully that was all that was needed but if someone who had the same problem could verify it before marking it as answered then it would be great.

Here’'s a simple shell script I use after each wildfire upgrade to generate self-signed certificate (based on ssl-guide in wildfire docs):

#!/bin/bash

cd /opt/wildfire/resources/security

  1. This removes default John Doe certs (default keystore password is ‘‘changeit’’)

echo “Deleting default certificates…”

/opt/wildfire/jre/bin/keytool -delete -keystore keystore -alias rsa

/opt/wildfire/jre/bin/keytool -delete -keystore keystore -alias dsa

  1. single RSA cert seems to be enough

echo “Creating new RSA certificate…”

/opt/wildfire/jre/bin/keytool -genkey -keystore keystore -alias wildfire.hostname.tld -validity 720 -keyalg rsa

Today, suddenly it didn’‘t work any longer. I copied in the keystore I had in backup. Didn’‘t change anything. I recreated the keystore. Didn’'t change. The odd thing is that the web admin interface uses the same certificate and in that context it seems to be possible to read the certificate. The error log contains this (passwords changed)

2006.07.16 09:30:14 [org.jivesoftware.wildfire.net.SSLConfig.(SSLConfig.java:76)] SSLConfig startup problem.

storeType:

keyStoreLocation: /opt/wildfire/resources/security/keystore

keypass:

trustStoreLocation: /opt/wildfire/resources/security/truststore

trustpass:

java.io.IOException: Keystore was tampered with, or password was incorrect

at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:768)

at java.security.KeyStore.load(KeyStore.java:1150)

at org.jivesoftware.wildfire.net.SSLConfig.(XMPPServer.java:145)

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessor Impl.java:39)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructor AccessorImpl.java:27)

at java.lang.reflect.Constructor.newInstance(Constructor.java:494)

at java.lang.Class.newInstance0(Class.java:350)

at java.lang.Class.newInstance(Class.java:303)

at org.jivesoftware.wildfire.starter.ServerStarter.start(ServerStarter.java:88)

at org.jivesoftware.wildfire.starter.ServerStarter.main(ServerStarter.java:49)

2006.07.16 09:30:14 org.jivesoftware.wildfire.spi.ConnectionManagerImpl.startClientSSLListeners(Conn ectionManagerImpl.java:243) Could not setup SSL socket

java.io.IOException

at org.jivesoftware.wildfire.net.SSLConfig.createServerSocket(SSLConfig.java:148)

at org.jivesoftware.wildfire.net.SSLSocketAcceptThread.(XMPPServer.java:145)

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessor Impl.java:39)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructor AccessorImpl.java:27)

at java.lang.reflect.Constructor.newInstance(Constructor.java:494)

at java.lang.Class.newInstance0(Class.java:350)

at java.lang.Class.newInstance(Class.java:303)

at org.jivesoftware.wildfire.starter.ServerStarter.start(ServerStarter.java:88)

at org.jivesoftware.wildfire.starter.ServerStarter.main(ServerStarter.java:49)

I tried to recreate the keystore with keyman a number of times without success. Eventually I reinstalled wildfire completely (it is a test install after all). Followed the notes I made earlier and suddenly the keystore produced was ok. This time I had managed to copy the keystore away before wildfire tried to read it so next time it happends (it feels like when, not if) I hopefully have a sound keystore in backup.

I can confirm that the keyman solution works. After getting the huge admin-log problem, my steps were:

(I am running my own CA, and have previously generated a certificate for use with wildfire)

0.5) stop wildfire

  1. Deleted all certs from the wildfire keystore

  2. Imported my CA Cert “keytool -keystore /path/to/wildfire/resources/security/keystore -import -file /path/to/file.pem -trustcacerts -alias ‘‘My CA’’”

  3. Generated a pkcs12 from the pem I generated “openssl pkcs12 -export -out cert.p12 -inkey cert.pem -in cert.pem”

  4. started keyman, opened the wildfire keystore, then imported the pkcs12 file (cert.p12 above -^). Then save and exit keyman.

4.5) start wildfire, log in, etc

I’‘m sure you don’‘t need keyman for this, but I’'m not familiar enough with java ssl to know how to do this with keytool. Basically, when I tried to import my server cert with keytool, it kept showing up as a CA cert. When I imported with keyman, it showed up as a private cert (which it should).

Listing my ketystore now shows this (note the “keyEntry” by the first cert, as is referenced in a couple other postings):

Keystore type: jks

Keystore provider: SUN

Your keystore contains 2 entries

_eq5sosk0, Jul 27, 2006, keyEntry,

Certificate fingerprint (MD5): 46:95:64:AA:CA:25:90:C4:0B:EE:8D:09:98:89:36:D8

my ca, Jul 27, 2006, trustedCertEntry,

Certificate fingerprint (MD5): 58:D0:1C:67:72:45:6E:49:96:C9:77:E4:B4:A0:9D:6D

Hope this helps some. Enjoy.

-soc