On Mon, 2014-01-20 at 17:49 +0100, Jan Cholasta wrote:
> On 20.1.2014 16:36, Simo Sorce wrote:
> > 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.
> 
> Done.
> 
> > 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.
> 
> Principals come from the --principal option, which can have multiple 
> values with the patch.
> 
> The service name constraint is there so that there is a 1-to-1 mapping 
> between principals and hostnames in the request (both subject and SAN). 
> Without this you would be able to request a certificate for completely 
> unrelated services and I was not sure if it's OK to allow that, since 
> the use case here is load balancing (right?)
> 
> >
> > Simo.
> >
> >
> 
> Updated patch attached.
> 

Sorry have to NACK.

I was confused by the code so asked on IRC:
<simo> so if I have subectname = one.ipa.lan and altname = two.ipa.net
then the certificate is anchored to both HTTP/one.ipa.net  AND
HTTP/two.ipa.net ?
<jcholast> yep
<simo> and what happens when I create other.ipa.net with altname
two.ipa.net ?
<simo> does HTTP/two.ipa.net now have 2 certificates anchored ?
<jcholast> the old certificate gets revoked and removed from
HTTP/one.ipa.net and HTTP/two.ipa.net, then the new certificate is
issued and anchored to HTTP/two.ipa.net and HTTP/other.ipa.net

This defeats the purpose of having altnames.

There are 2 reasons to have altnames:
1. just add aliases that are not shared by any other service
2. have a common alias between multiple service to allow loadbalancing

(1) will not be affected, but (2) would be impossible, because as soon
as I try to create the cert for one of the other nodes to be balanced
the previous nodes get their certificates revoked, which defeats the
whole point of creating them with a common altname.

Simo.

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

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to