I’'m trying to configure SSL connections (both admin console and xmpp). Something wierd is going on.
I followed the SSL Config guide and I must have missed a step because here are the problems I ran into.
- First, since some sort of SSL demo seemed to be configured in 2.1.2, I tried to bring it up on the following URL:
Well Mozilla went batsh*t at that point, complaining about invalid certs blah blah blah… I told it to just ignore that and trust the machine. It refused to connnect anyway saying that the cert was invalid.
“Okay”, says I, “It must want a real cert installed by a someone it trusts.” I decide to cut a nice clean self-signed cert and then get it signed by Entrust (their free 60 days trial). Entrust signed it and seemed happy. I followed the directions to import the cert into the resources/security/keystore file.
When I tried to import the Entrust signed cert into keystore, keytool complained that it couldn’‘t track the keychain back to a trusted signer. I looked up some Java docs and I apparently had to import Entrust’’’‘s signer cert into my ‘‘cacerts’’ file in /usr/java/jre1xxx/lib/security/cacerts. WTF? Isn’‘t Entrusts public signing cert already in the ‘‘cacerts’’ file. Isn’‘t that the point of having trusted authorities? I listed the authorities in the ‘‘cacerts’’ file and there were actually several Entrust certs. Interesting. Apparently my demo cert was not signed by one of them. I told keytool to dump out my signed cert and, low and behold, the signing authority (OU) was actually ‘‘Entrust Demo’’. I guess that’‘s so I can’'t use it in production (even for 60 days).
Well, that’‘s kind of goofy. If I wanted to play that trust game then I would have just put my own org signer cert in there. Well, lets just hope that the kiddies out there with PSI or Miranda have software that will either trust ‘‘Entrust Demo’’ or I’'ll end up buying one of their real certs.
Anyway, I download the ‘‘Entrust Demo’’ root cert and installed it into ‘‘cacerts’’ and then sucessfully imported my ‘‘Entrust Demo’’ signed cert into ‘‘keystore’’. Whew…
(God, no wonder PKI infrastructures failed so miserably).
keytool said that I then had three certs. (a) The original one for 127.0.0.1, (b) My self-signed cert and © My cert as signed by Entrust.
Everything fine so far. I changed the keystore password to one of my choosing. Changed the password for ‘‘cacerts’’ into the same thing. Then, following the rest of the directions in the SSL Guide, I went into Messenger and set the Java variables to the correct password values etc. BTW: The “Guide” is a little vague on certain issues like the keystore format “JKS” is the only format they discuss. Is there some other format that we would be using at that point? If you bring up that subject, you really should put it to bed lest we wonder if that is the root of our malfunctions.
Okay. All values set correctly (hopefully), and all certs signed, sealed and delivered.
I restart Messenger so it can pick up all of this SSL goodness. I go to the SSL settings page just to verify all of the setting took. Ooops. No SSL settings page. Just blank.
Thinking that I truly hosed some variable up I search for answers. Nothing obvious in the logs except some vague security errors. Unfortunately, since the SSL setting variables are in the SSL settings page and the SSL setting page refuses to come up, I’'m a little screwed.
I shutdown Messenger and hunt through the config files for the value of the SSL variables. Not particularly looking forward to hand editing XML files, but JED has a nice XML mode so no biggie.
The SSL setting parameters are nowhere to be found and I begin to suspect that they are in the database somewhere. Maybe / maybe not, but I’'m running out of time and my double-cheeseburger is getting cold as are my fries. (hint: never eat cold McFries, yeech
Since I’‘m in the early config stages on Messenger, I figure it’'s easier to re-install.
I save my certs and keystores, rm -rf jive-messenger, re-install jive-messenger, do a couple two-steps, save the fresh keystore as keystore.bak and restore my old keystore. I reset the keystore password back to default ‘‘changeit’’ and startup Messenger again.
Connect to http://localhost:9090, login and run through the inital setup. Everything is fine, fresh install, so I go to the ‘‘SSL Settings’’ page, fully expecting to be rewarded with lots of interesting keystore setting and information. No joy. Same blank page. ??? hmmmm…
The only thing thats not the same is the keystore file. I move the keystore file to keystore.new, move the virgin keystore.bak file back to ‘‘keystore’’.
I restart Messenger and now everything is fine. The SSL Settings page is back where it belongs.
Unfortunately I’'m back to square one.
I assume the keystore file is hosed. I suspect one of two things…
a. You should delete the entry in keystore for ‘‘127.0.0.1’’ …or…
b. The test machine I’‘ve deployed Messenger on is called, say, ‘‘test.mycompany.com’’. My signed cert is created for ‘‘im.mycompany.com’’ and I have a dns CNAME that points to the same IP as test.mycompany.com. When I did the most recent install of Messenger I told the setup wizard that the host’‘s name was ‘‘im.mycompany.com’’. I’‘m not sure why that would screw things up because at that point Messenger thinks the host’'s name is ‘‘im.mycompany.com’’ which the OS and DNS believe is the proper alias name for test.mycompany.com. This also agrees with the cert that was generated.
I guess somewhere in all this I may have fat fingered the name, but for the life of me I can’'t figure out why Messenger refuses to bring the SSL settings page up.
Only other thing I’'ve considered is that I installed Messenger as the ‘‘jive’’ user in /opt/jive-messenger (as the home directory for jive).
All the files under jive-messenger are owned by ‘‘jive’’.
I do this for security reasons in the unlikely event that we get a buffer overflow from some hacker.
(gotta cover my bases)
Anyway, any help is greatly appreciated.