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
_______________________________________________
Freeipa-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
