Re: TLSCACertificateFile directive and multiple CA certificates

[Dameon Wagner <dameon.wagner@it.ox.ac.uk>]

On Wed, May 17 2017 at 00:42:25 +0900, Alexandre Rosenberg scribbled
 in "TLSCACertificateFile directive and multiple CA certificates":
> Hello,

Hi Alex,

> Using multiple CA certificates with the TLSCACertificateFile
> directive is not working in my setup. The man page (1) clearly
> states that multiple certificates can be appended to the file.
> 
> Only the first CA in the file appear to be used. I confirmed this by
> changing the order of the certificate in the file.

How are testing to confirm this?

> I am using self-signed CA Certificate which is used for validating
> the provider server certificate during replication. I see this
> behaviour in both the latest OpenLDAP release and an older release.
> In both case I am using OpenSSL.
> 
> I just realized one important point abound my setup: Both CA
> certificate have the same DN. Other that that they are completely
> different certificate (different key, expiry date). Both CA
> certificate are valid (not expired).

Depending on how you're testing things, the duplicate DN may well be
the _an_ issue, but possibly not a real issue...

> I will test tomorrow if appending another CA certificate with a
> different CN makes a difference.
> 
> I am wondering if some people are successfully using multiples
> certificates with the TLSCACertificateFile directive. Thanks.

Yes we're successfully using multiple certificates with a
TLSCACertificateFile directive.

It might well be interesting, and useful, for you to explain what
you're trying to accomplish, as it's possible that you're
misunderstanding what the directive is actually there to achieve.

The purpose of a CA Certificate file is to allow you to describe the
path of trust between your TLSCertificateFile (the certificate used to
assert the authentication and identity of your DSA) and the eventually
trusted Root CA certificate that a connecting client will have on
their system.

The reason it's often required is that the path of trust to the Root
CA traverses across several intermediate signing certificates (less
likely to be the case when using a selection of self-signed
certificates) -- each certificate has a "Subject" (the DN you mention
above), and an "Issuer" (which is the Subject of it's "parent" signing
certificate).  A simple(ish) way of showing this is to use the openssl
s_client subcommand to do something like the following:

#---8<-----------------------------------------------------------------
$ echo | openssl s_client -connect $YOUR_LDAP_HOSTNAME:636 -showcerts
#---8<-----------------------------------------------------------------

and review the "Certificate chain" output.  You will have to adjust
the command if you're using TLS negotiation over port 389 rather than
the dedicated ldaps port (636).

Cheers.

Dameon.

-- 
><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><
Dr. Dameon Wagner, Systems Development and Support
IT Services, University of Oxford
><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><