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

Jan Cholasta jcholast at redhat.com
Mon Sep 9 14:19:42 UTC 2013


On 9.9.2013 15:36, Simo Sorce wrote:
> On Mon, 2013-09-09 at 11:17 +0200, 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.
>
> Seem very complicated.

Well, code-wise it isn't very complicated, actually it's what I have 
now. I'm just pondering whether to put it in the final design or not.

>
> At most I would see as sort of useful to be able to set a different CA
> just for HTTP (due to default browsers list of CA), but not for anything
> else. But for this case I would rather write instructions on how to
> create a frontend on a *different* server, that just proxies in all
> requests to FreeIPA, just for people that want to use browsers w/o
> distributing the FreeIPA CA cert. That will solve their problem w/o
> complicating ours.

It seems we are talking about slightly different perspectives on the 
issue. Consider the following situation: User wants to install new HTTP 
certificate using ipa-server-certinstall. Currently, the certificate 
must be signed by the CA that was used for IPA install (be it IPA CA or 
CA-less). In <https://fedorahosted.org/freeipa/ticket/3641> it was 
requested that the CA cert of the HTTP cert should be uploaded to LDAP 
(and as a result, distributed to clients). Should this be allowed? If it 
should, should the newly uploaded CA cert be trusted to issue only HTTP 
certs, or any (HTTP/LDAP/PKINIT) certs?

>
> We could also explain how to configure SNI (easier than proxy, but
> depends on whether mod_nss supports it, mod_ssl does), so that people
> can use a public cert with a 'public' name and keep FreeIPA own certs
> for internal management and joins etc...
>
> Simo.
>


-- 
Jan Cholasta




More information about the Freeipa-devel mailing list