[Freeipa-users] Why does a SAN field on a CSR require a host to be in IPA?

[Fil Di Noto]

On Sun, Oct 23, 2016 at 9:53 PM, Fraser Tweedale <ftweedal at 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 problem is slightly exacerbated in that 99% of the time you
> really want to issue service certs, but FreeIPA does not permit the
> creation of a service entry without a corresponding host entry.  So
> you end up with spurious host entries that do not correspond to
> actual hosts.  I have previously asked about relaxing this
> restriction.  The idea was rejected (for reasons I don't remember).

To be fair, I don't think I ever read specifically that a Host in IPA
was supposed to represent a single computer. But I imagine that the
majority of people who are using it thought that was the case, at
least at first. I don't think it would take much abstraction to
maintain that logical representation for administrators.

>> If this actually is a necessity and is not likely to change, I think it
>> would be beneficial to administrators to be able to manage "Hosts" that
>> correspond to CNAMEs (call them "Alias Hosts"? ) separately from Hosts that
>> are actually enrolled computers. They could be managed in a similar fashion
>> to SUDO rules, like maybe:
>>
>>
>>
>> Alias Hosts = a single name
>>
>> Alias Host Groups = groups of names
>>
>> Alias Host Maps = associate Alias Host/Group with a Hosts or Host Groups
>>
>>
>>
>> I'm picturing Alias Hosts and Alias groups as a seperate tab under Identity
>> (and some corresponding "ipa aliashost-*" CLI) and Alias Host Maps tab
>> under policy.
>>
> Now that we have kerberos principal aliases, we might be able to
> leverage that, perhaps even directly for service principals.  Any
> devs want to chime in on this idea?
>
> Cheers,
> Fraser