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, btb@bitrate.net wrote:
On Mar 8, 2014, at 08.50, Joshua Schaeffer jschaeffer0922@gmail.com 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