Please note, this is about communication between Liferay and the LDAP server, not communication between the user's browser and Liferay

I'm asking this here since I got zero views (other than my own) in 30 minutes at the liferay forums, and I'd like to solve this today if possible...

I've looked at:



I've also read this:


And I've done a bunch of searching and found lots of folks setting up CAS and mentioning LDAP in their posts.

Problem is I'm not (Yet?) interested in implementing CAS. I want to set up a demo server for folks and allow them to log in with their LDAP/AD credentials. I've opted for binding since I don't have access to a login that allows me (and therefore liferay) to see said passwords.

I know this is crazy, but I also don't want their passwords to be sent in the clear. :)

None of the liferay docs discuss how to ensure that liferay starts TLS. I'm not an LDAP expert, so perhaps this is normally enforced by the LDAP or AD server, but even in that case it would have been nice if the docs said something about how to ensure that an evil employee, or evil network intruder can't simply listen to life-ray log-in requests to gain access to everyone's stuff.

From what I've read, the right thing for current LDAP implementations is for the client to initiate TLS communication for sensitive queries


So does Liferay do this? Do I need to configure anything extra to enable it?

The fact that http://issues.liferay.com/browse/LEP-4225 comes up when I google, throws signifcant doubt on wether or not this is even implemented in Liferay (I notice however that this is against "old liferay"...)

Basically I'm asking for someone who actually knows, to clear up what is/isn't available and whether or not I need to do anything to enable secure communications with LDAP/AD.

Note that I'm not interested in client certificates or otherwise authenticating the client (liferay) to the LDAP server at this time. Just securely delegating authentication to LDAP/AD.

EDIT: I just confirmed (with wireshark) that in the default configuration "test connection" sends my password in cleartext, so this seems to be a real problem

EDIT 2: Also confirmed that login attempts send the password in clear text. An encrypted solution is clearly necessary.

  • Could the folks who are voting to close as off topic please clarify where they think I should ask this question. If this should be moved to some other stack exchange then please do move it... I'm not getting much response here anyway.
    – Gus
    Feb 16, 2012 at 14:56
  • Oh lovely, no liferay tag here. This really is liferay specific... Someone care to make one?
    – Gus
    Feb 16, 2012 at 23:11
  • thx for creating the tag, to whoever did it :)
    – Gus
    Feb 22, 2012 at 19:10
  • see if my edited answer helps or gives more information. Re the tag: You're welcome ;)
    – Olaf
    Feb 24, 2012 at 11:32

2 Answers 2


Correcting my original answer after I seem to have misread the question - it's clearer after the edit that the LDAP connection is meant.

Unfortunately I can't give a good answer out of the box right now, but hopefully some helpful pointers:

When you use an LDAP connection through SSL, you need to make sure that tomcat (the initiator of the connection) trusts the certificate that the LDAP server presents. Most likely this certificate is not issued by a known and trusted authority (e.g. it's probably self-signed).

Remember that SSL not only means encryption but also trusting the other end that it's the one that it states to be: It would be stupid to rely on encryption if any man-in-the-middle can cause you to connect to itself, encrypted. So you want some proof of identity of the one that you connect to.

When you google "LDAP SSL Java" you get a lot of hits giving good examples and explanations how to configure tomcat's virtual machine (and its keystore). Yes, it's the VM that you need to configure the trust to. http://docs.oracle.com/javase/jndi/tutorial/ldap/security/ssl.html contains basic pointers (in the introductory paragraph), stating

Once the JSSE has been installed and configured, you need to ensure that the client trusts the LDAP server that you'll be using. You must install the server's certificate (or its CA's certificate) in your JRE's database of trusted certificates. Here is an example.

# cd JAVA_HOME/lib/security
# keytool -import -file server_cert.cer -keystore jssecacerts

For information on how to use the security tools, see the Java 2 Platform Security trail of the Java Tutorial. For information on the JSSE, read the JSSE Reference Guide

Basically: If you didn't use keytool, you probably haven't set up trust to your LDAP server's certificate in your Liferay VM. Remember that you're not done then, you still need to include the keystore manipulated with keytool into your VM. I would expect trust-related error messages in the logfiles. As you neither give logfiles nor information on what kind of trust you established, please do so or let me know if you need further information

Original answer (before clarification that LDAP connection is meant):

Check Liferay's portal.properties default configuration and override it in $LIFERAY_HOME/portal-ext.properties. There you'll find the default value

# Set this to true to ensure users login with https. If this is set to true
# and you want your HTTP session to contain your credentials after logging
# in, then the property "session.enable.phishing.protection" must be set to
# false or your credentials will only be available in the HTTPS session.

If you set this to true, you might have everything you want.

This of course assumes, that you have https already set up and running correctly (e.g. if you go to https://localhost/ or whereever your server lives (or https://localhost:8443 if you use a custom port 8443). How you do this is a matter of configuring your application server. Once Liferay answers correctly when you access it through https you can enforce the rest.

  • This causes firefox to complain about: An error occurred during a connection to localhost:8080. SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long) --- And no request is sent to ldap at all.
    – Gus
    Feb 21, 2012 at 16:32
  • Are you sure you didn't set your https port to 8080? This looks like firefox tries to do https through the port that has only http - obviously this will fail and not do anything. Will add a precondition to my answer right now.
    – Olaf
    Feb 21, 2012 at 20:30
  • I was rather hoping not to have to set up https for my local box for this. Certainly the mode of communication between liferay (in tomcat) shouldnt be tied to the mode of communication between the browser and the tomcat server. Before I go spend a couple hours creating keys and setting up tomcat (and liferay) for https, can you explain to me why you think this relates to the ldap-tomcat communications? Certainly https will be in use in the final install, but I'd like not to mix https setup with ldap setup if at all possible. Change one thing at a time... etc
    – Gus
    Feb 22, 2012 at 18:57
  • sorry, misread the question - it's clearer now after the edit.
    – Olaf
    Feb 23, 2012 at 22:15
  • Yeah, your edit was what I had accomplished yesterday... The setup is categorized as "unstandardized" and deprecated by LDAP v3 (see RFC4513). The method in 4513 allows secure communication over port 389, and would probably also require the keytool/trust setup. I have to admit disappointment at JSSE requiring VM level configuration, and disappointment that Liferay doesn't use Ldap v3 communications given that that RFC was published in 2006. Given that you've arrived at the same workaround as me, and put in the effort I think I will give you credit :)
    – Gus
    Feb 24, 2012 at 15:10

Applications must transmit passwords in the clear over a secure connection for password changes and for authentication because modern, professional quality directory server have the capability of checking password quality and password history. Pre-encoded passwords cannot be checked for quality or history. A correctly configured directory server will not accept pre-encoded passwords for this reason.

  • From what I've read, that would be true of the initial connection, but not subsequent communications. So Anonymous (or other untrusted user) would be used to login initially, and then upgrade to TLS to send the user's credentials over an encrypted connection. The password would be clear within the encryption, but not visible to the likes of wireshark. Unfortunately, I was able to see the user's credentials in addition to the initial login when I snooped the connection. See my link to the java (oracle) tutorial on how to use LDAP/TLS (in java).
    – Gus
    Feb 16, 2012 at 14:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .