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 <ftwee...@redhat.com> 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:


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.

/ Alexander Bokovoy

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to