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

especially as the forum thread also said: -

<snip>

</snip>