ldap_result: Can't contact LDAP server (-1)

Question

G'day, I configured openldap-server machine which is running on port 636. I can also telnet to this port from another openldap-client machine. To secure the connection, I created a self-signed certificate on the server using this link enter link description here and then copied the certificate file to the client.

I have made sure that SELinux is desabled on both machine and also the client /etc/openldap/ldap.conf file has the option TLS_REQCERT allow

The detailed configuration of client machine is:

# cat ldap.conf
URI ldap://ad.dfsi.dev:636
BASE dc=dfsi,dc=dev
TLS_CACERTDIR /etc/openldap/cacerts
TLS_REQCERT allow

and the nslcd file:

# cat /etc/nslcd.conf
tls_reqcert allow
ssl start_tls
tls_cacertdir /etc/openldap/cacerts
tls_reqcert allow

If I do not use SSL, then ldap client gets access to all ldap users. But, when I change the configuration to use TLS via authconfig-tui, ldaps://ad.xx.dev:636, then it fails.

The logs say that the client successfully connects to the server, but then then server drops the connection as shown here:

ldapsearch -x -d 1
ldap_create
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ad.dfsi.dev:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying xx.xx.xx.xx:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect: 
connect success
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush2: 14 bytes to sd 3
ldap_result ld 0x7f8f75e1d150 msgid 1
wait4msg ld 0x7f8f75e1d150 msgid 1 (infinite timeout)
wait4msg continue ld 0x7f8f75e1d150 msgid 1 all 1
** ld 0x7f8f75e1d150 Connections:
* host: ad.dfsi.dev  port: 636  (default)
  refcnt: 2  status: Connected
  last used: Tue Nov 29 15:01:28 2016


** ld 0x7f8f75e1d150 Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x7f8f75e1d150 request count 1 (abandoned 0)
** ld 0x7f8f75e1d150 Response Queue:
   Empty
  ld 0x7f8f75e1d150 response count 0
ldap_chkResponseList ld 0x7f8f75e1d150 msgid 1 all 1
ldap_chkResponseList returns ld 0x7f8f75e1d150 NULL
ldap_int_select
read1msg: ld 0x7f8f75e1d150 msgid 1 all 1
ber_get_next
ldap_err2string
ldap_result: Can't contact LDAP server (-1)
ldap_free_request (origid 1, msgid 1)
ldap_free_connection 1 1
ldap_free_connection: actually freed

Running openssl shows that the client cannot find any certificates on the server, which is not reasonable because I have everything fixed there:

# openssl s_client -showcerts -connect ad.dfsi.dev:636 
CONNECTED(00000003)
140330386184096:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:184:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 247 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

nss-pam authconfg-tui generates its new CACERTDIR every time which overrides the previous configuration. Therefore, I have also put the certificate file in the /etc/openldap/cacerts folder.

My client machine is CentOS7 and server is Redhat ec2 instance.

Can anyone give me some hints to troubleshoot this?

Solution 1

STARTTLS means "explicit TLS" where the connection is established on regular port and then STARTTLS command is sent to initiate SSL handshake and switch to protection mode.

To connect try add -Z or -ZZ switch to ldapsearch:

ldapsearch -x -d 1 -ZZ

is to get the client to use starttls

I am afraid OpenSSL does not support starttls for LDAP protocol now (see man page man s_client about -starttls parameter)

Solution 2

Just to be clear about it: Did you configure the TLS usage in the OpenLDAP server?

You still need to set a few parameters. For reference, please check http://www.openldap.org/doc/admin24/tls.html#Server%20Configuration

From my understanding your client connects to the LDAP machine, but the LDAP machine does not know which certificate to deliver to the client.

Could you please verify or falsify my guess?

Comments

[Cory Knutson]

Welcome to ServerFault, the OP stated that he tried that, and it failed.