This may be related to, or a duplicate of, #6295

This is in FreeIPA 4.4.4-1 running on Ubuntu 17.10

tduehr.admin@ldap:~$ ipa service-add HTTP/sso1.example.com 
------------------------------------------------------------------------
Added service "HTTP/sso1.example.com@EXAMPLE.COM"
------------------------------------------------------------------------
  Principal name: HTTP/sso1.example.com@EXAMPLE.COM
  Principal alias: HTTP/sso1.example.com@EXAMPLE.COM
  Managed by: sso.example.com
tduehr.admin@ldap:~$ ipa service-add-principal HTTP/sso1.example.com HTTP/gatekeeper.example.com
-----------------------------------------------------------------------------------------------------
Added new aliases to the service principal "HTTP/sso1.example.com@EXAMPLE.COM"
-----------------------------------------------------------------------------------------------------
  Principal name: HTTP/sso1.example.com@EXAMPLE.COM
  Principal alias: HTTP/sso1.example.com@EXAMPLE.COM,
                   HTTP/gatekeeper.example.com@EXAMPLE.COM
root@sso1:~# ipa-getcert request -K HTTP/sso1.example.com -D gatekeeper.example.com -D sso1.example.com -d /etc/pki/nssdb/ -n gatekeeper -w -N sso1.example.com
New signing request "20170714012824" added.   
root@sso1:~# ipa-getcert list -i 20170714012824
Number of certificates and requests being tracked: 6.
Request ID '20170714012824':
        status: CA_UNREACHABLE
        ca-error: Server at https://ldap.example.com/ipa/xml failed request, will retry: 4001 (RPC failed at server.  The service principal for subject alt name gatekeeper.example.com in certificate request does not exist).
        stuck: no
        key pair storage: type=NSSDB,location='/etc/pki/nssdb',nickname='gatekeeper',token='NSS Certificate DB'
        certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='gatekeeper'
        CA: IPA
        issuer:
        subject:
        expires: unknown
        pre-save command:
        post-save command:
        track: yes
        auto-renew: yes

Ticket #6295 is fixed in FreeIPA v4.5.

But #6295 will not help in this use case, because you would need
both alice.example.com and bob.example.com to have a Kerberos
principal alias of awesome.example.com, which of course is not valid
(Kerberos principal aliases must be unique).

This use case is an important counter-example to
https://pagure.io/freeipa/issue/6528 (i.e. we must resolve this ticket in
some way before we can do #6528).

So, the current requirement is that the host/service entity must exist, and must be "managed by" the other hosts that want to have its hostname in the SAN on their own certs.

The relationship must be defined somehow. If we change this to NOT require
the "phantom host", how would you expect the defining of this relationship
to the "awesome.example.com" DNS name to look like? i.e. from an administrator POV.

@ftweedal can you please explain why you insist that creating host objects in this case is not appropriate? It is not a 'phantom host', it is a proper host object to associate other resources and their management in FreeIPA. This includes not only ability to validate SAN in the context of certificates but also a possibility to properly handle HBAC rules.

One way or another, you need an object to handle this relationship at LDAP level. I don't really see how inventing something else improves situation.

@abbra I neither agree nor disagree - I am just responding to the ticket.
Hence my request for what the reporter would expect the experience
to look like, if we did not require the creation of a host/service entry to
associate with the other entries.

Any of these:

1. Additional permissions for TLS certificate creation on a DNS entry
2. Many to one aliases (how is 1-1 different that just having another principal?)
3. Certificate issuance to a host group
4. Certificate generation permission checks performed against the IPs, resolved back to the host they point to, as well as the principal.

#4 is probably the least complex and easiest to use. I'd prefer it over the rest as that's also about how I expected it should work in the first place.

To answer @abbra: I can't SSH into awesome.example.com. That kind of multi record entry in DNS is only good for a few protocols. To me, a host is a physical or virtual machine on the network. That box may have multiple names, but a name may be shared by multiple machines.

@tduehr thanks for your input. I'll follow up each point separately:

1. We need a system that works when deploying FreeIPA without the internal DNS system, so whatever we would do needs to be a general feature of DNS. Arguably CNAME provides the mapping required, which more or less means that (4) subsumes this point.

2. These are Kerberos principal aliases. An alias cannot belong to multiple
   principals. There is no other aliasing mechanism available in FreeIPA (except DNS CNAME).

3. This is an interesting idea, but you would still need to create the "phantom host" principal would still need to exist and be made a member of the hostgroup. So it does not reach the goal.

4. DNS-based validation has been discussed before. It may happen in the future but there is significant complexity. CNAME and forward-then-reverse are two approaches that would probably both need to be supported (because we would not want the fact that IPA is being used to dictate DNS regime).

tl;dr for the forseeable future, we can only use data defined in FreeIPA - excluding the DNS component - to authorise certificate requests. For authorising requests with multiple DNS names there must be a relationship between the two names. There are currently two ways to define that relationship:

1. Kerberos principal aliases (does not work if an altname needs to be used with multiple principals)
2. Create a host/service principal and established managedBy relationship with other host principal(s).

I'm open to other ways to define the relationship - preferably without new schema - but I don't think any of your suggestions hit the mark.

Thanks,
Fraser

// closing per triage on Jul 25. Explanation in previous comment.