I have gotten OpenLDAP with SSL working on a test box with a signed certificate. I can use an LDAP tool on a Windows box to view the LDAP over SSL (port 636). But when I run dpkg-reconfigure ldap-auth-config to setup my local login to use ldaps, my login under a username in the directory doesn't work. If I change the config to use just plain ldap (port 389) it works just fine (I can login under a username in the directory). When its setup for ldaps I get Auth.log shows:

Sep  5 13:48:27 boromir sshd[13453]: pam_ldap: ldap_simple_bind Can't contact LDAP server
Sep  5 13:48:27 boromir sshd[13453]: pam_ldap: reconnecting to LDAP server...
Sep  5 13:48:27 boromir sshd[13453]: pam_ldap: ldap_simple_bind Can't contact LDAP server

I will provide whatever are needed. I'm not sure what else to include.


I suspect you're using "ldaps://server/" for your URI when you need something like "ldaps://server:636/".

Without specifying the port, its going to try TLS over port 389.

  • I had tried that. It didn't help. I used dpkg-reconfigure ldap-auth-config to set it. When it's set to ldap://myserver it works. When its set to ldaps://myserver:636, it doesn't work. But as I stated before, I can open an SSL connection to the server using an LDAP browser without problem. Thanx for the suggestion. Any other ideas what it could be? I'm kinda thinking that it is related to the certificate not being accepted by the ldap client components. – Oliver Nelson Sep 17 '09 at 4:34
  • You still need to specify the port, but yes, the cert could be causing the problem. If that is the case, in /etc/libnss-ldap.conf and /etc/pam_ldap.conf, try adding "tls_checkpeer no". – hexmode Sep 20 '09 at 19:16
  • tls_checkpeer didn't help either. This shouldn't be this hard. I wonder why OpenLDAP docs don't have better info on setting up various common setups. – Oliver Nelson Sep 23 '09 at 15:08
  • When all else fails, I try strace. You say you've tried an LDAP browser, but have you tried the CLI tool "ldapsearch"? If you can get that to work (read the man page for options), then you should be able to get the pam/libnss stuff working. Also, check the manpage for pam_ldap.conf -- there is a debug param that should spew out a lot of debugging information. If you need more help, you can email me or leave an anonymous comment on my weblog w/ your email (I'll delete the comment & it will never be shown) – hexmode Sep 24 '09 at 19:43
  • ldaps:// automatically sets the correct port in the client libraries. You can confirm this with ldapsearch -ZZ -H ldaps://... when you see that TLS can't be set up because it's already in place. -Z with ldap:// to get TLS over the normal port, or ldaps:// to use the ldaps port and SSL-on-connect. – Phil P Dec 15 '09 at 23:31

sshd uses privilege separation and chroots. This may be interacting badly with something in the stack required to turn on SSL and check certificates.

Try disabling PrivilegeSeparation temporarily; it's a bad idea to run like that, but if it fixes the problem then you know what area to investigate.


Well, it is a TLS issue. Just disable checking slapd's cert on the client side. TLS_ReqCert is by default set to "demand" on the client; change it to "never". This makes your client trust the slapd, and in turn, make a connection after the tsl handshake.

  • 1
    This will also make you subject to possible man-in-the-middle attacks by not asking and trying to validate the certificate. – John Mar 18 '11 at 16:37

Hi Although your system works with port 389 TLS might still be up, because openLDAP might be encrypting data and sending it over 389. You could check this out.

  • 2
    This is pretty much exactly the same hexmode's answer posted 4 years ago... – Falcon Momot Jul 1 '13 at 9:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.