[Freeipa-devel] [freeipa] #3668: CA-less install fails when intermediate CA is used

[Rob Crittenden]

Dmitri Pal wrote:
> On 06/10/2013 05:54 AM, Jan Cholasta wrote:
>> On 7.6.2013 15:36, John Dennis wrote:
>>> On 06/07/2013 09:26 AM, Jan Cholasta wrote:
>>>> On 7.6.2013 15:17, John Dennis wrote:
>>>>> On 06/07/2013 08:57 AM, Jan Cholasta wrote:
>>>>>> Yes, this is correct. The DS certificate must be directly signed
>>>>>> by the
>>>>>> CA trusted by IPA (specified by --root-ca-cert in
>>>>>> ipa-server-install),
>>>>>> there may be no intermediate CAs, because ldapsearch and friends and
>>>>>> python-ldap don't like them.
>>>>>
>>>>> That doesn't sound right. Do we understand why a chain length > 1 is
>>>>> failing?
>>>>>
>>>>
>>>> LDAP utilities and python-ldap only trust certificates directly issued
>>>> by CAs you point them to (at least on Fedora 18).
>>>
>>> This sounds like a bug in MozLDAP (i.e. the NSS LDAP crypto provider).
>>> Have we filed a bug? Let's file the bug here in the Red Hat bugzilla,
>>> not upstream, we're the maintainers of MozLDAP and upstream is already
>>> frustrated with it.
>>>
>>
>> I have just tested with libldap compiled with OpenSSL on my Arch Linux
>> box, it does not work as well:
>>
>> $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H
>> ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W
>> -b '' -s base
>> ldap_start_tls: Connect error (-11)
>>      additional info: error:14090086:SSL
>> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
>> (invalid CA certificate)
>>
>> For the record, this is what happens with NSS on Fedora:
>>
>> $ LDAPTLS_CACERT=$PWD/ca.crt ldapsearch -H
>> ldap://vm-131.idm.lab.bos.redhat.com -ZZ -D 'cn=Directory Manager' -W
>> -b '' -s base
>> ldap_start_tls: Connect error (-11)
>>      additional info: TLS error -8179:Peer's Certificate issuer is not
>> recognized.
>>
>> Honza
>>
> If the options does not work we should hide it for now and clearly state
> in the docs and man pages that the case when certs come from different
> CA is not supported for the time being.
>

IIRC it was added for two reasons:

1. Because the CA is not required to be included in the PKCS#12 file.
2. Because previous attempts to figure out the nickname of the signing 
CA was problematic.

rob