OpenLDAP 2.4.40, SLES x86_64.
This will seem crazy, but it looks to me that back-meta uses /etc/openldap/ldap.conf for its TLS configuration instead of the tls_options set explicitly within slapd.conf.
Within my meta configuration I have the following for idassert-bind:
idassert-bind bindmethod=simple binddn="cn=user,dc=example,dc=com credentials="password" flags=prescriptive tls_cacert=/etc/ssl/certs/ca.pem tls_cacertdir=/etc/ssl/certs tls_reqcert=demand
None of the TLS options seem to have any effect here at all (I can put nonsensical values to the tls options here and slapd doesn't complain at all).
Instead it's necessary to use /etc/openldap/ldap.conf for back-meta to bind over SSL/TLS:
tls_cacert /etc/ssl/certs/ca.pem tls_cacertdir /etc/ssl/certs
Any changes to ldap.conf get picked up by back-meta on a restart.
This can't be right, surely?
As an aside, I can't see why it's necessary to have to specify both tls_cacert (pointing at the last CA in the chain) as well as tls_cacertdir, but it is.
On 19/03/2015 11:45, Liam Gretton wrote:
OpenLDAP 2.4.40, SLES x86_64.
This will seem crazy, but it looks to me that back-meta uses /etc/openldap/ldap.conf for its TLS configuration instead of the tls_options set explicitly within slapd.conf.
I've just thought to check the ITS and it looks like this is ITS#8022 that Howard fixed back in January.
I'm off to check out from git and test from there.
My problem seems to be completely fixed in RE24, so thank you Howard for fixing ITS#8022.
It looks like Howard also fixed another long-standing problem in back-meta's connection initialisation: I've always had to add a spurious network-timeout config option as it couldn't cope with the connection to the backend service succeeding almost immediately.
Once again brilliant work, thanks for all your efforts.
openldap-technical@openldap.org