On Tue, Oct 25, 2016 at 08:01:59AM +0300, Alexander Bokovoy wrote: > On ti, 25 loka 2016, Fraser Tweedale wrote: > > On Mon, Oct 24, 2016 at 12:30:10AM -0700, Fil Di Noto wrote: > > > On Sun, Oct 23, 2016 at 9:53 PM, Fraser Tweedale <[email protected]> > > > wrote: > > > > On Sun, Oct 23, 2016 at 08:37:15PM -0700, Fil Di Noto wrote: > > > >> Hello, > > > >> > > > >> > > > >> > > > >> I would like to better understand why IPA requires SAN (subject > > > >> alternative > > > >> name) entries to have a backing host record. In order to sign a > > > >> certificate > > > >> with a SAN that corresponded to a user friendly CNAME I had to add a > > > >> host > > > >> record (ipa host) for that DNS name (use force option to create > > > >> without an > > > >> A/AAAA record) as well as a service principle. > > > >> > > > >> > > > >> > > > >> I'm sure I'm not alone when I say I don't like doing that because it > > > >> means > > > >> that a "Host" in FreeIPA is not a computer, it's a host record that > > > >> may or > > > >> may not be the only record that corresponds to a computer. It gets > > > >> confusing. > > > >> > > > >> > > > >> > > > >> I assume things are this way to ensure integrity at some level. But I > > > >> can't > > > >> picture it. What is the potential danger of simply bypassing the > > > >> host/principal checks and just signing the certificate with whatever > > > >> SAN > > > >> field we like? > > > >> > > > > In this specific case, it is because certmonger requests service > > > > certificates with host credentials. Therefore it is not just human > > > > administrators issuing certs. And we MUST validate SAN against > > > > information in the directory (the only "source of truth" available > > > > to the CA / IPA cert-request command). Otherwise you could put e.g. > > > > `google.com' into SAN, and we would issue the cert, and that would > > > > be Very Bad. > > > > > > > > > > In my case it's always human administrators issuing certs. I can see > > > how validation is a great way to prevent a scenario like the one you > > > described. But couldn't that be accommodated by tinkering with the > > > roles/privileges so that you could impose the restriction on external, > > > less-trusted applications but allow a trusted human administrator to > > > bypass it? > > > > > > Admin group by default would be nice. It would be unfortunate if > > > someone added a service account to the admin group, but I don't see > > > that as justification for ruling it out. How many other poor security > > > decisions has someone made already before they decided to add a > > > service account to the domain admin group? To that I would say that > > > degree of administrative negligence is not something that the project > > > should design around. But, I don't work at RedHat and I don't have to > > > take the support calls so my opinion means nothing. > > > > > > But if I'm an admin, enforcing the SAN restriction doesn't prevent me > > > from doing anything I couldn't already do by creating a couple host > > > records. It's just making things difficult for admins who ultimately > > > are securely deploying a service. > > > > > The question is not really one of privilege, but sanity. FreeIPA > > has to make sure that certs issued by it correspond to the CA's view > > of reality, i.e. what is in the FreeIPA directory, at the time the > > request is made. IMO to disable these checks for human users with a > > particular permission is a mistake waiting to happen. > > > > Yes, enforcing the restriction forces a human to put to created the > > needed objects before the cert request will be considered valid. > > Not a bad thing, IMO. > > > > All this said, I think there is a valid RFE in allowing Kerberos > > principal aliases to be consulted when validating a CSR. This would > > mean you do not have to create new objects, just add more principal > > names to the existing one. I filed a ticket: > > > > https://fedorahosted.org/freeipa/ticket/6432 > > > > Alexander, Simo, what do you think? > Certainly principal aliases should be checked if they were asked to be > in SAN. The question is what type of the SAN extension should be > considered for them in addition to Kerberos principal. The aliases are > stored in their full format (alias@REALM), so either you need to do full > match or consider dropping the realm for some types. This needs to be > clarified before any implementation happens. > Right, UPN and KR5PrincipalName can be checked as-is.
We should check dnsNames by affixing around the dnsName the same service type (e.g. `HTTP') and realm as the nominated principal, and looking for that in the aliases. e.g. for nominated principal `HTTP/[email protected]', if there is a SAN dnsName `www.example.com', we look for `HTTP/[email protected]' in its aliases. Does this sound reasonable? No other GeneralName types shall be checked against principal aliases, unless/until we support SRVName. Cheers, Fraser -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
