I have a love/hate relationship with iKeyman. It never seems to want to work the way I think it should.

Take the instance when a customer manages their SSL keys online, and creates the private certs without actually creating a CSR on the host machine. It just gets tricky. iKeyman won’t allow you to import the private key, and if you try to install the new certificate, you’ll get an error along the lines of “No CSR found for Certificate”

What you can do is use 3rd party tools to create a .p12 certificate, then import this into a new .kdb.

So here is my cheat sheet for how I got this working.

1. Extract the certificates from email.
2. Use OpenSSL to create a p12
3. Create a new KDB
4. Import the root certificates, intermediate certificates
5. Import the Personal certificate

Copy the certificates from the email you have been provided. In my case I had the new trusted cert, the Intermediate and I had to get the Private key as well.

Copy the text certificates from the email and create a file with the extensions like the following for each. In my case I had 3, NewCert.key, NewPrvKey.crt and Intermediate.cer.

They will look something like below.

Once you’ve done this, you’ll need access to OpenSSL. I’m on a Mac, so this is installed already.

OpenSSL is accessed via Terminal.

OpenSSL will be used to create a .p12 file so we can import into iKeyman. Use the following command.

openssl pkcs12 -export -name "NewKey" -inkey ~/Desktop/NewPrvKey.crt -in ~/Desktop/NewCert.key -out ~/Desktop/NewCert.p12 -keypbe PBE-SHA1-RC2-40

You’ll be prompted for a password for the .p12 you are creating. Remember this, you’ll need it.

Ok.You’ve now got a .p12 . Transfer this to your IHS server, along with the Intermediate.cer that you created previously.

Fire up iKeyman, I’m running this on my IBM HTTP Server.

Now we are going to –

1. Extract the existing trusted root and intermediates from the old KDB (optional)
2. Create a new KDB
3. Import the Trusted root and intermediates if you need to (optional)
4. Import your private keys

Import the Intermediate Certificate, and also if you required to pull in the other Root Certificates. I’m using TrustiCo so this is the following. I had these already in another keystore, so I just Extracted and then imported from the .kdb I was replacing.

Create a new .kdb, I’m calling mine 2015Key.kdb.

Make sure to stash the “Password to a file”, then hit OK.

Now select “Personal Certificates”

Select “Receive”

Change the Keyfile type to PKCS12 and browse to our .p12 certificate.

Enter your password for the .p12, then change the label to something that makes sense. Hit Apply and OK

This will import the new certificate for your server into the KDB file. If it is the only one, it should automatically be set as the default.

Once done you can then Validate trust (Personal Certificates>Validate). If everything is working, then it should give you a nice “Validation successful” If not, you more than likely don’t have the correct Trust Chain. Go to the vendor of your 3rd party cert and get the correct signer certs.

Then all that is left is change the IHS server config to point to the new key and stash (.kdb, .sth). Restart IHS and you should be good to go..

Just a quick update. I’ve recently been doing some work trying to Auto magically configure Sametime using Managed Settings. This has been a bit of a struggle, but we are getting there.

If you’ve not heard of Managed Settings before, they are a way that you can push out and update Sametime Connect (both embedded and standalone) settings. Here is a good overview.

One caveat that we ran into is with the update site that is pushed out via policies must be a http server running on port 80.  Once we enabled tracing on the Sametime Connect clients we were able to get more infiormation on what was going on.

<globalInstanceId="ELc0a8c93700014fac6b9c030000000b" msg="CWPMS0202E: The Managed Settings File Provider was unable to open the URL http://sametime.domain.com:88/sametime/updates/managed-settings.xml due to the following error: Forbidden." severity="50" version="1.0.1">
 <extendedDataElements name="CommonBaseEventLogRecord:level" type="noValue">

We tried everything to make sure that the file was being served correctly. You could access the URL and the managed-settings file was loaded via a browser.

The Workaround

Relocating the managed-setting file on another HTTP server appeared to resolve this issue. We were then able to use the managed settings and push out our changes.

I’m currently installing Connections 5 for a customer. It’s a great place as the onsite guys really know their stuff. Anyway, their LDAP is in a bit of a state. Typical example of an organisation that has grown, gone through many Active Directory upgrades and no hard and fast rules for user management.

For Connections to be useful, you need relevant and current users in the Profiles database.

With populating the profiles DB, you’ve got 2 types of people. You’ve got the Wizards, and the Command lines. I’m a Wizard guy, just because it has come along way since I first used it (2.5) and hey, it automates half of my job. I still like to know and understand what the Wizards are doing, but if they automate it, awesome.

So I’m doing this install, and I run the Wizard with the default search scope.

The default search filter I used was below. I wanted to see how many records…

(&(sAMAccountName=*)(objectClass=user)

As you do, I iterate the log file..

LFRN0027I: After operation, success records is 634, duplicate records 0, failure records is 366.

That’s interesting…these guys only have 400 users?

Opened the PEOPLEDB, and there were heaps..I means heaps… of deactivated users. Doesn’t look like a user account had been deleted. Ever.

So, reset everything, dropped the DB and recreated it.

I had to work out how to populate without syncing accounts that were disabled. I also wanted mail to be populated.

Here is the search string that did it..

(&(sAMAccountName=*)(objectClass=user)(mail=*)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))

The parameter (!(userAccountControl:1.2.840.113556.1.4.803:=2) is a feature with MS AD, and is called a bitwise filter. Essentially, we’ve selected the users with the  useraccountcontrol flag enabled. This link explains it better than I ever could.

After operation, success records is 406, duplicate records 0, failure records is 24, and last successful entry is

This worked, users synced dropped to the correct numbers. Happy days.

CentOS is pretty awesome. I do most of my work these thankfully on a Linux distro. We usually just run command line, and use tools like XMing and Putty to do the GUI only bits of the install.

In this particular install, we were using the Servers GNOME desktop. When running installation manager, we were getting a JVM crash when hitting “Next” on the install for Installation manager 1.8.

After much searching, ensuring everything was up to date I stumbles across this technote.

Once this fix was in place, I was able to continue the install.