Hi!
I need some assistance regarding TLS configuration. So, I'm using OpenLDAP 2.4.11 with debian/testing. This what my config looks like: slapd.conf: [...] TLSCACertificateFile /etc/ssl/certs/ecentrum_cacert.pem TLSCertificateFile /etc/ldap/tls/openldap_cert.pem TLSCertificateKeyFile /etc/ldap/tls/openldap_key.pem TLSVerifyClient try [...]
Slapd starts with these settings gladly, and with a client (eg. ldapsearch) without requesting TLS connection, I can get to the invalid credentials error (which is what I'm expecting now, this is just testing.). But with requesting TLS:
$ cat ~/.ldaprc TLS_CACERT /etc/ssl/certs/ecentrum_cacert.pem $ ls -l /etc/ssl/certs/ecentrum_cacert.pem -rw-r--r-- 1 root root [...] /etc/ssl/certs/ecentrum_cacert.pem
$ ldapsearch -d 1 -ZZWx '(objectclass=*)' \ -H ldap://fileserver.digiszfv:636 ldap_url_parse_ext(ldap://fileserver.digiszfv:636)
ldap_create
ldap_url_parse_ext(ldap://fileserver.digiszfv:636/??base)
ldap_extended_operation_s
ldap_extended_operation
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP fileserver.digiszfv:636
ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.1.3:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x67e0b0 msgid 1 wait4msg ld 0x67e0b0 msgid 1 (infinite timeout) wait4msg continue ld 0x67e0b0 msgid 1 all 1 ** ld 0x67e0b0 Connections: * host: fileserver.digiszfv port: 636 (default) refcnt: 2 status: Connected last used: Mon Oct 27 11:07:53 2008
** ld 0x67e0b0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x67e0b0 request count 1 (abandoned 0) ** ld 0x67e0b0 Response Queue: Empty ld 0x67e0b0 response count 0 ldap_chkResponseList ld 0x67e0b0 msgid 1 all 1 ldap_chkResponseList returns ld 0x67e0b0 NULL ldap_int_select read1msg: ld 0x67e0b0 msgid 1 all 1 ber_get_next ldap_free_connection 1 0 ldap_free_connection: actually freed ldap_err2string ldap_start_tls: Can't contact LDAP server (-1)
Meanwhile on the server side: # tail -f syslog slapd[3779]: slap_listener_activate(9): slapd[3779]: >>> slap_listener(ldaps://fileserver.digiszfv:636/) slapd[3779]: connection_get(15): got connid=21 slapd[3779]: connection_read(15): checking for input on id=21 slapd[3779]: connection_read(15): TLS accept failure error=-1 id=21, closing slapd[3779]: connection_closing: readying conn=21 sd=15 for close slapd[3779]: connection_close: conn=21 sd=15
The log messages are so terse and/or cryptic, I simply can not figure out what could be wrong. Any help would be appreciated!
Thanks!
Daniel
On Mon, 27 Oct 2008, LÉVAI Dániel wrote: ...
Slapd starts with these settings gladly, and with a client (eg. ldapsearch) without requesting TLS connection, I can get to the invalid credentials error (which is what I'm expecting now, this is just testing.). But with requesting TLS:
...
$ ldapsearch -d 1 -ZZWx '(objectclass=*)' \ -H ldap://fileserver.digiszfv:636
There are two ways to use LDAP with TLS/SSL: 1) start the connection in cleartext and then use the StartTLS extended-op to initiate a TLS layer, or 2) negotiate a TLS/SSL layer immediately after connecting.
The former is requested using the "ldap://" schema with the -Z option and is normally run on port 389. The latter is requested using the "ldaps://" schema and is normally run on port 636. These are distinct protocols: the client and server have to be talking the same one or it just won't work.
Your ldapsearch tried to do the former (LDAP w/StartTLS) on the port reserved for the latter (ldaps). The server was expecting to see a TLS client-handshake as the first data but instead got an LDAP extended-op and it all goes off the rails after that.
So, don't mix them. If you want to do the former, then drop the bogus ":636" from the URL: ldapsearch -d 1 -ZZWx '(objectclass=*)' \ -H ldap://fileserver.digiszfv
If you want to do the latter, then set the schema correctly, drop the -Z options, and drop the ":636" (because that's the default for ldaps): ldapsearch -d 1 -Wx '(objectclass=*)' \ -H ldaps://fileserver.digiszfv
(If you're using the default ports, then you don't need to specify them for the OpenLDAP clients, as they'll use the right default for the schema. I hear that was broken in the obsolete slurpd daemon for replication URLs, but you shouldn't be using that anyway.)
Philip Guenther
On Monday 27 October 2008 16.36.41 Philip Guenther wrote:
On Mon, 27 Oct 2008, LÉVAI Dániel wrote: ...
Slapd starts with these settings gladly, and with a client (eg. ldapsearch) without requesting TLS connection, I can get to the invalid credentials error (which is what I'm expecting now, this is just testing.). But with requesting TLS:
...
$ ldapsearch -d 1 -ZZWx '(objectclass=*)' \ -H ldap://fileserver.digiszfv:636
There are two ways to use LDAP with TLS/SSL:
- start the connection in cleartext and then use the StartTLS
extended-op to initiate a TLS layer, or 2) negotiate a TLS/SSL layer immediately after connecting.
Alright, understood! Thanks!
The former is requested using the "ldap://" schema with the -Z option and is normally run on port 389. The latter is requested using the "ldaps://" schema and is normally run on port 636. These are distinct protocols: the client and server have to be talking the same one or it just won't work.
[...]
So, don't mix them. If you want to do the former, then drop the bogus ":636" from the URL: ldapsearch -d 1 -ZZWx '(objectclass=*)' \ -H ldap://fileserver.digiszfv
So, now: $ ldapsearch -d 1 -ZZWx '(objectclass=*)' -H ldap://fileserver.digiszfv ldap_url_parse_ext(ldap://fileserver.digiszfv) ldap_create ldap_url_parse_ext(ldap://fileserver.digiszfv:389/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP fileserver.digiszfv:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.1.3:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x6120b0 msgid 1 wait4msg ld 0x6120b0 msgid 1 (infinite timeout) wait4msg continue ld 0x6120b0 msgid 1 all 1 ** ld 0x6120b0 Connections: * host: fileserver.digiszfv port: 389 (default) refcnt: 2 status: Connected last used: Mon Oct 27 17:02:27 2008
** ld 0x6120b0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x6120b0 request count 1 (abandoned 0) ** ld 0x6120b0 Response Queue: Empty ld 0x6120b0 response count 0 ldap_chkResponseList ld 0x6120b0 msgid 1 all 1 ldap_chkResponseList returns ld 0x6120b0 NULL ldap_int_select read1msg: ld 0x6120b0 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x6120b0 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x6120b0 0 new referrals read1msg: mark request completed, ld 0x6120b0 msgid 1 request done: ld 0x6120b0 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree Enter LDAP Password: ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 20 bytes to sd 3 ldap_result ld 0x6120b0 msgid 2 wait4msg ld 0x6120b0 msgid 2 (infinite timeout) wait4msg continue ld 0x6120b0 msgid 2 all 1 ** ld 0x6120b0 Connections: * host: fileserver.digiszfv port: 389 (default) refcnt: 2 status: Connected last used: Mon Oct 27 17:02:30 2008
** ld 0x6120b0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x6120b0 request count 1 (abandoned 0) ** ld 0x6120b0 Response Queue: Empty ld 0x6120b0 response count 0 ldap_chkResponseList ld 0x6120b0 msgid 2 all 1 ldap_chkResponseList returns ld 0x6120b0 NULL ldap_int_select read1msg: ld 0x6120b0 msgid 2 all 1 ber_get_next ldap_free_connection 1 0 ldap_free_connection: actually freed ldap_err2string ldap_result: Can't contact LDAP server (-1)
# tail syslog slapd[3779]: slap_listener_activate(8): slapd[3779]: >>> slap_listener(ldap://fileserver.digiszfv:389/) slapd[3779]: connection_get(15): got connid=35 slapd[3779]: connection_read(15): checking for input on id=35 slapd[3779]: conn=35 op=0 do_extended slapd[3779]: send_ldap_extended: err=0 oid= len=0 slapd[3779]: send_ldap_response: msgid=1 tag=120 err=0 slapd[3779]: connection_get(15): got connid=35 slapd[3779]: connection_read(15): checking for input on id=35 slapd[3779]: connection_get(15): got connid=35 slapd[3779]: connection_read(15): checking for input on id=35 slapd[3779]: connection_get(15): got connid=35 slapd[3779]: connection_read(15): checking for input on id=35 slapd[3779]: connection_read(15): TLS accept failure error=-1 id=35, closing slapd[3779]: connection_closing: readying conn=35 sd=15 for close slapd[3779]: connection_close: conn=35 sd=15
If you want to do the latter, then set the schema correctly, drop the -Z options, and drop the ":636" (because that's the default for ldaps): ldapsearch -d 1 -Wx '(objectclass=*)' \ -H ldaps://fileserver.digiszfv
$ ldapsearch -d 1 -Wx '(objectclass=*)' -H ldaps://fileserver.digiszfv ldap_url_parse_ext(ldaps://fileserver.digiszfv) ldap_create ldap_url_parse_ext(ldaps://fileserver.digiszfv:636/??base) Enter LDAP Password: ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP fileserver.digiszfv:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.1.3:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 20 bytes to sd 3 ldap_result ld 0x6120b0 msgid 1 wait4msg ld 0x6120b0 msgid 1 (infinite timeout) wait4msg continue ld 0x6120b0 msgid 1 all 1 ** ld 0x6120b0 Connections: * host: fileserver.digiszfv port: 636 (default) refcnt: 2 status: Connected last used: Mon Oct 27 17:05:59 2008
** ld 0x6120b0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x6120b0 request count 1 (abandoned 0) ** ld 0x6120b0 Response Queue: Empty ld 0x6120b0 response count 0 ldap_chkResponseList ld 0x6120b0 msgid 1 all 1 ldap_chkResponseList returns ld 0x6120b0 NULL ldap_int_select read1msg: ld 0x6120b0 msgid 1 all 1 ber_get_next ldap_free_connection 1 0 ldap_free_connection: actually freed ldap_err2string ldap_result: Can't contact LDAP server (-1)
# tail syslog slapd[3779]: slap_listener_activate(9): slapd[3779]: >>> slap_listener(ldaps://fileserver.digiszfv:636/) slapd[3779]: connection_get(15): got connid=36 slapd[3779]: connection_read(15): checking for input on id=36 slapd[3779]: connection_get(15): got connid=36 slapd[3779]: connection_read(15): checking for input on id=36 slapd[3779]: connection_get(15): got connid=36 slapd[3779]: connection_read(15): checking for input on id=36 slapd[3779]: connection_read(15): TLS accept failure error=-1 id=36, closing slapd[3779]: connection_closing: readying conn=36 sd=15 for close slapd[3779]: connection_close: conn=36 sd=15
Philip Guenther
With both ldapsearch(1) commands, I've been asked for my password, and I typed something bogus intentionally, in the hope of getting the invalid credentials message, but unfortunatelly, I didn't get it. The only time ldapsearch(1) is working as "expected", is when I'm running it without the -ZZ option and with ldap:// (not ldaps://):
$ ldapsearch -d 1 -Wx '(objectclass=*)' -H ldap://fileserver.digiszfv [...] Enter LDAP Password: [...] ldap_bind: Invalid credentials (49)
Any other ideas? Thanks!
Daniel
On Mon, 27 Oct 2008, LÉVAI Dániel wrote: ...
slapd[3779]: connection_read(15): TLS accept failure error=-1 id=35, closing
...
slapd[3779]: connection_read(15): TLS accept failure error=-1 id=36, closing
So it's the TLS negotiation that's failing. What's the output if you connect directly to the ldaps port with openssl's s_client option?
openssl s_client -connect fileserver.digiszfv:636 </dev/null
Philip
LÉVAI Dániel leva@ecentrum.hu writes:
On Monday 27 October 2008 16.36.41 Philip Guenther wrote:
On Mon, 27 Oct 2008, LÉVAI Dániel wrote: ...
[...]
There are two ways to use LDAP with TLS/SSL:
- start the connection in cleartext and then use the StartTLS
extended-op to initiate a TLS layer, or 2) negotiate a TLS/SSL layer immediately after connecting.
Alright, understood! Thanks!
The former is requested using the "ldap://" schema with the -Z option and is normally run on port 389. The latter is requested using the "ldaps://" schema and is normally run on port 636. These are distinct protocols: the client and server have to be talking the same one or it just won't work.
[...]
With both ldapsearch(1) commands, I've been asked for my password, and I typed something bogus intentionally, in the hope of getting the invalid credentials message, but unfortunatelly, I didn't get it.
This sounds as if you have not removed the private part from the key, see man rsa(1), pkcs8(1). How did you create the certificates?
-Dieter
Dieter Kluenter wrote:
LÉVAI Dániel leva@ecentrum.hu writes:
On Monday 27 October 2008 16.36.41 Philip Guenther wrote:
On Mon, 27 Oct 2008, LÉVAI Dániel wrote: ...
[...]
There are two ways to use LDAP with TLS/SSL:
- start the connection in cleartext and then use the StartTLS
extended-op to initiate a TLS layer, or 2) negotiate a TLS/SSL layer immediately after connecting.
Alright, understood! Thanks!
The former is requested using the "ldap://" schema with the -Z option and is normally run on port 389. The latter is requested using the "ldaps://" schema and is normally run on port 636. These are distinct protocols: the client and server have to be talking the same one or it just won't work.
[...]
With both ldapsearch(1) commands, I've been asked for my password, and I typed something bogus intentionally, in the hope of getting the invalid credentials message, but unfortunatelly, I didn't get it.
This sounds as if you have not removed the private part from the key, see man rsa(1), pkcs8(1). How did you create the certificates?
I have the key and cert in two distinct files. I've created a certificate signing request, sent it to the CA, it signed it, and then sent it back. Now I have the signed certificate, and CA's certificate.
Daniel
openldap-software@openldap.org
-
Dieter Kluenter -
LÉVAI Dániel -
Philip Guenther