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:
>>>>> 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.
>>> It does not allow them - SANs are being authorized by using the managedBy
>>> attribute on the SAN-ed host/service (i.e.
>> 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
>>> should be verified before we allow SANs in default profile. I added a
>>> 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.
>> Also maybe we should allow admins to bypass the need to have an actual
>> object to represent the alt name ?
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
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...
>> 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
Freeipa-devel mailing list