Lars Schimmer <l.schimmer@cgv.tugraz.at> (Fr 17 Jan 2014 11:19:24 CET):
>
> 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
> ---
Das sieht so aus, als würde dort gar kein SSL gesprochen.
> 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:
…
> 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.
…
>
> Auch wenn mir das etwas komisch für SSL vorkommt, eher TLS?
Auf 636 ist „ssl on connect“, dort müsste also der s_client sofort
erfolgereich mit einem SSL-Handshake anfangen. Wenn das nicht so ist,
könnte es Klartext sein, dann müsste aber das funktionieren, eben LDAP
ohne „s“:
ldapsearch -H ldap://…:636/
ebenso wie
ldapsearch -H ldap://…/
Wie ist das Symptom bei
LDAPTLS_REQCERT=never \
ldapsearch -Z -H ldap://…/
und
LDAPTLS_REQCERT=never \
ldapsearch -ZZ -H ldap://…/
Das sollte TCP|LDAP|TLS machen. Im Unterschied zum
Port 636 mit ldaps, wo TCP|TLS|LDAP gemacht wird.
Sagt der Server etwas, wenn Du mit dem s_client auf den Port 636 gehst?
Was steht in der Prozessliste der Serverseite beim slapd?
slapd … ldaps:/// ldap:///
??
--
Heiko
Attachment:
signature.asc
Description: Digital signature