Dear list members,
I am having some problems with TLS I would like to share and hopefully solve with your help.
First of all, the specs: it's a OpenLDAP 2.4.19 compiled (manually, not via apt-get) on a Ubuntu 8.04 (Hardy). I don't think it matters, but I am using the dynlist overlay (that's why I had to compile manually and not via apt-get, as I couldn't get it to work with the package Ubuntu provides).
Passing on to the problem itself, let me just start by saying that the SSL/TLS setup itself seems to be working fine, and I am always able to ldapsearch on port 636 with ldaps:// (SSL) or on port 389 with ldap:// and -ZZ (TLS).
Unfortunately, using other clients (phpLDAPadmin and some custom php scripts I wrote), the behavior is rather random. Sometimes it fails, sometimes it works (at the beginning it worked more often than not, lately it has been working less and less). The server logs, unfortunately, are not so helpful (for me, at least!). The only error I see (with logs at -1, trying to connect via phpLDAPadmin with TLS on port 389) is:
connection_read(15): TLS accept failure error=-1 id=23, closing Apr 7 16:45:18 gold slapd[7385]: connection_closing: readying conn=23 sd=15 for close Apr 7 16:45:18 gold slapd[7385]: connection_close: conn=23 sd=15 Apr 7 16:45:18 gold slapd[7385]: daemon: removing 15 Apr 7 16:45:18 gold slapd[7385]: daemon: activity on 1 descriptor Apr 7 16:45:18 gold slapd[7385]: daemon: activity on: Apr 7 16:45:18 gold slapd[7385]: conn=23 fd=15 closed (TLS negotiation failure)
Trying on port 636 with ldaps:// yields the same error. But as I mentioned, it just happen sometimes, while on others the connection is successfully established! Although I did notice that even when it does work, I get the following error:
connection_read(14): unable to get TLS client DN, error=49 id=8
but it is quickly followed by a "conn=8 fd=14 TLS established tls_ssf=256 ssf=256"...
So, this is my problem and it is getting me quite puzzled... The fact that it does work on occasion makes me think it can't be my configuration or the usual file permission culprit...
Here's my slapd.conf (I removed the ACL configuration, as I am guessing it's not important here):
# # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/dyngroup.schema include /usr/local/etc/openldap/schema/inetorgperson.schema
#Custom Schemas include /usr/local/etc/openldap/schema/local.schema include /usr/local/etc/openldap/schema/postfix.schema
pidfile /home/slapd/run/slapd.pid argsfile /home/slapd/run/slapd.args
####################################################################### # Database definitions #######################################################################
database hdb suffix "dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" rootpw secret directory /home/slapd/database index objectClass eq
####################################################################### # Replication #######################################################################
overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100
####################################################################### # TLS #######################################################################
TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCACertificateFile /home/slapd/ssl/cacert.pem TLSCertificateFile /home/slapd/ssl/servercrt.pem TLSCertificateKeyFile /home/slapd/ssl/serverkey.pem TLSVerifyClient never
####################################################################### # Overlay (for dynamic lists) #######################################################################
overlay dynlist dynlist-attrset ipfnRole memberURL member
If it helps for anything, in the ldap.conf files of the client I also have the "TLS_REQCERT never" setting, together with the TLS_CACERT and TLS_CACERTDIR for the CA's certificate.
Thanks in advance for any help,
On 8 Apr 2010, at 03:57, Daniel Gomes wrote:
First of all, the specs: it's a OpenLDAP 2.4.19 compiled (manually, not via apt-get) on a Ubuntu 8.04 (Hardy)
Hmm. Ubuntu and Debian OpenLDAP packages use GNUTLS by default, and I've certainly had problems with cert name recognition - especially with subjectAltNames in certificates before. Hit it with the LDAP URI set to the name in the subjectName, and it works. Hit it with the subjectAltName DNS names, and it tends to barf.
I recompile the OpenLDAP debs from package source (better still - use the 2.4.21 package from Lucid), and change debian/configure.options from "--with-ssl=gnutls" to "--with-ssl=openssl"; also change the debian/control file dependencies from "libgnutls-dev (>= {version})" to "libssl-dev". Follow that with a dpkg-buildpackage -rfakeroot, and you should end up with OpenSSL linked packages.
Note: I'm not trying to get into yet another Debian/GNUTLS/OpenSSL licensing debate here, just saying what works for me.
Cheers,
Neil
NEIL DUNBAR Systems Architect
(602) 850-5783 work +44 7976 616583 mobile +1 (602) 535-6914 US mobile www.llnw.com
Hey Neil,
thanks for the tip, I might try re-compiling it with the options you mentioned. The things is, at the moment (and for the last couple of days), all has been working flawlessly, even on phpldapadmin (with which I always had those issues), so I cannot reproduce the error anymore (and therefore I wouldn't be able to tell if the recompilation-trick worked or not...). But again, assuming the problem would be some certificate field, this wouldn't change over time, so it still wouldn't explain why it worked sometimes while others not... I'm starting to believe it was just a random error, but again, I'm still afraid it will spontaneously show up some time in the future and give me a lot of headaches...
Anyway, as I mentioned, now it all seems to be working fine, but I still get this error when clients (successfully) connect:
slapd[13887]: connection_read(14): unable to get TLS client DN, error=49 id=14
It seems to be an issue related to the client certificate, but I am specifically saying on slapd.conf "TLSVerifyClient never", so I am out of ideas as to how to fix this error...
Cheers,
Em 08-04-2010 19:20, Neil Dunbar escreveu:
On 8 Apr 2010, at 03:57, Daniel Gomes wrote:
First of all, the specs: it's a OpenLDAP 2.4.19 compiled (manually, not via apt-get) on a Ubuntu 8.04 (Hardy)
Hmm. Ubuntu and Debian OpenLDAP packages use GNUTLS by default, and I've certainly had problems with cert name recognition - especially with subjectAltNames in certificates before. Hit it with the LDAP URI set to the name in the subjectName, and it works. Hit it with the subjectAltName DNS names, and it tends to barf.
I recompile the OpenLDAP debs from package source (better still - use the 2.4.21 package from Lucid), and change debian/configure.options from "--with-ssl=gnutls" to "--with-ssl=openssl"; also change the debian/control file dependencies from "libgnutls-dev (>= {version})" to "libssl-dev". Follow that with a dpkg-buildpackage -rfakeroot, and you should end up with OpenSSL linked packages.
Note: I'm not trying to get into yet another Debian/GNUTLS/OpenSSL licensing debate here, just saying what works for me.
Cheers,
Neil
NEIL DUNBAR Systems Architect
(602) 850-5783 work +44 7976 616583 mobile +1 (602) 535-6914 US mobile www.llnw.com
openldap-technical@openldap.org