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

Simo Sorce simo at redhat.com
Mon Jan 20 15:36:10 UTC 2014


On Mon, 2014-01-20 at 11:07 +0100, Jan Cholasta wrote:
> On 17.1.2014 11:39, Jan Cholasta wrote:
> > 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.
> >
> 
> See attachment for patch which implements the above design.

Hi Jan, I am a bit too far removed from the code to fully understand the
change just from the diff.

Could you please add a short explanation in the commit message, a bout
what the code does now differently than it did before.
For example although I understand the checks you do on subjectname
+subjectaltname I do not know where the principals come from or why you
have a comment that says principals must all be of the same service
type.

Simo.


-- 
Simo Sorce * Red Hat, Inc * New York




More information about the Freeipa-devel mailing list