On 2014-01-16 20:10, Heiko Schlittermann wrote: > Lars Schimmer <l.schimmer@cgv.tugraz.at> (Do 16 Jan 2014 15:50:14 CET): >> On 2014-01-16 14:53, Christian Schmidt wrote: >>> 16.01.2014 14:18, Lars Schimmer: >>>> Ich bin ein wenig am Verzweifeln. Ich habe einen LDAP Server unter >>>> Debian Wheezy aufgesetzt und versuche den nun mit LDAPS:// >>>> anzusprechen. Unter ldap:// funktioniert dieser wie erwartet, aber >>>> ldaps:// kommt immer der selbe Fehler: >>>> >>>> ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS: can't connect: A TLS >>>> packet with unexpected length was received.. ldap_err2string >>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>> >>> Wie sehen die "Client-Einstellungen" aus? Sprich: Wie (=über welches >>> Interface) kontaktierst Du den Server? Und was steht als CN bzw. >>> Hostname in Deinem SSL-Zertifikat? Lauscht Dein slapd auf Port 636? >>> => Mehr Details! >> >> Ich versuch das ganze via 2. Linux Client mit ldapsearch, CN ist >> CN=*.cgv.org auf dem Server (Wildcard halt). Der slapd lauscht wie >> erwartet auf Port 636, sonst würd ja keine Fehlermeldung beim ldaosearch >> kommen ;-) >> >> Hostname sei dann ldap.cgv.org - und somit im Wildcard mit drinnen, es >> sei denn, slapd kann mit Wildcards ned um? >> Das der Client im ldap.conf auch die CA Cert braucht, it auch schon >> beachtet. > > Was passiert, wenn Du > > openssl s_client -CAfile <TLS_CACERT von ldap.conf> server:636 > > probierst? Gelinkt die Zertifikatsprüfung? Hm, nö. Interessant: schimmer@tetris ~ % openssl s_client -CAfile /etc/ssl/certs/cgv.org.2.crt -host 129.27.218.1 -port 636 CONNECTED(00000003) 140350555530920:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 320 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- Was will der mir jetzt damit sagen, das da kein SSL lauscht? Das das Zertifikat ned passt? Jedenfalls ergibt eine Abfrage: ldapsearch -d 1 -v -b 'dc=cgv, dc=org' -x -H ldap://ldap.cgv.org:636 was anderes als ldapsearch -d 1 -v -b 'dc=cgv, dc=org' -x -H ldap://ldap.cgv.org - bei letzterer zeigt er die Einträge an, bei der :636 gibt es ne Fehlermeldung: ** ld 0x7fb3cd4b30e0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x7fb3cd4b30e0 request count 1 (abandoned 0) ** ld 0x7fb3cd4b30e0 Response Queue: Empty ld 0x7fb3cd4b30e0 response count 0 ldap_chkResponseList ld 0x7fb3cd4b30e0 msgid 1 all 1 ldap_chkResponseList returns ld 0x7fb3cd4b30e0 NULL ldap_int_select read1msg: ld 0x7fb3cd4b30e0 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 > … und daß TLS_CACERTDIR von ignoriert wird, weißt Du? (ldapsearch ist > gegen GnuTLS gelinkt, also wird nur TLS_CACERT (ein File!) gelesen. Ja, schon gemerkt. Das CACERT file ist am server und am Client ident. Und certtool wirft aus: Chain verification output: Verified. The certificate is trusted. Auf dem ldap server seht in der ldap.conf die Zeile: URI ldap://ldap.cgv.org ldaps://ldap.cgv.org:636 Ich bin davon ausgegangen, das damit der slapd auf port 636 mit ldaps:// lauscht, ein Telnet auf 636 ergibt auch nen wartenden Dienst: Trying 129.27.218.1... Connected to ldap.cgv.org. Escape character is '^]'. Auch wenn mir das etwas komisch für SSL vorkommt, eher TLS? ... Danke soweit. > Best regards from Dresden/Germany > Viele Grüße aus Dresden > Heiko Schlittermann > MfG, Lars Schimmer -- ------------------------------------------------------------- TU Graz, Institut für ComputerGraphik & WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schimmer@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723
Attachment:
signature.asc
Description: OpenPGP digital signature