Sent: Sat Jun 16 2012 19:42:59 GMT-0400 (EDT)
From: Howard Chu <hyc@symas.com>
To: Quanah Gibson-Mount <quanah@zimbra.com>
bernd@net.t-labs.tu-berlin.de, Patrick Hemmer
<openldap@stormcloud9.net>, openldap-technical@openldap.org
Subject: Re: TLS issues when setting olcTLSCACertificateFile to the
CA bundle
Quanah
Gibson-Mount wrote:
--On Saturday, June 16, 2012 2:31 PM -0400
Patrick Hemmer
<openldap@stormcloud9.net> wrote:
Sent: Sat Jun 16 2012 03:31:40 GMT-0400
(EDT)
From: Bernd May <bernd@net.t-labs.tu-berlin.de>
To: Patrick Hemmer <openldap@stormcloud9.net>
openldap-technical@openldap.org
Subject: Re: TLS issues when setting olcTLSCACertificateFile
to the CA
bundle
So you problem is, that you have
signed your server cert with a CA from
a CA chain and your clients with another CA and you don't
want clients
to connect, not signed by your client CA?
This sounds more like a case for ACLs and matching rules,
since you
AFAIK you cannot tell ldap to only trust a CA for server
cert
verification purposes. A CA is trusted or not.
The assessment is correct, but I beg to differ on the
statement "A CA is
trusted or not".
Server certs are used by the client to verify the remote
server is who it
says it is.
Client certs are used by the server to verify the client is
allowed to
talk to it.
There is a very big difference between the two. The server
doesnt care
one bit if the CN of a client cert doesnt match the reverse
DNS lookup of
the IP the connection came from. All it cares is that the cert
presented
by the client is signed by a recognized CA. As such if you
dont restrict
the CAs that OpenLDAP will recognize for client certificates,
any
john-doe server with a certificate could connect (at which
point client
certs become useless).
The TLS chapter of the Admin Guide already covers this.
What in particular are you referring to? The only relevant part I
see is this:
: The server must be configured with the CA certificates and also
its own server certificate and private key.
: Typically a single CA will have issued the server certificate and
all of the trusted client certificates, so the server only needs to
trust that one signing CA
However my situation isnt the typical case mentioned, as I have a
different CA signing the server's cert and the client's certs.
I would suggest you use
olcTLSCACertificatePath and point to a directory
containing the CA certs that should be used for validation of
certs.
No. There's no behavioral difference between the ...Path vs
...File. The use of ...Path is annoying because it requires the
maintenance script to generate the hash symlinks, but aside from
that, all certs in either location are used.