On Mon, 2013-09-09 at 16:19 +0200, Jan Cholasta wrote:
> 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?

See the point below, the reason people want to use a cert is to avoid
the hassle of installing a private CA on web browser for all users (that
may have personal machine, tablets and whatnot.

I think the solution is to change the way we tell them to do it. Instead
of installing a separate set of public certs, allow SNI setup and have
them create a separate name for public use. It will make for a much
better/easier experience for all involved and will keep the whole
solution more secure wrt Nalin concerns for example.

> >
> > 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.
> >
> 
> 


-- 
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to