On ke, 17 tammi 2018, Callum Guy wrote:
>Hi Alex,
>
>I have now managed to create valid certificates after following your
>provided example however I do have some questions.
>
>Firstly in my situation there are multiple proxy instances which are
>servicing this domain, for this reason I attempted to add two hosts to my
>dummy host. This part worked fine and produced the following:
>
>[11:43] root net-ipa1 ~ # ipa service-add-host HTTP/gogs.domain.net --host
>net-proxy1.domain.net --host net-proxy2.domain.net
>  Principal name: HTTP/gogs.domain.net@DOMAIN.NET
>  Principal alias: HTTP/gogs.domain.net@DOMAIN.NET
>  Managed by: gogs.domain.net, net-proxy1.domain.net, net-proxy2.domain.net
>
>AFAIK that looks good although i am not entirely clear on how that
>configuration would effect FreeIPA behaviour.
>
>Following the rest of the example did not work for me however things
>usually don't work if I don't understand what I'm doing! Ignoring that for
>a second, I managed to add my CSR to the service principal via the IPA
>interface and the produced certificate was accepted by both proxy instances
>so I have achieved what i needed to.
>
>I am interested in where  it all went wrong and always interested in
>improving my understanding of IPA itself so wanted to share the output in
>case you were able to provide any information! You can see the domain
>redacted log below:
You did re-issued a certificate for a wrong service on a wrong host.

You wanted to issue certs for HTTP/gogs.domain.net but did so for
HTTP/net-ipa1.domain.net. The latter is not managed by
net-proxy1.domain.net, so there is an error.

If I understood your setup, it is the following:

  - main host visible to users is gogs.domain.net, they would
    authenticate using GSSAPI to HTTP/gogs.domain.net

  - gogs.domain.net is actually represented by net-proxy1.domain.net and
    net-proxy2.domain.net. In case of IPA this means gogs.domain.net
    only exists within IPA database but not as a real (enrolled) host

  - HTTP/gogs.domain.net would need to have aliases
    HTTP/net-proxy1.domain.net and HTTP/net-proxy2.domain.net to allow
    web services on net-proxy1 and net-proxy2 to handle Kerberos
    authentication

  - net-proxy1.domain.net and net-proxy2.domain.net should not have
    actual HTTP/ services defined in IPA

This means you'd need to perform something like the following steps
(below {} is relying on a shell expansion feature, e.g. {foo{1,2}} would
expand into "foo1 foo2" and --bar={foo{1,2}} would expand into
"--bar=foo1 --bar=foo2"). Note that I haven't tested this at all, only
checked that IPA commands use proper arguments/options.

 1. ipa host-add gogs.domain.net
 2. ipa service-add HTTP/gogs.domain.net
 3. ipa service-add-host HTTP/gogs.domain.net --hosts={net-proxy{1,2}.domain.net}
 4. ipa service-add-principal HTTP/gogs.domain.net {HTTP/net-proxy{1,2}.domain.net}
 5. ipa service-allow-create-keytab HTTP/gogs.domain.net --hosts={net-proxy{1,2}.domain.net}
 6. ipa service-allow-retrieve-keytab HTTP/gogs.domain.net --hosts={net-proxy{1,2}.domain.net}

Now, we have a host gogs.domain.net. This host has HTTP/gogs.domain.net
service which is also known to KDC as HTTP/net-proxy1.domain.net and
HTTP/net-proxy2.domain.net. The principal HTTP/gogs.domain.net can be
managed by hosts net-proxy1.domain.net and net-proxy2.domain.net,
meaning these hosts can create and retrieve keytab for the
HTTP/gogs.domain.net principal.

Next step is to issue the certificate and the keytab. There is a
problem though because you should retrieve them at one place only or
otherwise the second issuance would invalidate the first one. Choose
which host will be the primary one and make sure you have a mechanism to
distribute the retrieved certificate and its private key (and a Kerberos
keytab) to the second one.

Let's say it would be a net-proxy1.domain.net. On net-proxy1 if you have
Apache and mod_nss installed, you can use its /etc/httpd/alias database:

 ipa-getcert request -n Server-Cert \
                     -d /etc/httpd/alias \
                     -t 'NSS Certificate DB' \
                     -p /etc/httpd/alias/pwdfile.txt \
                     -N gogs.domain.net \
                     -D gogs.domain.net \
                     -D net-proxy1.domain.net \
                     -D net-proxy2.domain.net \
                     -K HTTP/gogs.domain.net \
                     -K HTTP/net-proxy1.domain.net \
                     -K HTTP/net-proxy2.domain.net \
                     -C /path/to/rotation/script

rotation script is called by certmonger after it has re-issued and saved
the script. IPA servers have their own:
/usr/libexec/ipa/certmonger/restart_httpd but all it basically does is
to determine whether httpd is running and then restarting it to apply a
new certificate because mod_nss only reads it once. You can write this
script using any language (a shell, for example) and it could do what
you want:
 - copy nss database to net-proxy2, for example
 - trigger restart of httpd on net-proxy1 and net-proxy2
 - something else

For the keytab you do the same but as service keys aren't rotated
automatically, you can generate one at net-proxy1 and retrieve it at
net-proxy2:

On net-proxy1 as root:

 kinit -k
 ipa-getkeytab -p HTTP/net-proxy1.domain.net -k /path/to/key.tab

On net-proxy2 as root:

 kinit -k
 ipa-getkeytab -p HTTP/net-proxy2.domain.net -k /path/to/key.tab -r

'-r' option retrieves the keytab without re-generating it, so that it
stays valid.

Now you'd have HTTP/gogs.domain.net principal's key as keytabs at both hosts.

You can use this keytab to authenticate clients talking to
HTTP/net-proxy1.domain.net or HTTP/net-proxy2.domain.net because the key
is the same, only its name differs.

Various applications have different ways to specify that any key from
the keytab could be used. For example, mod_auth_gssapi in Apache has a
default mode where any acceptor name (Kerberos term for the target
principal at server side) is accepted.

--
/ Alexander Bokovoy