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.
> > 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.
> Also maybe we should allow admins to bypass the need to have an actual
> object to represent the alt name ?
> 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 ?
Simo Sorce * Red Hat, Inc * New York
Freeipa-devel mailing list