[Freeipa-devel] [PATCH] 210 Allow SAN in IPA certificate profile

[Jan Cholasta]

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