Mathieu MILLET wrote:
On Wed, 25 Mar 2009 15:09:09 +0100, Peter Mogensen apm@mutex.dk wrote:
I have problem with SASL/EXTERNAL and TLS. The server can't seem to find the client certificate. I'm using slapd from Debian Lenny and Ubuntu Hardy, and it's probably due to GnuTLS problems. I get error from slapd like: "TLS: can't accept: A TLS packet with unexpected length was received.."
Oh ... forget this one. I found the reason for this. It was my fault.
"unable to get TLS client DN, error=-4 id=0" Are GnuTLS just completely broken on Debian Lenny or can this be made to work?
Which version of OpenLDAP are you using ? If using 2.4.15, the ldap "client" libs have broken SASL/EXTERNAL implementation. These libs are also used for consumer to connect to provider.
2.4.9-0ubuntu0.8.0 I haven't checked which upstream version the patches makes it equivalent to though.
Doing: ldapwhoami -YEXTERNAL -H ldaps://server:389/ I'm stepping through the SSL handshake with wireshark and it seems to get all the way through to the servers ChangeChipherSpec/Finish stage after which the client sends a TCP FIN,ACK.
slapd output is: connection_get(10): got connid=11 connection_read(10): checking for input on id=11 connection_get(10): got connid=11 connection_read(10): checking for input on id=11 connection_get(10): got connid=11 connection_read(10): checking for input on id=11 connection_get(10): got connid=11 connection_read(10): checking for input on id=11 connection_get(10): got connid=11 connection_read(10): checking for input on id=11 connection_read(10): unable to get TLS client DN, error=-4 id=11 connection_get(10): got connid=11 connection_read(10): checking for input on id=11 ber_get_next ber_get_next on fd 10 failed errno=0 (Success) connection_closing: readying conn=11 sd=10 for close connection_close: conn=11 sd=10
According to wireshark it's TLSv1.1. I think I read somewhere that GnuTLS don't like that, but I can't figure out how do downgrade to TLSv1.0
/Peter