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,