ok, more testing, more results ;) why i wasn't able to get any working setup in my test-setup turned out to be a very stupid (brown-paperbag-level) user-error - i just missed that there was an old .ldaprc hanging around... :)
but the initial problem i had in a production setup is still there: i've been using the slapd 2.3.30 package (with openssl) with 'security tls=128' to force TLS server-side (with server-cert, with no client-certs). now with the slapd 2.4.7 package (with gnutls) this seems to force client-certs, too. a TLS query without client-cert won't work - but commenting the 'security' line out results in working TLS and working non-TLS queries. it seems like openssl and gnutls or slapd 2.3 and slapd 2.4 simply behave differently for 'security tls=128'. this is a failing query with 'security tls=128' on the slapd 2.4.7 with gnutls: [EMAIL PROTECTED]:~$ ldapsearch -ZZ -x -h localhost -b dc=foo-bar,dc=baz "(objectClass=*)" -d 1 ldap_create ldap_url_parse_ext(ldap://localhost) 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 localhost:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 127.0.0.1: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 0x6120c0 msgid 1 wait4msg ld 0x6120c0 msgid 1 (infinite timeout) wait4msg continue ld 0x6120c0 msgid 1 all 1 ** ld 0x6120c0 Connections: * host: localhost port: 389 (default) refcnt: 2 status: Connected last used: Tue Apr 1 21:34:42 2008 ** ld 0x6120c0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x6120c0 request count 1 (abandoned 0) ** ld 0x6120c0 Response Queue: Empty ld 0x6120c0 response count 0 ldap_chkResponseList ld 0x6120c0 msgid 1 all 1 ldap_chkResponseList returns ld 0x6120c0 NULL ldap_int_select read1msg: ld 0x6120c0 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x6120c0 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x6120c0 0 new referrals read1msg: mark request completed, ld 0x6120c0 msgid 1 request done: ld 0x6120c0 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 ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({i) ber: ber_flush2: 14 bytes to sd 3 ldap_result ld 0x6120c0 msgid 2 wait4msg ld 0x6120c0 msgid 2 (infinite timeout) wait4msg continue ld 0x6120c0 msgid 2 all 1 ** ld 0x6120c0 Connections: * host: localhost port: 389 (default) refcnt: 2 status: Connected last used: Tue Apr 1 21:34:42 2008 ** ld 0x6120c0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x6120c0 request count 1 (abandoned 0) ** ld 0x6120c0 Response Queue: Empty ld 0x6120c0 response count 0 ldap_chkResponseList ld 0x6120c0 msgid 2 all 1 ldap_chkResponseList returns ld 0x6120c0 NULL ldap_int_select read1msg: ld 0x6120c0 msgid 2 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x6120c0 msgid 2 message type bind ber_scanf fmt ({eAA) ber: read1msg: ld 0x6120c0 0 new referrals read1msg: mark request completed, ld 0x6120c0 msgid 2 request done: ld 0x6120c0 msgid 2 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 2, msgid 2) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree # extended LDIF # # LDAPv3 # base <dc=foo-bar,dc=baz> with scope subtree # filter: (objectClass=*) # requesting: ALL # ldap_search_ext put_filter: "(objectClass=*)" put_filter: simple put_simple_filter: "objectClass=*" ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 56 bytes to sd 3 ldap_result ld 0x6120c0 msgid -1 wait4msg ld 0x6120c0 msgid -1 (infinite timeout) wait4msg continue ld 0x6120c0 msgid -1 all 0 ** ld 0x6120c0 Connections: * host: localhost port: 389 (default) refcnt: 2 status: Connected last used: Tue Apr 1 21:34:42 2008 ** ld 0x6120c0 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x6120c0 request count 1 (abandoned 0) ** ld 0x6120c0 Response Queue: Empty ld 0x6120c0 response count 0 ldap_chkResponseList ld 0x6120c0 msgid -1 all 0 ldap_chkResponseList returns ld 0x6120c0 NULL ldap_int_select read1msg: ld 0x6120c0 msgid -1 all 0 ber_get_next ber_get_next: tag 0x30 len 49 contents: read1msg: ld 0x6120c0 msgid 3 message type search-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x6120c0 0 new referrals read1msg: mark request completed, ld 0x6120c0 msgid 3 request done: ld 0x6120c0 msgid 3 res_errno: 13, res_error: <stronger TLS confidentiality required>, res_matched: <> ldap_free_request (origid 3, msgid 3) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 # search result search: 3 ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_err2string result: 13 Confidentiality required text: stronger TLS confidentiality required ldap_msgfree # numResponses: 1 ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 ldap_free_connection: actually freed [EMAIL PROTECTED]:~$ >> gnutls-cli says: > >> [EMAIL PROTECTED]:~$ gnutls-cli-debug host -p 389 [...] > TLS negotiation is protocol-specific; connecting on the LDAP port with > gnutls-cli is not a meaningful test of TLS support. oic!? i thought TLS works like a wrapper and has a common handshake for any protocol it subsequently transports... i would have found that elegant (and handy, e.g. for debugging with gnutls-cli ;) - toobad. >> when trying a query with TLS, slapd -d 1 says: > >> slap_listener_activate(8): >>>>> slap_listener(ldap:///) >> connection_get(13): got connid=0 >> connection_read(13): checking for input on id=0 >> ber_get_next >> ber_get_next: tag 0x30 len 29 contents: >> ber_get_next >> conn=0 op=0 do_extended >> ber_scanf fmt ({m) ber: >> send_ldap_extended: err=0 oid= len=0 >> send_ldap_response: msgid=1 tag=120 err=0 >> ber_flush2: 14 bytes to sd 13 >> connection_get(13): got connid=0 >> connection_read(13): checking for input on id=0 >> TLS: can't accept: A record packet with illegal version was received.. >> connection_read(13): TLS accept failure error=-1 id=0, closing >> connection_closing: readying conn=0 sd=13 for close >> connection_close: conn=0 sd=13 > > That's with what client? Probably with gnutls-cli? that was a ldapsearch. but apart from the error messages that certainly have quite some potential for improvement ;) i guess this can be ignored because my test-setup was incorrect (the .ldaprc)... > I haven't tested the -6.1 NMU specifically, but "worksforme" on the previous > builds of 2.4.7, and indeed I tested TLS support quite extensively while > getting 2.4.7 into shape for Debian. did you by chance test the server-cert-but-no-client-certs scenario? regards, Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
