IBM Tivoli Directory Integrator and SSL

We saw this error today: -

2012-06-14 16:09:04,360 INFO  [AssemblyLine.AssemblyLines/populate_from_dns_file.1] - [PopFromDns_lookup_dn] [lookup_user] CTGDIS495I handleException , initialize, javax.naming.CommunicationException: simple bind failed: ldap.uk.ibm.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:

        java.security.cert.CertPathValidatorException: The certificate issued by O=UK,O=IBM,O=COM is not trusted; internal cause is:

        java.security.cert.CertPathValidatorException: Certificate chaining error]
2012-06-14 16:09:04,362 ERROR [AssemblyLine.AssemblyLines/populate_from_dns_file.1] - [PopFromDns_lookup_dn] [lookup_user] CTGDIS810E handleException - cannot handle exception , initialize

javax.naming.CommunicationException: simple bind failed: ldap.uk.ibm.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:

        java.security.cert.CertPathValidatorException: The certificate issued by O=UK,O=IBM,O=COM is not trusted; internal cause is:

        java.security.cert.CertPathValidatorException: Certificate chaining error]
in a new IBM Connections 3.0.1 environment, when running: -

$ ./populate_from_dn_file.sh

Having followed my own advice to check / update the SSL certificates: -

$ /opt/IBM/TDI/V7.0/jvm/jre/bin/keytool -list -keystore /opt/IBM/TDI/V7.0/jvm/jre/bin/keystore.jks -storepass passw0rd

but I was still getting the same exception, and was starting to question my sanity.

Then I Google'd the error and found this thread: -

SSL to Active directory

<snip>
* The error of "The certificate issued by CN=minca, DC=ad, DC=huseby,
DC=com is not trusted" is probably an issue of the TDI Server pointing
to the wrong JKS file, or you do not have all the required public
certificates in the trustStore to validate the certificate presented
by the AD Server.

* Enable the "javax.net.debug=true" in the solution.properties.  By
doing this, more information about the SSL handshake between the TDI
server and AD machine will be dumped to the TDI Config Editor console
log.  Have a review the output..towards the top of the log you will be
able to validate which JKS files the server is using.  You should also
be able to read through the logs..and see which certificate is causing
the problem. </snip>

I checked further, and found that we were missing BOTH of the following files: -

/opt/IBM/TDI/V7.0/tdisol_AD/TDI/solution.properties
/opt/IBM/TDI/V7.0/tdisol_AD/TDI/etc/global.properties
The key lines are: -

javax.net.ssl.trustStore=/opt/IBM/TDI/V7.0/jvm/jre/bin/keystore.jks
javax.net.ssl.trustStorePassword=passw0rd
javax.net.ssl.trustStoreType=jks
It seems that solution.properties is the more critical of the two files: the problem didn't go away until I updated solution.properties, so I'm guessing that global.properties is ignored, perhaps because we are using a solution directory: -

/opt/IBM/TDI/V7.0/tdisol_AD/TDI

especially as the forum thread also said: -

<snip>

* Are you using a Solution Directory, or the Install Directory as the
base for your TDI solutions?
Depending on the answer, you will either be using the
global.properties or solution.properties file.
* I will assume you are using the solution.properties file in your
Solution Directory.

</snip>

*UPDATE*

A friend asked whether I'd seen similar problems when running collect_dns.sh. This is my response: -


Thanks for the email - I didn't explicitly run collect_dns.sh but instead using populate_from_dn_file.sh, reading from a hand-edited collect.dns file.

The failure was, I think, on our part - the solution.properties file hadn't been defined, so ITDI didn't know where to go to get at the keystore.jks file.

I'm guessing that, because we chose to use a solution directory, created AFTER the ITDI installation and because the etc/global.properties doesn't reference the specific keystore, this wasn't ever going to work.