[Freeipa-devel] Multiple CA certificates in LDAP, questions

Jan Cholasta jcholast at redhat.com
Tue Sep 10 08:30:55 UTC 2013


On 9.9.2013 17:54, Simo Sorce wrote:
> On Mon, 2013-09-09 at 10:40 -0400, Rob Crittenden wrote:
>> Jan Cholasta wrote:
>>> On 9.9.2013 16:02, John Dennis wrote:
>>>> On 09/09/2013 05:17 AM, Jan Cholasta wrote:
>>>>> Another question:
>>>>>
>>>>> Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive
>>>>> set of trusted CAs, or is using one set for everything good enough?
>>>>> Using distinctive sets would allow granular control over what CA is
>>>>> trusted for what service (e.g. trust CA1 to issue certificates for LDAP
>>>>> and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm
>>>>> not sure how useful that would be in the real world.
>>>>
>>>> That would complicate things quickly. Managing CA certs is already
>>>> challenging enough. Exploding this via combinations does not seem to
>>>> present enough real value for the complexity.
>>>>
>>>> In the real world most deployments boil down to a single CA and that
>>>> trust model been effective. Don't forget you can always revoke any cert
>>>> issued by a CA. Having granular control over individual CA's does not
>>>> seem to present value, just complications. If your CA is compromised
>>>> you've got big things to worry about, having it be 1 in N does not seem
>>>> to change that equation radically. If one CA got compromised you've got
>>>> a lot of work to do to replace the trusted CA list everywhere. If one is
>>>> compromised why aren't the other CA's? Having to update just one CA
>>>> trust rather than potentially N is better.
>>>
>>> I'm not suggesting *controlling* multiple CAs, but being able to manage
>>> what individual external CAs are trusted to do. This is probably only
>>> relevant to CA-less install. When IPA internal CA is installed, there is
>>> just that one CA, which is trusted for everything.
>>>
>>
>> We've fielded questions from people wanting to replace the cert in the
>> web server even while maintaining the IPA CA. Granted this was prior to
>> the CA-less option.
>
>> The impetus seems to be not requiring all users to trust the IPA CA. I
>> think if that became easier then wanting to use another CA would be less
>> of an issue.
>
> And I really think this would be better served with an SNI setup, where
> we have 2 SSL certs for the web server only (a public one and an IPA
> one). While everything else must use the IPA CA, esp for PKINIT.

What if there is no IPA CA (CA-less)? Should we assume that the user has 
their own CA in control and allow only certs signed by that single CA?

Regarding SNI, it apparently is not supported in server-side NSS 
(https://bugzilla.mozilla.org/show_bug.cgi?id=360421) and Python 2.x 
(http://bugs.python.org/issue5639). These seem like blockers to me, 
correct me if I'm wrong.

>
> Simo.
>


-- 
Jan Cholasta




More information about the Freeipa-devel mailing list