TrustStore for LDAPS and AD


For Directory Integrator to securely connect to Active Directory or LDAP you need to establish a trust. You do this by adding a Certificate Signers to your truststore. There are two scenarios;
  • You already have know the details of your target system's certificate signer and have that signer's cert
  • You don't have any information and must determine who signed what.

Scenario 1: (You already have the signer's cert)

Add it to your keystores

There are 2-4 keystores you have to handle:
  • The Config Editor's keystore
  • The Server's keystore
The Config Editor

The config editor's keystores are in the solution directory that you chose when you installed TDI. This is usually a folder named TDI in your home directory or the server's installation directory. Start your config editor and select 'switch workspace' if you're not sure. Below are the commands with the default passwords

$ /opt/IBM/TDI/V7.2/jvm/jre/bin/keytool -import -trustcacerts -alias AddTrust-Global-CA -file AddTrust-Global-CA.pem -keystore /home/gattis/TDI/testserver.jks -storepass server

$ /opt/IBM/TDI/V7.2/jvm/jre/bin/keytool -import -trustcacerts -alias AddTrust-Global-CA -file AddTrust-Global-CA.pem -keystore /home/gattis/TDI/serverapi/testadmin.jks -storepass administrator

(You may need to add an intermediary signer next)

The Server

If you only installed the server, the location is still your workspace - though that's usually the install location.

sudo /opt/IBM/TDI/V7.2/jvm/jre/bin/keytool -import -trustcacerts -alias GATTIS-CA -file gattis-AD1-CA.cer -keystore /opt/IBM/TDI/V7.2/testserver.jks -storepass server

sudo /opt/IBM/TDI/V7.2/jvm/jre/bin/keytool -import -trustcacerts -alias GATTIS-CA -file gattis-AD1-CA.cer -keystore /opt/IBM/TDI/V7.2/serverapi/testadmin.jks -storepass administrator

Scenario 2: (Determine who signed the other certificate)

1. Inspect the other system's certificate

Take a look at who signed the other server's certificate

# Hit enter twice after this command
openssl s_client -connect some.ldap.server:636 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -noout -issuer

The output will be the name of the Certificate Signer and will be something like:

issuer= /C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA

2. Figure out who signed the certificate

When  you looked at who signed that certificate, you'll notice the issuer line is is either:
  • The same server (a self-signed certificate)
  • Another signer in your own organization (a privately signed certificate)
  • A  signer outside your organization (a public certificate service)

Self Signed Certificates
If you see that the issuer is the same as the server, such as:

openssl s_client -connect ......
issuer= /DC=org/DC=your/DC=server/CN=some

Then you have a Self-Signed certificate that you can just import as detailed in step 3.

Privately Issued Certs
If you see that the certificate is signed by someone in your organization (an it may be hard to tell) 

openssl s_client -connect ......
issuer= /DC=org/DC=your/CN=server/CN=other

You'll need to ask the administrator of that other system for their 'Certificate Authority Signer' certificate.  In some cases, that issuer will not look like a server hostname. If that's the case, the person running the server you're connecting to should know who signed their certificate.

If this is an Active Directory service, the default is to be signed automatically by the AD Domain Cert Authority. If that's the case, you can go to any domain server, start the MMC console and add the cert snap-in, and export the cert as base64.

Publicly Issued Certs 
Since the issuer ID doesn't explicitly tell you where to go to get it's Cert, you have to do a little sleuthing. If it's like the above example, you have to Google it and find that company's "Certificate Authority" Cert such as in the example at the top:  "CN=GeoTrust SSL CA". 

Once you get that cert, check with these commands to make the subject and the issuer are the same:

$ cat AddTrust-External-CA-Root.pem | openssl x509 -noout -subject
Subject: C=US, O=GeoTrust, Inc., CN=GeoTrust SSL CA

$ cat AddTrust-External-CA-Root.pem | openssl x509 -noout -issuer
Issuer: C=US, O=GeoTrust Inc., CN=GeoTrust Global CA

If they are not the same, as in this example then you are dealing with an 'Intermediary Signer' and must hunt down the signer of this intermediary, that in this case would be "CN=GeoTrust Global CA" . When you get that cert, you must check it and ensure that it is the 'root' of the trust chain.


Take a look at who issued the other server's certificate.

$ openssl s_client -connect some.ldap.server:636 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/some.ldap.server.cer


Trust Exceptions

You will see the following error if your TDI server does not trust the LDAP or AD server you are attempting to connect to. (By default, you trust no servers!)

ERROR - [Enrollment Goups Iterator] CTGDIS810E handleException - cannot handle exception , initialize 
javax.naming.CommunicationException: simple bind failed: [Root exception is PKIX path building failed: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is: The certificate issued by CN=ohio-AD1-CA, DC=ohio, DC=edu is not trusted; internal cause is: Certificate chaining error]

Chaining Errors Certificate chaining error

It's possible there is an 'Intermediary Signer' .  If you notice that when you got the Issuer's certificate, the Owner and the Issuer are the same:

Owner: CN=some, DC=ldap, DC=server
Issuer: CN=some, DC=ldap, DC=server

If they are not  the same, you will have to track down the Issuer, of the server that Issued you your certificate.

Can't find the keystore

The TDI's Server
The default Directory Integrator Server truststore is TDI_HOME/serverapi/testadmin.jks  and is configured in the file.  Just check your to make sure you're not overriding it (i.e. this is the file TDI uses)
$ grep /opt/IBM/TDI/V7.1/etc/
$ grep /opt/IBM/TDI/V7.1/


You can use TLS, if you want to set up the connector yourself