Re: TLS issues when setting olcTLSCACertificateFile to the CA bundle

[Andrew Findlay <andrew.findlay@skills-1st.co.uk>]

On Sat, Jun 16, 2012 at 02:31:31PM -0400, Patrick Hemmer wrote:

> 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).

There is a good point here, and I think it may require some new config
items to address it.

Slapd needs to know about at least three CAs. In many cases they are
the same actual CA, but the functions of each are distinct:

1)	The CA that signed slapd's own server certificate.
	The CA certificate for this one should be supplied to clients
	as part of the TLS setup.

2)	The CA that signed the server certificate of any replication
	supplier, so that TLS connections to that supplier can be
	verified.

3)	The CA that signed the authentication certificates used by
	clients when they make ldap connections to slapd. This is
	used to verify the client certificates.

At present, (1) and (3) are both configured using TLSCACertificateFile
or TLSCACertificatePath. (2) is configured in the syncrepl clause,
with fallback to ldap.conf or by setting the LDAPTLS_CACERT environment
variable when starting slapd, as in this case slapd is acting as a client.

The issue of CA *chains* is separate, and in all cases above it should
be valid to use a file containing however many certificates there are
in the chain.

I think we need a way to configure each of the 3 cases separately.

Case (1) is adequately covered by the existing config variables.

Case (2) is covered by the tls_cacert options in the syncrepl clause,
which allows for the possibility of each remote supplier having a
certificate signed by a different CA.

Case (3) seems to need new config items. Looking at the TLS section of
slapd.conf(5) I think it would be necessary to duplicate all the TLS*
items as TLSClient* items (except for TLSVerifyClient itself, which
should perhaps be renamed as TLSClientVerify to fit the naming scheme)

Comments?

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------