slapd + gnutls fails
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
openldap (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
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_
}}}
== server-side ==
{{{
connection_
}}}
== slap.conf ==
{{{
## SSL:
TLSCACertificat
TLSCertificateFile /etc/local/
TLSCertificateK
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) wrote : | #1 |
Lari Huttunen (debian-huttu) wrote : | #2 |
Why is the source package openldap2.3 although slapd version is 2.4.7?
Adam Sommer (asommer) wrote : | #3 |
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/
TLS_REQCERT never
Then restart slapd and see if you can connect.
Thanks again.
Jamie Strandboge (jdstrand) wrote : | #4 |
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:/
Lari Huttunen (debian-huttu) wrote : | #5 |
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/
#include <abstractions/
/etc/
/etc/
/etc/
/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/
/etc/
/etc/
# the databases and logs
/var/lib/ldap/ r,
/var/lib/ldap/* rw,
# lock file
/var/
# pid files and sockets
/var/run/slapd/* w,
/usr/lib/ldap/ r,
/usr/lib/ldap/* mr,
/usr/sbin/slapd mr,
}
Lari Huttunen (debian-huttu) wrote : | #6 |
... 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
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_REQCERT never
Any comments on those? I've also dabbled with the nss_initgroups_
don't have any conclusive results on that.
Adam Sommer (asommer) wrote : Re: [Bug 217159] Re: slapd + gnutls fails | #7 |
>
> $ 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_REQCERT never
>
> Any comments on those? I've also dabbled with the
> nss_initgroups_
> 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) wrote : | #8 |
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) wrote : | #9 |
Hi,
Can you try the version of openldap in my ppa archive?
http://
Thanks
chuck
Mathias Gug (mathiaz) wrote : | #10 |
Could you try using the debug option when running ldapsearch on the client ?
ldapsearch -x -d 1
Changed in openldap2.3: | |
status: | New → Incomplete |
Ronald van Engelen (ronalde) wrote : | #11 |
I'm having the same problems:
* `TLS_REQCERT=never` needed in `/etc/ldap.conf` (`/etc/
* 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@
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
-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) wrote : | #12 |
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) wrote : | #13 |
I am also having problems with Hardy slapd 2.4.9-0ubuntu0.
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:
# 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:
# 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.
- 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:
# 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:/
server:
>>> slap_listener(
connection_get(13): got connid=1
connection_
connection_
connection_closing: readying conn=1 sd=13 for close
connection_close: conn=1 sd=13
Mathias Gug (mathiaz) wrote : | #14 |
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://
elvis (elvisa) wrote : | #15 |
As above:
client: ldapsearch -x -H ldaps:/
server:
>>> slap_listener(
connection_get(13): got connid=1
connection_
connection_
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) wrote : | #16 |
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.
Similarly, I connected to Apache with
gnutls-cli --x509cafile my_ca.cer --x509keyfile myclient.pem --x509certfile myclient.cer -p 443 servername.
And slapd with:
gnutls-cli --x509cafile my_ca.cer --x509keyfile myclient.pem --x509certfile myclient.cer -p 636 servername.
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) wrote : | #17 |
This is run with:
/usr/sbin/slapd -h ldaps:/// -g openldap -u openldap -f /etc/ldap/
Connecting from either "ldapsearch -x -H ldaps://..." or gnutls-cli, slapd returns:
>>> slap_listener(
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_
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_
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) wrote : | #18 |
@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) wrote : | #19 |
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:
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) wrote : | #20 |
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:
gnutls-cli -l shows a huge list too. permissions all seem fine (and readable)
Mathias Gug (mathiaz) wrote : | #21 |
Could you please include the information requested at
https:/
Thank you,
--
Mathias Gug
Ubuntu Developer http://
Adrian Bridgett (adrian-bridgett) wrote : | #22 |
sure:
/etc/ldap/
BASE dc=opsera,dc=com
URI ldap://
TLS_CACERT /etc/ssl/
TLS_REQCERT demand
TLS_CACERT file:
-----BEGIN CERTIFICATE-----
MIIEUTCCAzmgAwI
BAYTAkdCMRIwEAY
BgNVBAoTBk9wc2V
Fg9yb290QG9wc2V
WjB4MQswCQYDVQQ
ZWFkaW5nMQ8wDQY
CSqGSIb3DQEJARY
AQ8AMIIBCgKCAQE
toLXiLQOKcm0k1F
ACP4DdFkVK0rOnc
JoPsTfP8O4ISOHV
QGkUh+86HSCKxk3
HyC4sveyYzm4f+
BBQ7ztgRvxawSnu
hvTiN0BuzzrOMKF
ZTEQMA4GA1UEBxM
cHNlcmEgQ0ExHjA
DEy1MAwGA1UdEwQ
xrvRfNlS5FJphmh
hr4h/2gxjLTjrMS
vcOymiVZ4JWprPC
IxJZHNTpi+
XavJFc33egXQUO7
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_
ldap_create
ldap_url_
ldap_sasl_bind
ldap_send_
ldap_new_connection 1 1 0
ldap_int_
ldap_connect_
ldap_new_socket: 3
ldap_prepare_
ldap_connect_
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) wrote : | #23 |
FYI I've compiled up 2.4.16 (took 2.4.15 from debian and updated source), added a patch from http://
(Subject: gnutls doen't initialize gnutls_
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) wrote : | #24 |
http://
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) wrote : | #25 |
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.
Changed in openldap (Ubuntu): | |
status: | Incomplete → Invalid |
Adrian Bridgett (adrian-bridgett) wrote : | #26 |
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
extendedKeyUsag
keyUsage = digitalSignature, keyEncipherment
Luis Mondesi (lemsx1) wrote : | #27 |
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:/
The documentation should be updated not to say to use TLSCipherSuite HIGH:MEDIUM:+SSLv2 -- especially the wiki.
Adrian Bridgett (adrian-bridgett) wrote : | #28 |
FYI I just hit another issue where ldap wouldn't start with errors like this:
TLS init def ctx failed: -207
slapd stopped.
connections_
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/
cannot choose slapd for some reason for this bug report. :/