Antw: Re: TLSCACertificateFile directive and multiple CA certificates

["Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>]

>>> Dameon Wagner <dameon.wagner@it.ox.ac.uk> schrieb am 17.05.2017 um 10:34 in
Nachricht <20170517083438.GJ3001@maia.oucs.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 think the duplicate DN is a problem, because the DN (subject) is used to find a matching certificate. Then if that seems valid (regarding expiration dates), it'll be used. And I think to search is terminated here.
>From a PKI point of view there's no problem with this algorithm, right?

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