On 10.1.2014 13:34, Martin Kosek wrote:
On 01/09/2014 04:49 PM, Simo Sorce wrote:
On Thu, 2014-01-09 at 10:44 -0500, Rob Crittenden wrote:
Martin Kosek wrote:
On 01/09/2014 03:12 PM, Simo Sorce wrote:
Also maybe we should allow admins to bypass the need to have an actual
object to represent the alt name ?
I'd rather not. This would allow a rogue admin to create a cert for
www.google.com. Sure, they could also create a host for that but forcing
them to add more entries increases the chances of them getting caught
doing it.
They can remove the host right after they create a cert, I honestly do
not think this is a valid concern. If your admin is rouge he can already
take full ownership of your infrastructure in many ways, preventing
setting a name in a cert doesn't really make a difference IMO.
However I would be ok to limit this to some new "Security Admin/CA
Admin" role that is not assigned by default.
Simo.
Ok, let's reach some conclusion here. I would really like to not defer this
feature for too long, it is quite wanted. Would creating new virtual operation
"Request certificate with SAN" make the situation better? It would not be so
difficult to do, the check_access function can already access virtual operation
name as a parameter, we just need to call it.
Why don't we treat SAN hostnames the same way as the subject hostname?
The way I see it, with SAN the only difference is that there is a set of
hostnames instead of just a single hostname, so maybe we should support
requesting a certificate for a set of hosts/services instead of just a
single host/service.
As far as authorization is concerned, currently you can request a
certificate for a single host/service, if you have the "Request
certificate" permission and write access to the host/service entry. With
multiple hosts/services, you would be able to request a certificate if
you have the "Request certificate" permission and write access to *all*
of the host/certificate entries you are requesting the certificate for.
Effectively this means that cert-request would accept multiple
principals instead of single principal and the automatic revocation code
in cert-request, host-del and service-del would take into account that a
single certificate might be assigned to multiple entities.
--
Jan Cholasta
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel