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

[Dmitri Pal]

On 06/10/2013 12:13 PM, Petr Viktorin wrote:
> On 06/10/2013 05:34 PM, Dmitri Pal wrote:
>> On 06/10/2013 09:56 AM, Petr Viktorin wrote:
>>> 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.
>>>
>>
>> I am not sure I get it.
>> So we inspect the certificate PKCS#12 file and there can be ambiguity
>> about the root of trust. How? This part is not clear to me.
>> Sorry for being slow here. Can someone explain it in more details?
>
> A PKCS#12 file can contain any number of arbitrary certificates (or
> other objects).
> There is already some ambiguity in determining which cert to use for
> the server. Here we error out if we don't find exactly one cert with
> appropriate usage flags.
> The root CA cert can be the one that signed the server cert (the only
> scenario that works now), or it can be any one along the chain.
> If you have an intermediate CA signed by a well-known authority, you
> would probably not want to trust *everything* signed by that
> authority; you'd want to trust "your" root CA which can be anywhere
> along the chain.
>
> If we exclude scenarios with Intermediate CAs (which don't currently
> work), the situation is much simpler, but we don't want to limit the
> CLI to that.
>
> Note that users can't usually carefully control what's inside the
> PKCS#12 file: the tools will typically allow generating a file with
> either only one cert, or with the entire chain.
>
>> Regardless...
>> If something can't be reliably determined then we should probably do
>> following:
>> If we have any issues with determining the root of trust we should fail
>> and request the caller to run the command again with additional command
>> line option that would explicitly provide the the name of the root CA.
>>
>> Will that help?
>
> That would be any time there's more than one CA in the trust chain.
> Is it worth special-casing this? Are there real-world deployments that
> only use one CA? Note that in this case you can just use a single-cert
> PKCS#12 plus a PEM file for the CA, which is simple enough IMO.
>
So my point is that why we can't say that we support only a single-cert
PKCS#12 file plus a PEM file case and have a clear set of instructions
on how to produce these files?

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/