On Fri, 15 Mar 2013, Mik J wrote:
Sorry if my question seem to be simple but I've read the
manpage and I would like to clarify what I understood
ldap.conf is the configuration file read by the ldap client.
means that the client doesn't ask the server for a certificate.
Therefore the server will not sent its certificate. Even for LDAPS (LDAP
The text of the manpage is misleading: in TLS/SSL, the client does not
'request' a server certificate. Whether the server sends its certificate
is not under the client control, but rather is a property of the
cipher-suite that was selected. For example, with AES256-SHA the server
cert is always sent. (And no, TLS_REQCERT has no effect on the
So, setting it to "never" just tells the client to do no checking of the
server certificate, if any, that is received.
(Note also: at least when using OpenSSL, the 'try' setting behaves exactly
the same as 'demand' and 'hard'.)
I have a few questions though
1) The statements TLS_CACERT and TLS_CACERTDIR seem to be a bit
redundant. Why use the TLS_CACERT statement, we can have multiple CA
cert right ?
Sometimes it's easier to administer a single file of multiple certs
instead of a directory of hashed certificate names.
(On the server side, the certs in the olcTLSCACertificateFile file are
also used to generate the optional list of CA subjects included in the
client cert request, though many (most?) client ignore that list.)
2) I read that some people tell to have both "TLS_REQCERT
"TLS_CACERTDIR" or "TLS_CACERT". Why would you specify a CA cert if
client doesn't request and certificate from the LDAP server ?
It's probably pointless. I suppose it's possible to use "TLS_REQCERT
never" but also use client certs, in which case the client might need to
send certs for intermediate CA...but that would be a bizarre use-case.
3) I will use "TLS_CACERT" and "TLS_KEY" on my
client, if I want my
client to be authenticated by the LDAP server
If you want to use TLS/SSL client certificate authentication, yes. That
doesn't directly affect the identity it binds as, of course.
4) All these statements are also valid for LDAP over SSL. Correct ?