More "Fun" With SSL/TLS Certs

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.

  1. 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:

https://localhost:9091

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.

  1. “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.

  2. 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).

  1. 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.

  2. 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.

  3. Okay. All values set correctly (hopefully), and all certs signed, sealed and delivered.

  4. 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.

  5. 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.

  6. 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.

  7. 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

  8. Since I’‘m in the early config stages on Messenger, I figure it’'s easier to re-install.

  9. 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.

  10. 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…

  11. 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’’.

  12. 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.

Thanks,

Jim Burnes

Security Engineer

Great-West

Hey Jim,

Thanks for the very detailed description of your steps.

When doing step 5 have you changed the entries’’ password as well? Remember that if you change the keystore password you will need to change the entries’’ password as well. If that is not the problem it will be of help to get the error that you have in the log files.

Regards,

– Gato

When I ran into some of these same symptoms, two causes that I isolated were:

  1. Incorrect ownership of the keystore file

  2. Browser incompatibility

Those are quick checks to perform.

Well I think I’'ve found the problem.

Sometimes, in desperation, I take the error message that the system gives me and I paste it, word for word, into Google and hit ‘‘search’’.

This time it worked. The original message was something about the server cert being invalid or corrupt. I got back something I hadn’'t expected.

Apparently it’'s possible to accidentally trash your local cert databases in your .mozilla/default directory. Those files are named *.db.

I tried this after installing a fresh copy of Firefox to no avail.

So I just moved .mozilla to .mozilla.old and restarted it.

Here is where I’'m getting a little fuzzy. The first thing I tried after that was:

https://localhost:9091.

That broke after my browser complained about the default cert owned by “John Doe” or something.

Then, having forgotten that I hand’'t re-installed my signed cert, I connected to:

https://im.mydomain.com:9091

And it worked like a charm (well after complaining that it doesnt know who signed the John Doe key).

Strange. Apparently something had hosed up my *.db files a while ago.

Just thought I’'d let your guys know. Who knows who might try to connect via a mozilla-based browser with a set of trashed *.db files.

Good luck and thanks for the help.

Jim Burnes

Great-West

Denver

More information on this strange problem.

I’'ve now got a basic Messenger install running under 2.1.2 using a remote SSL Firefox browser on Windows.

I connected just fine once and did my usual admin duties. I think the problem occurs because when you connect to the real name of the server (on my system im.<mydomain.com> ), you are presented with the 127.0.0.1/Joe Doe cert. You can accept this cert even though the name doesn’'t agree with the name of the server.

I believe this corrupts the cert in the Firefox *.db files. I’'m not sure of this, but it looks likely. After it does so, Firefox refuses to connect.

Probably the best way to deal with this is to not attempt to connect to to Messenger via SSL until you remove the default 127.0.0.1 cert.

I’'ll try again and let you know what happens.

JB