Error code 116 when validating LDAP with SSL authentication or logging into ClearQuest

Resolving The Problem

Note: For more information on the configuration of LDAP authentication for ClearQuest, see the ClearQuest and LDAP integration presentation on the IBM Education Assistant site.

1. Verify that the certificate is already valid, still valid, and has not been revoked. Ask your LDAP and SSL administrator for assistance.
   
   
2. When running the installutil setldapinit command with SSL parameters, the location of the key database file can be specified with the -K switch. It can be either in UNC form if the .kdb file is located on a central network storage. It can also be a full path to the .kdb file, if the key database file is distributed to all clients separately. Make sure that the .kdb file is actually stored in the location that was specified and that all users have read access to it.
   
   
3. The password you have specified when creating the key database is stashed to a file. By default, that file has the same base name as the key database file and the extension .sth. For instance, if your key database file is named ldapkey.kdb, the password is stashed to a file called ldapkey.sth. Make sure that the password stash file exists in the same location as the key database file (see Resolution 2), that it is accessible, and that it follows the naming convention.
   
   
4. If the Common Name (CN) of the certificate does not match the host name of the LDAP server, the certificate's validity cannot be verified and therefore an error will be returned. To verify the CN of the certificate:
1. Open the iKeyMan utility that comes with ClearQuest from C:\Program Files\IBM\GSK7\bin\gsk7ikm.exe.
2. Open the key database file and enter the password when prompted.
3. In the list of signer certificates, double-click on the certificate of your LDAP server to show its properties.
4. Check the value of the field labeled "Issued To", it will read something like "cn=ldapserver".
5. If the hostname you specify in the installutil setldapinit command (with the -h switch) is not "ldapserver", the certificate verification will fail and the error will be returned. Both must be absolutely identical.
   
   
5. If you change the password for the key database file, you must stash it to a file and update both the key database file and the stash file. This must be done in the location where you provide it for your clients, either on a central network share or on each client computer (see Resolution 2).
   
   
6. When creating a new key database, you can set an expiry time (in days) after which the key database becomes invalid. The key database file may have also become corrupted on the way to the location where you provide it for the individual clients. Open the key database file to verify it is both readable and has not expired. If it has expired or it is corrupted, create a new key database, stash the password to a file, and distribute both files to your client computers.
   
   
7. To verify whether the LDAP server is listening on TCP port 636 (the standard port for secure LDAP or LDAPS), run the following command from a Windows command prompt or a terminal in UNIX/Linux:
   
telnet ldapserver 636 

   ... where ldapserver is the host name or the IP address of the LDAP server as you have specified it in the installutil setldapinit command with the -h switch. If you get a message saying the connection was refused or similar, contact your LDAP administrator to enquire if your LDAP server supports SSL and if it is listening on port 636. Your LDAP administrator may have changed the port for any reason. You can specifiy a different port than 636 using the -p switch in the installutil setldapinit command.
   
   To verify if the LDAP server is reachable at all, try to run the installutil setldapinit and validateldap commands without the SSL parameters (omit the -Z and -K switches in setldapinit) to see if the validation works or not. If it does not work, contact your LDAP administrator for assistance.

If none of these recommended solutions have helped resolve your problem, contact IBM Rational Client Support for assistance.