slapd + gnutls fails

[Lari Huttunen]

Binary package hint: slapd

= SLAPD + GnuTLS fails =

ldaps connections require a client cert although it has been disabled from
the slapd.conf.

== client-side ==

{{{
$ ldapsearch -x
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
}}}

== server-side ==

{{{
connection_read(14): unable to get TLS client DN, error=49 id=0
}}}

== slap.conf ==

{{{
## SSL:
TLSCACertificateFile /etc/local/pki/tls/certs/ca.nnn.nnn.crt
TLSCertificateFile /etc/local/pki/tls/certs/ldap.nnn.nnn.crt
TLSCertificateKeyFile /etc/local/pki/tls/private/ldap.nnn.nnn.key
TLSVerifyClient never
}}}

= OS Details =

 OS:: Ubuntu 8.0.4

{{{
ii slapd 2.4.7-6ubuntu3 OpenLDAP server (slapd)
ii libgnutls13 2.0.4-1ubuntu2 the GNU TLS library - runtime library
}}}

[Lari Huttunen (debian-huttu)]

cannot choose slapd for some reason for this bug report. :/

[Lari Huttunen (debian-huttu)]

Why is the source package openldap2.3 although slapd version is 2.4.7?

[Adam Sommer (asommer)]

Thank you for reporting this bug and helping to make Ubuntu better. I am able to use TLS with slapd without any problems, but one thing I had to adjust was to give the openldap user access to the directory containing the certificate and key.

I placed my cert in /etc/ssl/certs, and the key in /etc/ssl/private. Since the /etc/ssl/private directory's group ownership is ssl-cert I executed:

  sudo adduser openldap ssl-cert

Then restarted slapd, and everything worked fine using the configuration example you posted above (but with different directories). I'm using a self-singed cert and CA cert. Can you double check that the openldap user has access to your cert directory? Also another thing to try is adding the following to /etc/ldap/ldap.conf:

  TLS_REQCERT never

Then restart slapd and see if you can connect.

Thanks again.

[Jamie Strandboge (jdstrand)]

If you apparmor is enabled (the default on a new install) and you are not using /etc/ssl, /etc/ssl/certs and /etc/ssl/private for your SSL certificates, then you will also need to adjust your apparmor profile. See https://wiki.ubuntu.com/DebuggingApparmor for details.

[Lari Huttunen (debian-huttu)]

That was the first thing I stumbled upon, so I don't think it's that.
Slapd won't start if it can't read the pki files. I've adjusted the
apparmor profile as follows:

$ cat usr.sbin.slapd
# vim:syntax=apparmor
# Last Modified: Fri Jan 4 15:18:13 2008
# Author: Jamie Strandboge <email address hidden>

#include <tunables/global>

