SSL to Active directory

[Petter huseby]

Hi

I'm trying to establish a secure connection between my workstation and
my AD domain running on VmWare, using the LDAP connector.

I have now struggled with this some days without lock, so I need to
share my problem here, and hope for an solution :-)

Here is what I have done:

Installed a windows 2003 server in vmware and promoted it to a domain
controller
Installed the Sertification service, so I'm able to generate
certificate using the certification authority tool.
updated my host file so I can reach the vmware server by name.
Installed Microsoft support tool on my workstation and verified the
the LDP.exe are able to connect to my Ad.

Here is some question I like to ask the TDI group:

1) It seems that I need to update my trust store in TDI to be able to
use SSL. Witch jks file shal I use. Is it testserver.jks ,
key.jks , /serverapi/testadmin, installdir/testserver.jkt or
installdir/serverapi/testadmin. It's to many JKT files...

2) When I know with file to use, with certificate do I need to get
from the Certification authority in ad, it the Root certificate, or
do I need to create a certificate request in keymanager and import
that to ad , and import the new certificate in Key manger?

I will post a complete solution here when I get it to work .....

Regard
Petter Huseby
IBM Norway

[Petter huseby]

Forgot to mention that I'm running TDI 7

[Petter huseby]

On Nov 26, 9:51 am, Petter huseby <petter.hus...@gmail.com> wrote:

Hi

Here is the error log from the LDAP connector, after I importer the
root certificate to testadmin.jks file:

13:10:57,656 INFO - [LDAPConnector] CTGDJQ001I Using LDAP SSL
connection. Ensure TCP port number is changed accordingly.
13:11:05,281 ERROR - CTGDIS266E Error in InitConnectors. Exception
occurred: javax.naming.CommunicationException: simple bind failed:
MIN-5C0CEC76969.ad.huseby.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 CN=minca, DC=ad, DC=huseby, DC=com is not trusted; internal cause
is:
java.security.cert.CertPathValidatorException: Certificate chaining
error] javax.naming.CommunicationException: simple bind failed:
MIN-5C0CEC76969.ad.huseby.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 CN=minca, DC=ad, DC=huseby, DC=com is not trusted; internal cause
is:
java.security.cert.CertPathValidatorException: Certificate chaining
error]
13:11:05,281 INFO - CTGDIS100I Printing the Connector statistics.
13:11:05,296 INFO - [LDAPConnector] Errors:1
13:11:05,312 INFO - CTGDIS104I Total: Errors:2.
13:11:05,312 INFO - CTGDIS101I Finished printing the Connector
statistics.
13:11:05,312 ERROR - CTGDIS077I Failed with error: simple bind failed:
MIN-5C0CEC76969.ad.huseby.com:636.

[JasonW]

Petter,

* 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.
In the solution.properites, as you probably already know is the
following parameters which point to the Server and Client jks files.

## server authentication
javax.net.ssl.trustStore=serverapi\testadmin.jks
{protect}-javax.net.ssl.trustStorePassword=administrator
javax.net.ssl.trustStoreType=jks

## client authentication
javax.net.ssl.keyStore=serverapi\testadmin.jks
{protect}-javax.net.ssl.keyStorePassword=administrator
javax.net.ssl.keyStoreType=jks

* 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.

Good luck.