did you read the description of this setting in man 5 slapd-config?
Well, yes and no. I read about TLS_REQCERT under man ldap.conf and incorrectly
assumed that what was set here (allow, demand, etc) also needed to be set on
cn=config. I've read over both man pages more carefully now and I see the
difference, one is requesting the cert from the server and the other is
requesting the cert from the client. I just removed olcTLSVerifyClient from
cn=config and I was able to authenticate successfully.
Thanks for your help, your advise was very clear,
Joshua
On 03/08/2014 11:27 AM, [email protected] wrote:
On Mar 8, 2014, at 08.50, Joshua Schaeffer <[email protected]> wrote:
I'm in the process of setting up my slapd server to operate over LDAPS and
having trouble when using a CA certificate (being my own certificate
authority). I've been able to setup LDAPS when using a self-signed server
certificate:
please use ldap+starttls, not ldaps.
This works fine and I'm able to authenticate clients. However if I use a CA
certificate (again, being my own CA) to sign my server certificate and then
change olcTLSVerifyClient to demand and add olcTLSCACertificateFile then I can
no longer authenticate. I've installed my CA certificate on the client machine
and pointed both ldap.conf and nslcd.conf to the CA certificate. However I get
the following when debugging:
why are you setting olcTLSVerifyClient when changing from a self signed cert to
a properly signed cert? did you read the description of this setting in man 5
slapd-config? it has nothing to do with use of a self-signed vs a regular
cert. be methodical when doing an exercise like this. first switch from your
self signed cert to your proper cert. test. then, modify olcTLSVerifyClient
and see what happens.
Why would the client not send the certificate if I've pointed TLS_CACERT in
ldap.conf and tls_cacertfile to that cert?
TLS_CACERT and tls_cacertfile point to the ca cert. why would this cert be
sent anywhere by the client? the server already has this cert. those settings
allow the client to establish a chain of trust to the certificate presented by
the server. it’s a “bootstrapping” mechanism, so to speak. you tell the
client [by way of those settings] to implicitly trust, no questions asked,
certain ca certificates. then when the client is presented a certificate by a
server, it can be deemed “trustworthy”, even though it had no prior knowledge
of this particular cert.
-ben
