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 [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
