Re: SSL server certificate that has an intermediary certificate in the chain

[Erwann ABALEA <eabalea@gmail.com>]

2011/7/30 Howard Chu <hyc@symas.com>:
> Frank Swasey wrote:
>> On 7/29/11 3:09 PM, Philip Guenther wrote:
>>> On Fri, 29 Jul 2011, Francis Swasey wrote:
>>>> I have tried placing both the server certificate and the intermediate
>>>> certificate in the same file. ÂOpenLDAP won't start if I put the
>>>> intermediate certificate first, and openssl fails to verify the
>>>> certificate chain if I put the server certificate first in the file.
>>>>
>>>> Have I missed something obvious or has OpenLDAP really forced me into
>>>> the position of needing to add the intermediate certificate from my SSL
>>>> CA Vendor into my trusted store on all my clients?
>>>
>>> It's a CA cert; have you tried adding it to the file specified by the
>>> TLSCACertificateFile option?
>>
>> Well, I never looked at it that way. ÂYes, adding the intermediate
>> certificate to the file pointed to by the TLSCACertificateFile option on
>> the OpenLDAP server appears to have worked.
>
> Amaazing what trouble you could save yourself if you actually read the
> documentation.

He told he looked at the documentation. Documentation is not a novel,
things must be organized to be easily found.

> http://www.openldap.org/doc/admin24/tls.html#Server%20Configuration
> Section 16.2.1.1

I too think a configuration directive is missing here. The logic that
says "this is a CA, you must place it in this CA file/path" is wrong.
This directive (TLSCACertificateFile/Path) is used to verify the
client certificate, and it shouldn't be used to place the certificates
needed by the client to verify the server certificate.

Imagine this situation:
 - Root CA A, sub-CA A1 used to sign server certificates
 - Root CA B, sub-CA B1 used to sign client certificates
 - Server, Client, each one has a certificate signed by the correct CA
(A1 and B1, respectively)
 - Client knows A (the trust anchor, maybe have been bundled with the
software), B and B1 (it has received the whole certificate chain when
it received its personal certificate
 - Server knows A and A1 (it received the whole certificate chain),
and B (manually set by the admin), and maybe B1 (the admin could have
set it, or he's waiting for the client to send it, both situations are
valid and can be justified)

Actual OpenLDAP configuration would be to place B (and maybe B1)
certificate in TLSCACertificateFile/Path element, to be able to verify
the Client certificate. The Server must also place A1 in this element,
so it can be sent to the Client to help it verify the Server
certificate.
So, during the TLS negotiation, B, A1, maybe B1, maybe A are sent to
the Client for it to verify the Server certificate? (remember, this
certificate is signed by A1, and A must already be known by the
Client). That's a waste of bandwidth. What if B is a global CA, Bx are
national ones (or similar decomposition, so we have a lot of Bx)?
And, because A1 is in TLSCertificateFile/Path element, then Server
will implicitly trust any certificate signed by the A+A1 chain? That's
not what the admin has thought.

-- 
Erwann.