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

Petr Viktorin pviktori at redhat.com
Mon Jun 10 13:56:12 UTC 2013


On 06/10/2013 03:35 PM, Rob Crittenden wrote:
> 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.

Well, that's not a necessary requirement. A tester did have a bit of 
trouble creating a PKCS#12 file with both the server cert and the CA 
cert, but the trouble is comparable to having to create a PEM file.

> 2. Because previous attempts to figure out the nickname of the signing
> CA was problematic.

This is the main reason. It could be done, but I believe we should avoid 
any guessing to determine the root of trust.

-- 
Petr³




More information about the Freeipa-devel mailing list