/usr/sbin/slapd {
  #include <abstractions/base>
  #include <abstractions/nameservice>

  #include <abstractions/ssl_certs>
  /etc/local/pki/tls/certs/ca.nnn.nnn.crt r,
  /etc/local/pki/tls/certs/ldap.nnn.nnn.crt r,
  /etc/local/pki/tls/private/ldap.nnn.nnn.key r,

  /etc/sasldb2 r,

  capability dac_override,
  capability net_bind_service,
  capability setgid,
  capability setuid,

  /etc/gai.conf r,
  /etc/hosts.allow r,
  /etc/hosts.deny r,
  /etc/ldap/ldap.conf r,
  /etc/ldap/schema/* r,
  /etc/ldap/slapd.conf r,

  # the databases and logs
  /var/lib/ldap/ r,
  /var/lib/ldap/* rw,

  # lock file
  /var/lib/ldap/alock kw,

  # pid files and sockets
  /var/run/slapd/* w,

  /usr/lib/ldap/ r,
  /usr/lib/ldap/* mr,

  /usr/sbin/slapd mr,
}

[Lari Huttunen (debian-huttu)]

... but TLS_REQCERT never in the client confs helps, but makes me wonder:

$ man ldap.conf

TLS_REQCERT <level>

 never The client will not request or check any server certificate.

This probably should not be the case. Previously <allow> has worked, which
is still a bit dubious.

 allow The server certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is
           provided, it will be ignored and the session proceeds normally.

Is there any way to make it work with <try> for example?

This is not a major thing and thanks for your help, in pointing out the obvious problem. :)
Shouldn't trust and old config, I guess. :)

For the sake of documentation here are the client confs:

$ cat /etc/ldap/ldap.conf
#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

URI ldaps://127.0.0.1/
BASE dc=nnn,dc=nnn
TLS_REQCERT never

$ cat /etc/ldap.conf
base dc=nnn,dc=nnn
uri ldaps://127.0.0.1/
timelimit 120
bind_timelimit 120
idle_timelimit 3600
ssl on
pam_password exop
bind_policy soft
TLS_CACERTFILE /etc/pki/tls/certs/ca.nnn.nnn.crt
TLS_REQCERT never

Any comments on those? I've also dabbled with the nss_initgroups_ignoreusers parameter, but
don't have any conclusive results on that.

[Adam Sommer (asommer)]

>
> $ cat /etc/ldap/ldap.conf
> #
> # LDAP Defaults
> #
>
> # See ldap.conf(5) for details
> # This file should be world readable but not world writable.
>
> URI ldaps://127.0.0.1/
> BASE dc=nnn,dc=nnn
> TLS_REQCERT never
>
> $ cat /etc/ldap.conf
> base dc=nnn,dc=nnn
> uri ldaps://127.0.0.1/
> timelimit 120
> bind_timelimit 120
> idle_timelimit 3600
> ssl on
> pam_password exop
> bind_policy soft
> TLS_CACERTFILE /etc/pki/tls/certs/ca.nnn.nnn.crt
> TLS_REQCERT never
>
> Any comments on those? I've also dabbled with the
> nss_initgroups_ignoreusers parameter, but
> don't have any conclusive results on that.
>
>
I copied your config into my /etc/ldap/ldap.conf (changing the base
parameter), and using "TLS_REQCERT allow" worked fine for me. I use "never"
because my LDAP server is using a self-signed cert, and there used to be
issues without setting that option. The server I'm testing with was
upgraded from Dapper to Hardy.

I was just wondering if you are using libnss-ldap? Could it possibly be a
setting in /etc/ldap.conf?

--
Party On,
Adam

[Brian May (brian-microcomaustralia)]

There seems to be some confusion here.

TLS_REQCERT on the client tells the client if it should check the server certificate or not.

This is different whether or not the server checks the client certificate or not.

I am having problems with the client checking the server certificate (#231321), where changing TLS_REQCERT will help (but this presumably will decrease the security because the server certificate is not checked).

This bug report started of by saying that the server having problems with the client certificate.

Brian May

[Chuck Short (zulcss)]

Hi,

Can you try the version of openldap in my ppa archive?

http://launchpad.net/~zulcss/+archive

Thanks
chuck

[Mathias Gug (mathiaz)]

Could you try using the debug option when running ldapsearch on the client ?

  ldapsearch -x -d 1

[Ronald van Engelen (ronalde)]

I'm having the same problems:
 * `TLS_REQCERT=never` needed in `/etc/ldap.conf` (`/etc/ldap/ldap.conf` is a symlink to the former)
 * openldap user can't access ssl-certificates; fixed with `adduser openldap ssl-cert `

After applying those fixes pam works but nss doesn't i.e. a normal user can log in but seems unknown (prompt reads `nosuchuser@localhost:~$`).

It seems this has to to do with some process which lacks permissions to the ldap-config files in the directory `/etc/ldap`; because some of these files might contain sensitive information documentation suggests to restrict access to the owner and group:

{{{
ls -la /etc/ldap
lrwxrwxrwx 1 openldap openldap 14 2008-08-24 23:55 ldap.conf -> /etc/ldap.conf
drwxr-x--- 2 openldap openldap 4096 2008-06-14 15:16 sasl2
drwxr-x--- 2 openldap openldap 4096 2008-08-30 11:36 schema
-rw-r----- 1 openldap openldap 900 2008-09-08 08:20 slapd.conf

-rw-r----- 1 openldap openldap 671 2008-09-08 09:32 slapd.consumer.conf
-rw-r----- 1 openldap openldap 2970 2008-08-25 09:42 slapd.databases.conf
-rw-r----- 1 openldap openldap 483 2008-08-25 01:38 slapd.master.conf
-rw-r----- 1 openldap openldap 1236 2008-06-19 13:21 slapd.schemas.conf
}}}

[Ronald van Engelen (ronalde)]

Ronald van Engelen wrote on 2008-09-08:
> I'm having the same problems:

I didn't catch Brian May's statement:
> This bug report started of by saying that the server having problems with the client certificate.

My comment is about clients (nss) not able to use ldaps; I will try to solve this elsewhere.

[elvis (elvisa)]

I am also having problems with Hardy slapd 2.4.9-0ubuntu0.8.04.2 and TLS.

It seems OpenLDAP on Hardy is now compiled against GnuTLS, and not OpenSSL as it was in old versions.

I've created x509 certificates and signed them against our company CA. These work perfectly for Apache on Hardy (adding the CA cert to by browser shows connection to Apache as working and verified).

Experiments with gnutls-cli show the following:

1) Connecting to Apache on port 443 shows TLS success, connected via TLS 1.0:
Processed 1 CA certificate(s).
Processed 1 client certificates...
Processed 1 client X.509 certificates...
Resolving '***'...
Connecting to '10.1.2.100:443'...
- Certificate type: X.509
 - Got a certificate list of 2 certificates.

 - Certificate[0] info:
 # The hostname in the certificate matches '***'.
 # valid since: Fri Feb 6 14:36:14 EST 2009
 # expires at: Sun Feb 6 14:36:14 EST 2011
 # fingerprint: 7E:C2:AF:1B:75:7A:CB:0F:17:A6:10:8C:8B:1C:52:2B
 # Subject's DN: ***
 # Issuer's DN: ***

 - Certificate[1] info:
 # valid since: Tue Dec 5 13:42:33 EST 2006
 # expires at: Mon Dec 5 13:49:02 EST 2011
 # fingerprint: D5:63:08:F0:9C:E2:BB:47:35:EF:06:15:EF:54:DA:D8
 # Subject's DN: ***
 # Issuer's DN: ***

- Peer's certificate is trusted
- Version: TLS 1.0
- Key Exchange: DHE RSA
- Cipher: AES 256 CBC
- MAC: SHA
- Compression: DEFLATE
- Handshake was completed

2) Connection to gnutls-serv on port 5556 shows TLS success, connected via TLS 1.1
Processed 1 CA certificate(s).
Processed 1 client certificates...
Processed 1 client X.509 certificates...
Resolving '***'...
Connecting to '10.1.2.100:5556'...
- Certificate type: X.509
 - Got a certificate list of 1 certificates.

 - Certificate[0] info:
 # The hostname in the certificate matches '***'.
 # valid since: Fri Feb 6 14:36:14 EST 2009
 # expires at: Sun Feb 6 14:36:14 EST 2011
 # fingerprint: 7E:C2:AF:1B:75:7A:CB:0F:17:A6:10:8C:8B:1C:52:2B
 # Subject's DN: ***
 # Issuer's DN: ***

- Peer's certificate is trusted
- Version: TLS 1.1
- Key Exchange: DHE RSA
- Cipher: AES 256 CBC
- MAC: SHA
- Compression: DEFLATE
- Handshake was completed

- Simple Client Mode:

3) Connection to slapd on ldaps:// port 636 shows:
Processed 1 CA certificate(s).
Processed 1 client certificates...
Processed 1 client X.509 certificates...
Resolving '***'...
Connecting to '10.1.2.100:636'...
*** Fatal error: A TLS packet with unexpected length was received.
*** Handshake has failed
GNUTLS ERROR: A TLS packet with unexpected length was received.

Using ldapsearch on plain-text ldap:/// port 389 works fine. ldapsearch on ldaps:/// returns errors. Running slapd in debug mode shows various errors, including similar "TLS packet of unexpected length" errors:

client: ldapsearch -x -H ldaps://localhost:636 -D "***" -w "***"

server:
>>> slap_listener(ldaps:///)
connection_get(13): got connid=1
connection_read(13): checking for input on id=1
connection_read(13): TLS accept failure error=-1 id=1, closing
connection_closing: readying conn=1 sd=13 for close
connection_close: conn=1 sd=13

[Mathias Gug (mathiaz)]

On Thu, Feb 26, 2009 at 04:48:11AM -0000, elvis wrote:
> I've created x509 certificates and signed them against our company CA.
> These work perfectly for Apache on Hardy (adding the CA cert to by
> browser shows connection to Apache as working and verified).
>
> Experiments with gnutls-cli show the following:

>
> 3) Connection to slapd on ldaps:// port 636 shows:
> Processed 1 CA certificate(s).
> Processed 1 client certificates...
> Processed 1 client X.509 certificates...
> Resolving '***'...
> Connecting to '10.1.2.100:636'...
> *** Fatal error: A TLS packet with unexpected length was received.
> *** Handshake has failed
> GNUTLS ERROR: A TLS packet with unexpected length was received.
>

What is the exact command line you've used (gnutls-cli)?

>
> Using ldapsearch on plain-text ldap:/// port 389 works fine. ldapsearch on ldaps:/// returns errors.

What is the error message?

--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com

[elvis (elvisa)]

As above:

client: ldapsearch -x -H ldaps://localhost:636 -D "***" -w "***"

server:
>>> slap_listener(ldaps:///)
connection_get(13): got connid=1
connection_read(13): checking for input on id=1
connection_read(13): TLS accept failure error=-1 id=1, closing
connection_closing: readying conn=1 sd=13 for close
connection_close: conn=1 sd=13

That was running slapd with "-d3". Do you require more detailed than that?

[elvis (elvisa)]

Oh, and the gnutls-cli stuff:

I opened the listening server with:
gnutls-serv --x509cafile my_ca.cer --x509keyfile myclient.pem --x509certfile myclient.cer

It returns:
Set static Diffie Hellman parameters, consider --dhparams.
Processed 1 CA certificate(s).
Echo Server ready. Listening to port '5556'.

I connected to the gnutls-serv with:
gnutls-cli --x509cafile my_ca.cer --x509keyfile myclient.pem --x509certfile myclient.cer -p 5556 servername.mydomain.tld

Similarly, I connected to Apache with
gnutls-cli --x509cafile my_ca.cer --x509keyfile myclient.pem --x509certfile myclient.cer -p 443 servername.mydomain.tld

And slapd with:
gnutls-cli --x509cafile my_ca.cer --x509keyfile myclient.pem --x509certfile myclient.cer -p 636 servername.mydomain.tld

Ports are listening and verified with "netstat -plutn". Tests were run on both localhost, and from another machine with copies of the certs. No firewalls are in place, and iptables is set to "ACCEPT" on all policies with no other rules in place.

As above, I get successful returns from Apache-SSL and gnutls-serv. I get a failure from slapd.

If you need more detail or other tests, please let me know and I'll run them.

[elvis (elvisa)]

This is run with:
/usr/sbin/slapd -h ldaps:/// -g openldap -u openldap -f /etc/ldap/slapd.conf -d15

Connecting from either "ldapsearch -x -H ldaps://..." or gnutls-cli, slapd returns:

>>> slap_listener(ldaps:///)
daemon: listen=8, new connection on 13
daemon: added 13r (active) listener=(nil)
daemon: activity on 1 descriptor
daemon: activity on:
daemon: epoll: listen=7 active_threads=0 tvp=zero
daemon: epoll: listen=8 active_threads=0 tvp=zero
daemon: activity on 1 descriptor
daemon: activity on: 13r
daemon: read active on 13
daemon: epoll: listen=7 active_threads=0 tvp=zero
daemon: epoll: listen=8 active_threads=0 tvp=zero
connection_get(13)
connection_get(13): got connid=0
connection_read(13): checking for input on id=0
tls_read: want=5, got=5
  0000: 16 03 02 00 4d ....M
tls_read: want=77, got=77
  0000: 01 00 00 49 03 02 49 a7 3e 1c 36 94 5c 6e cb ce ...I..I.>.6.\n..
  0010: 5a ee 9c 8e af cd aa dd a2 9a 53 48 db 0a bd 00 Z.........SH....
  0020: 32 9e f4 e2 1a c9 00 00 18 00 39 00 33 00 16 00 2.........9.3...
  0030: 38 00 32 00 13 00 66 00 35 00 2f 00 0a 00 05 00 8.2...f.5./.....
  0040: 04 02 01 00 00 07 00 09 00 03 02 00 01 .............
TLS: can't accept: Could not negotiate a supported cipher suite..
connection_read(13): TLS accept failure error=-1 id=0, closing
connection_closing: readying conn=0 sd=13 for close
daemon: activity on 1 descriptor
daemon: activity on:
daemon: epoll: listen=7 active_threads=0 tvp=zero
daemon: epoll: listen=8 active_threads=0 tvp=zero
connection_close: conn=0 sd=13
daemon: removing 13

[Mathias Gug (mathiaz)]

@elvis:
According to the slapd log:

TLS: can't accept: Could not negotiate a supported cipher suite..

Could you post your slapd.conf file? Becareful to not include any sensitive information such as passwords.

[elvis (elvisa)]

Unfortunately I've decommissioned the machine. However I do know that I didn't manually specify any TLSCipherSuite directives in the slapd.conf.

The hardy slapd.conf man (5) file still references the TLSCipherSuite format accepted by OpenSSL (e.g.: "TLSCipherSuite HIGH:MEDIUM:+SSLv2"), which caused slapd to fail in start as GnuTLS doesn't support this format. As such I removed the directive (allowing all ciphers supported by GnuTLS) which would allow slapd to start.

Similarly my ldap.conf didn't specify any cipher suite, and the gnutls-cli testing above didn't either.

If I get time I will attempt to rebuild and retest from where I left off.

[Adrian Bridgett (adrian-bridgett)]

FWIW I've got the same on a debian box I've just upgraded from etch to lenny:
slapd 2.4.11-1
libldap-2.4-2 2.4.11-1
libgnutls26 2.4.2-6+lenny1

certs are not blacklisted (checked ca and server), gnutls-serv works fine.

tracign with openssl shows a very quick reply:
openssl s_client -connect localhost:636 -debug
CONNECTED(00000003)
write to 0x68d7c0 [0x68e390] (118 bytes => 118 (0x76))
0000 - 80 74 01 03 01 00 4b 00-00 00 20 00 00 39 00 00 .t....K... ..9..
0010 - 38 00 00 35 00 00 16 00-00 13 00 00 0a 07 00 c0 8..5............
0020 - 00 00 33 00 00 32 00 00-2f 03 00 80 00 00 05 00 ..3..2../.......
0030 - 00 04 01 00 80 00 00 15-00 00 12 00 00 09 06 00 ................
0040 - 40 00 00 14 00 00 11 00-00 08 00 00 06 04 00 80 @...............
0050 - 00 00 03 02 00 80 88 ce-a0 bb 73 ed f1 ba 4a 72 ..........s...Jr
0060 - de c5 25 dc 88 8d b5 8a-d7 15 10 17 68 46 a7 23 ..%.........hF.#
0070 - 94 41 2e 07 92 aa .A....
read from 0x68d7c0 [0x6938f0] (7 bytes => 0 (0x0))
8434:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:

gnutls-cli -l shows a huge list too. permissions all seem fine (and readable)

[Mathias Gug (mathiaz)]

Could you please include the information requested at
https://wiki.ubuntu.com/DebuggingOpenldap#ssl-client-failure?

Thank you,

--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com

[Adrian Bridgett (adrian-bridgett)]

sure:

/etc/ldap/ldap.conf:
BASE dc=opsera,dc=com
URI ldap://foo.opsera.com
TLS_CACERT /etc/ssl/certs/ca.opsera.com.crt
TLS_REQCERT demand

TLS_CACERT file:
-----BEGIN CERTIFICATE-----
MIIEUTCCAzmgAwIBAgIJAI+dj7GhDEy1MA0GCSqGSIb3DQEBBQUAMHgxCzAJBgNV
BAYTAkdCMRIwEAYDVQQIEwlCZXJrc2hpcmUxEDAOBgNVBAcTB1JlYWRpbmcxDzAN
BgNVBAoTBk9wc2VyYTESMBAGA1UEAxMJT3BzZXJhIENBMR4wHAYJKoZIhvcNAQkB
Fg9yb290QG9wc2VyYS5jb20wHhcNMDgwNTE0MTEyNDAxWhcNMTgwNTEyMTEyNDAx
WjB4MQswCQYDVQQGEwJHQjESMBAGA1UECBMJQmVya3NoaXJlMRAwDgYDVQQHEwdS
ZWFkaW5nMQ8wDQYDVQQKEwZPcHNlcmExEjAQBgNVBAMTCU9wc2VyYSBDQTEeMBwG
CSqGSIb3DQEJARYPcm9vdEBvcHNlcmEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEA5NBn4qZQmpNSfAZGicY11YoRbG2ZW+IMNd6P0t3uqbqlS/xd
toLXiLQOKcm0k1FdBXgeredDAd7Lm0KOvXOu85oDcSB4Y+8Xny0ug/oyw5HhrvaT
ACP4DdFkVK0rOncpgqjUoPPlHpAtRE+vruxgYqG4WHRZQv2aIfDCLP1vorLNLl68
JoPsTfP8O4ISOHVY5KlmngOjBeU0JuFP7luFoPshXbxpQ8VL2frTNLV3SKpU7zMe
QGkUh+86HSCKxk3ahq5grZIYLm+RlOXORTisT8xK6VWTDO1O0DF1HnVN/pkx6AwN
HyC4sveyYzm4f+nwVTFd/vKXVRHWJoKLltSUkwIDAQABo4HdMIHaMB0GA1UdDgQW
BBQ7ztgRvxawSnughvTiN0BuzzrOMDCBqgYDVR0jBIGiMIGfgBQ7ztgRvxawSnug
hvTiN0BuzzrOMKF8pHoweDELMAkGA1UEBhMCR0IxEjAQBgNVBAgTCUJlcmtzaGly
ZTEQMA4GA1UEBxMHUmVhZGluZzEPMA0GA1UEChMGT3BzZXJhMRIwEAYDVQQDEwlP
cHNlcmEgQ0ExHjAcBgkqhkiG9w0BCQEWD3Jvb3RAb3BzZXJhLmNvbYIJAI+dj7Gh
DEy1MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADggEBAKtJww1eJjGtr3c4
xrvRfNlS5FJphmh6xqIyTJf7cglcOziob/FtPD7HJ3FLq2dj1uwRlbreTzTmpajl
hr4h/2gxjLTjrMSriLbHjuBhuotHa8/NsuFm3USWZyca0zASOQV4+yGu4AydUmo5
vcOymiVZ4JWprPC4bmALti8ykqejDjhydcl8Vd9nLKz8KuU1EwBMWHtBjSfkuAao
IxJZHNTpi+iBXRFguola0aTX3K0g1+IABaYKb1MUerszmvXdqaJ0KnszT79d9R2u
XavJFc33egXQUO7K/Vm0tg2+phP7QbRwix95pNP8jkalWbCuXMDbMqLNBN28+u3V
w4gO30E=
-----END CERTIFICATE-----

gnutls-cli output:
Connecting to '127.0.1.1:636'...
*** Fatal error: A TLS packet with unexpected length was received.
*** Handshake has failed
GNUTLS ERROR: A TLS packet with unexpected length was received.

package versions:
gnutls-bin 2.4.2-6+lenny1 gnutls26 install ok installed
ldap-utils 2.4.11-1 openldap install ok installed
libgnutls26 2.4.2-6+lenny1 gnutls26 install ok installed
libldap-2.4-2 2.4.11-1 openldap install ok installed
libnss-ldap 261-2.1 install ok installed
libpam-ldap 184-4.2 install ok installed
slapd 2.4.11-1 openldap install ok installed
sudo-ldap 1.6.9p17-2.1 sudo install ok installed

ldapsearch:
ldap_url_parse_ext(ldaps://foo.opsera.com/)
ldap_create
ldap_url_parse_ext(ldaps://foo.opsera.com:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP foo.opsera.com:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 127.0.1.1:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
tls_write: want=93, written=93
  0000: 16 03 02 00 58 01 00 00 54 03 02 49 ef 6d 28 ac ....X...T..I.m(.
  0010: b6 ff 62 fd 12 78 93 a8 58 cb f7 39 a6 b7 61 59 ..b..x..X..9..aY
  0020: 1e 8f f4 5a 5d 4c a6 83 b5 73 d0 00 00 24 00 33 ...Z]L...s...$.3
  0030: 00 45 00 39 00 88 00 16 00 32 00 44 00 38 00 87 .E.9.....2.D.8..
  0040: 00 13 00 66 00 2f 00 41 00 35 00 84 00 0a 00 05 ...f./.A.5......
  0050: 00 04 01 00 00 07 00 09 00 03 02 00 01 ...

[Adrian Bridgett (adrian-bridgett)]

FYI I've compiled up 2.4.16 (took 2.4.15 from debian and updated source), added a patch from http://209.85.229.132/search?q=cache:idWE3JHeQOUJ:www.openldap.org/its/index.cgi/Software%2520Bugs%3Fid%3D6053%3Bpage%3D1+"main:+TLS+init+def+ctx+failed:+-50"&cd=1&hl=en&ct=clnk&gl=uk&lr=lang_en

(Subject: gnutls doen't initialize gnutls_x509_privkey_t structure, leading to TLS init def ctx failed: -50)

and it still does the same thing. tcpdump shows SSL client hello being sent, then the ldap server just closes the connection on it :-( (slapd logs saying Could not negotiate a supported cipher suite)

[Adrian Bridgett (adrian-bridgett)]

http://www.openldap.org/its/index.cgi/Software Bugs?id=6053;expression=gnutls is a better link to that patch

compiled with openssl rather than gnutls and it's happier..

Aha!!! Found it :-) openssl client then complained that the ceritficate was not suitable for the purpose. In short, I had put a client cert on, not a server set. I use easy-rsa2 from openvpn package to build certs and I had ran it with ./build-key not ./build-key-server. Once the ldap keypair was rebuilt with "-extensions server" everthing was happy (even on the older version of software).

Naturally it would be nice if openldap checked this and produced a helpful error :-)

many thanks for your help and prompt replies.

[Mathias Gug (mathiaz)]

Seems that the last commenter was able to fix his problem. I'm going to mark this bug invalid. Please open a new bug if you encounter a similar problem.

[Adrian Bridgett (adrian-bridgett)]

I _think_ that the problem was that the LDAP server certificate was just a regular SSL certificate and it needed recreating as a "server" certificate (build-key-server from easy-rsa tools):
nsCertType = server
extendedKeyUsage=serverAuth
keyUsage = digitalSignature, keyEncipherment

[Luis Mondesi (lemsx1)]

this bug should be closed.

I had the same problem today and I simply commented out the TLS suite portion. That allowed things to work just fine.

(see comment # 19 https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/217159/comments/19 )

The documentation should be updated not to say to use TLSCipherSuite HIGH:MEDIUM:+SSLv2 -- especially the wiki.

[Adrian Bridgett (adrian-bridgett)]

FYI I just hit another issue where ldap wouldn't start with errors like this:
TLS init def ctx failed: -207
slapd stopped.
connections_destroy: nothing to destroy.'

This turned out to be due to a PKCS#8 key, using "openssl rsa -in old.key -text" (and then cutting and pasting the "PRIVATE RSA KEY" part to create a PKCS#1 key) fixed the issue.

Hopefully this will save someone else a few hours of head scratching/banging/punching the wall.