On ti, 30 heinä 2019, Dmitry Perets via FreeIPA-users wrote:
Hi Alexander,
Yes, indeed, I got the feeling that it is not supported =)
Problem is that it cought me by surprise in the middle of a huge
project, as I wouldn't expect that - out of all things - this would not
have a solution. First hit was when I learned that "DNS views" were not
supported, but I still had hope that I could find some trick with
separate DNS names...
Having this done automatically during installation time is too much
luxary for me, I will be happy also with manual tweaks at this point =)
To your items:
> In order to support it, we would need:
> - decide what is the 'primary' hostname and maintain other names as
> aliases for all Kerberos principals associated with the host:
>
>
host/name1.example.com would need to have aliases
>
host/name2.example.com, host/name3.example.com...
>
>
ldap/name1.example.com would need to have aliases
>
ldap/name2.example.com, ldap/name3.example.com...
>
> HTTP/name1.example.com would need to have aliases
> HTTP/name2.example.com, HTTP/name3.example.com...
>
Yes, this is what I did (manually).
> - allow adding
name2.example.com, name3.example.com... as dNS SAN
> entries into certificates issued for services on
name1.example.com.
>
Yes, this actually works today. I managed to reissue the certificate
for HTTP endpoint on IPA server, simply with "ipa-getcert resubmit",
adding two times "-D" flag. I got a certificate with two DNS:SAN
entries, and this solved my issue with libcurl validating certificates.
Of course, to do that, I had to add the new DNS name as principal alias
to the existing IPA object (was enough to add it to service object -
http/name1.example.com).
So there was no need to create separate hosts and/or services.
Good to hear. I was not sure it was allowed as we have quite a number of
rules around certificate issuance.
> - keep the list of alternative hostnames to validate access to
IPA API.
>
>
> The third part is a minor thing in terms of fixing it:
>
https://github.com/abbra/freeipa/pull/9/files. But I don't want to
> submit it without fixing all the other pieces.
Well, looks like the rest can be done at least manually today.
Problem is that even if you push the fix today, it will take a long
time until we will see it in RHEL.
In RHEL 6 and 7 -- unlikely, given that both are already beyond a phase
where RFEs like this could be added.
Do you see any manual way to make it work today, as a workaround?
(only
the third point I mean, because the first two are solvable).
You need to change the
code any way.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland