How to connect to LDAP over SSL from within websphere application server using JNDI

Hi Experts,

I am trying to connect to LDAPS using JNDI. I am getting the following exception.

javax.naming.CommunicationException: 192.168.*.***:636 [Root exception is]

Pl. see the code snippet to see if i am doing anything wrong. Code is run within websphere app server 6.1

private DirContext getInitialContext(
      String protocol, 
      String hostname, 
      int port,
      String username, 
      String password, 
      String keystore)
	        throws NamingException {

	        String providerURL =
	            new StringBuffer("")
	        System.setProperty("", keystore); 

	        Properties props = new Properties();
	        props.put(Context.PROVIDER_URL, providerURL);

	        if ((username != null) && (!username.equals(""))) {
	            props.put(Context.SECURITY_AUTHENTICATION, "simple");
	            props.put(Context.SECURITY_PRINCIPAL, username);
	            props.put(Context.REFERRAL, "ignore");
	            	props.put(Context.SECURITY_PROTOCOL, "SSL");
	                ((password == null) ? "" : password));

	        return new InitialDirContext(props);

Open in new window

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Can you post the full stacktrace of the exception? I suspect that there is an SSL Handshake failing down the chain somewhere - in which case you haven't imported someone's certificate somewhere (the web server's in the ldap or the ldap's in the web server)

And make sure the Web server can see the ldap server...
Also make sure your protocol is ldap and not ldaps (although I would expect another exception if that was the problem)
We have a working sample for JNDI and LDAPS:
jwillekeCommented: is only thrown to indicate that there is an error in the underlying protocol, such as a TCP error.

Either the IP address for the LDAP server is NOT open on port 636 or perhaps you could have a firewall issue on your box or somewhere in between.

We have seen this error when the client running the code can not OPEN to 636 because some software has declared the port as an "UN-SAFE PORT".


Powerful Yet Easy-to-Use Network Monitoring

Identify excessive bandwidth utilization or unexpected application traffic with SolarWinds Bandwidth Analyzer Pack.

bcisystemsAuthor Commented:
Got it working. I had an issue with importing the certificate into WAS. Here are the steps i followed to get the certificate in. Once that was done and the right trust store location was given, it was all gold. Thanks for the replies though.

1.      Log in to the WebSphere Application Server Administrative Console.
2.      Navigate to Security > SSL certificate and key management > SSL configurations.
3.      Click the appropriate SSL configuration from the list; for example, NodeDefaultSSLSettings.
4.      Click Key stores and certificates.
5.      Click the appropriate trust store from the list; for example, NodeDefaultTrustStore.
6.      Click Signer certificates, click Retrieve from port, and then enter the following information:
7.      Type the Host name used when attempting to retrieve the signer certificate from the SSL port.
8.      Type the SSL Port used when attempting to retrieve the signer certificate.
9.      Type the Alias the key store uses for the signer certificate.
10.      Click Retrieve signer information to retrieve the certificate from the port.
11.      Click OK and then click Save to save the changes to the master configuration.

In this regard, that I found the solution myself. I would like to request my points back from the admin.
bcisystemsAuthor Commented:
I forgot to mention the keystore. It would look something like this on a windows machine:

KEYSTORE= C:/Program Files (x86)/IBM/SDP/runtimes/base_v61/profiles/AppSrv01/config/cells/Node01Cell/nodes/Node01/trust.p12
Without the full stacktrace, there would have been no way to give you any steps -- you could have been missing a certificate on either side. And had you have confirmed that you really see handshake issues, I would have worked with you

I would have expected partial points - it did point you to the solution and honestly it is trivial to find out how to fix it once you know what's wrong. But if you do not think so, have a nice day - life is too short to deal with people that consider someone helping them only if all the work had been done for them
:) which does not mean that I will object - I won't. If this is how you feel - I am fine with it.

Good thing that the connection works and good luck with your future development.
bcisystemsAuthor Commented:

I would like to share partial points with you, since you pointed me in the right direction, your answer did help. But would you agree that it would be fair to share points between us?
bcisystemsAuthor Commented:

One other question, you said protocol should be ldap instead of ldaps. Can you explain why?
And yes thanks for your help.

Did I say full points anywhere? :)

It is not about points - it is about help really - that's why I posted at all. Had been dealing with LDAPS way too often and 9 times out of 10 it will be one of the certificates. The problem with providing full solution in such cases is that it is not clear what the version of WAS is or what kind of LDAP you are using. And the certificate can be missing in eitehr keystore. You are kinda luckier when it is in the server and not in LDAP - had been dealing with a stubborn AD the other day :)

 And if you really belive that you should get all of your points back - as I said, I won't object.

PS: For the protocol: the RFC-compliant and standard way to do it is to use the ldap URL and to specify the Context.SECURITY_PROTOCOL to make it SSL. Technically an LDAPS URL is acceptable (and in this case you do not really use the SECURITY_PROTOCOL - in theory)... I just prefer following the RFCs... and it makes the code easier to work on eithe ldap or ldaps just based on the ssl setting. has some more details.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
bcisystemsAuthor Commented:
:) thanks, and yes its not abt points.
I thought that you wanted to give just partial points? :)
bcisystemsAuthor Commented:

Like you said, its not about points and its about rewarding the true experts that help :)

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.