[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#8364) [PATCH] back-meta idassert-bind tls_reqcert=never bug

Full_Name: Mohammad Nweider
Version: master
OS: Redhat Linux
URL: https://www.securiteam.io/contribs/openldap/mohammad-20160131-0001-fix-backmeta-idassertbind-tlsreqcert-never-bug.patch
Submission from: (NULL) (


We've found a small bug when trying to run openldap with meta backend, what we
were trying to achieve is to have our server listens on ssl/tls port and to
communicate with the meta targets over ssl/tls as well, but due to the fact that
we're using a self-signed certificate and we don't have access to manage the
meta targets, we wanted to skip the client certificate verification when
connecting to the meta targets, so we tried adding idassert-bind
tls_reqcert=never to our meta config for this purpose, but unfortunately it
didn't work as expected.

Whenever openldap has a certificate/key either in
TLSCertificateFile/TLSCertificateKeyFile or in idassert-bind tls_cert/tls_key
settings, it completely ignores tls_reqcert in idassert-bd%d!

to reproduce you can just try to build your server with ssl/tls enabled, add the
tls global/server settings:

TLSCACertificateFile /usr/local/etc/openldap/cacert.pem
TLSCertificateFile /usr/local/etc/openldap/servercrt.pem
TLSCertificateKeyFile /usr/local/etc/openldap/serverkey.pem

add some meta backend targets over ldaps with idassert-bind tls_reqcert=never:

database      meta
suffix        "dc=foo,dc=com"

uri           "ldaps://a.bar.com/dc=foo,dc=com"
suffixmassage "dc=foo,dc=com" "dc=bar,dc=org"
idassert-bind tls_reqcert=never

Enable debugging and try to run some queries against your meta db. You will see
a client certificate is sent to the meta target even with tls_reqcert=never!

The mplelest fix I could come up with is to add the certificate/key to the ssl
context only when is_server or lo->ldo_tls_require_cert is not zero like in the
attached patch.

Please let me know if I'm misunderstanding something or if this use case can be
solved/achieved without this patch.