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

[Rob Crittenden]

Martin Kosek wrote:
> On 01/09/2014 03:12 PM, Simo Sorce wrote:
>> On Thu, 2014-01-09 at 09:04 -0500, Simo Sorce wrote:
>>> On Thu, 2014-01-09 at 09:51 +0100, Martin Kosek wrote:
>>>> On 01/09/2014 12:26 AM, Simo Sorce wrote:
>>>>> On Thu, 2013-12-05 at 14:37 +0100, Jan Cholasta wrote:
>>>>>> Hi,
>>>>>>
>>>>>> the attached patch fixes <https://fedorahosted.org/freeipa/ticket/3977>.
>>>>>
>>>>> See the additional comments on 3977, I think this patch should be NACKed
>>>>> with extreme prejudice if it allows setting arbitrary subjectAltNames.
>>>>>
>>>>> Simo.
>>>>>
>>>>
>>>> It does not allow them - SANs are being authorized by using the managedBy
>>>> attribute on the SAN-ed host/service (i.e. host-add-managedby/service-add-host
>>>> commands).
>>>
>>> This means that in order to add a subjectAltName you have to register a
>>> Host with that name ? That is not really convenient, but if it works at
>>> least it properly constrains potential hijacking.
>
> Right. The host does not need to even be enrolled to make this work. But it is
> still better to make it this way that to allow hosts to request SANs.
>
>>>
>>>> But you are right that the authorization part should not be taken lightly and
>>>> should be verified before we allow SANs in default profile. I added a comment
>>>> in the Trac as well.
>>>
>>> Yes we definitely need a test to make 100% sure this cannot be worked
>>> around, the security consequences would be disastrous.
>
> +1
>
>>> 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.

>
> cert requests issued by admin can bypass this check, it is only applied to
> principals starting with "host/", i.e. for example to certs renewed by certmonger.
>
> Other requests are authorized differently. cert-request is a VirtualCommand and
> people are authorized by checking if they have a write access to the
> appropriate virtual operation LDAP entry, living in cn=virtual
> operations,cn=etc,SUFFIX... Which is by default only the admins group members
> which have the god-like special ACI we discussed yesterday. Rob is that
> correct? You also participated in the VirtualCommand coding...

Right. I think I mentioned yesterday that there is currently no special 
permission for issuing SAN certs (at least partly because we don't 
actually do it). Adding a rule for this should be fairly straightforward 
and I think should be part of any effort to enable SAN certs.

Doing the ACI will require a bit of work since currently there is a 1-1 
relationship between a command and an ACI right now (via 
self.check_access()). It shouldn't be too much work to be able to pass 
in another ACI to check though.

>
>>>
>>> We will need this type of functionality if we want to allow admins to
>>> create wildcard certificates anyway, which is another important use case
>>> for hosting/cloud-like services.
>>
>>
>> I was also thinking admins may want to allow a lower privileged admin to
>> manage a host, but not allow them to add a special subjectaltname to
>> random other hosts he manages. In this case again we need the ability
>> for an admin to be able to provide the cert to the host. Also then a
>> special case arises on automatic renew from certmonger, all names need
>> to be checked against the old certificate being renewed, so
>> authorization in that case would have to be based on the previous cert
>> names and not on managedby, right ?
>> If not automatic renewal would fail ?
>
> Hmm, the renewal would fail in this case. admin would have to request new
> certificate manually in this case (when mangedby attribute is not set
> properly). Previous certificate is not checked by the cert-request
> authorization code.

Yup. If the host can't manage all the hosts in the SAN then renewal will 
be rejected.

rob