On Wed, Aug 28, 2019 at 5:08 PM Markus Larsson via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org> wrote:
>
>
>
> On 28 August 2019 16:47:35 CEST, lejeczek via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org> wrote:
>> On 28/08/2019 15:15, Markus Larsson via FreeIPA-users wrote:
>>> I might be wrong here but it sure looks like the cert is being
>>> rejected because the name on service doesn't match the cert.
>>> I'm not at a place where I could check but it looks like that to me.
>>>
>>> BR
>>> Markus
>>>
>>>
>>> On 28 August 2019 16:11:17 CEST, lejeczek via FreeIPA-users
>>> <freeipa-users(a)lists.fedorahosted.org> wrote:
>>>
>>> hi guys
>>>
>>> Would a subdomain on a separate subnet (from which nodes do not
>> have
>>> access to IPA's IPs) to which IPA is connect via
"secondary"
>> ifaces,
>>> have clients successfully install and connect?
>>>
>>> I've crafted a sub domain/zone with, I think, all the records
>> required
>>> and those point to IPAs "secondary" IPs and when I install
>> clients they
>>> fail:
>>>
>>> ...
>>>
>>> Do you want to download the CA cert from
>>>
http://ipa2.subdomain.private.freeipa/ipa/config/ca.crt?
>>> (this is INSECURE) [no]: yes
>>> Downloading the CA certificate via HTTP, this is INSECURE
>>> Successfully retrieved CA cert
>>> Joining realm failed: libcurl failed to execute the HTTP POST
>>> transaction, explaining: Problem with the SSL CA cert (path?
>> access
>>> rights?)
>>>
>>> Installation failed. Rolling back changes.
>>> ...
>>>
>>> Still the same client:
>>>
>>> $ curl
http://ipa2.subdomain.private.freeipa/ipa/config/ca.crt
>>> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
>>> <html><head>
>>> <title>301 Moved Permanently</title>
>>> </head><body>
>>> <h1>Moved Permanently</h1>
>>> <p>The document has moved <a
>>>
>>
href="http://ipa2.private.freeipa/ipa/config/ca.crt">here</a>.</p>
>>> </body></html>
>>>
>>> That host in returned URL above is where IPA top domain lives,
>> but nodes
>>> on the subnet cannot access there.
>>>
>>> This fails by design and what I'm trying will not work? Or it's
>> doable
>>> and I'm only missing something?
>>>
>>> If that is how IPA currently works(or rather doesn't) then is
>> this
>>> something that may get included/fixed in the future?
>>>
>>> many thanks, L>
>>>
>>>
>> Would it mean that each new subzone needs to have a bunch of
>> services(on
>> top of DNS) created for stuff as basic as nodes/clients want to
>> use/join
>> that subzone?
>>
>> My case may be bit different from a regular - IPA top level domain =>
>> subdomain but only with one simple fact that subdomain is on the subnet
>> which has no connection to IPA top level domain subnet (other than IPA
>> servers are connected to both subnets directly) - but would this one
>> thing be such a big impediment?
>>
>> I thought that what I'm doing is not that unusual and many have done it
>> before and that IPA is prepared for this scenario.
>>
>> p.s. I'm on Centos' 4.6.4 version.
>>
>> thanks, L.
>>
>
> Now that say that I'm probably mistaken. The certs should work given that the ipa
server has the same name just a different IP when coming from this network.
That's split horizon DNS.
> If it has a different DNS name then cert work is needed.
The OP said "sub domain/zone" so the IPA servers would be named differently.
In addition I believe that API requests will be rejected due to
mismatching Referer headers. I believe Alexander has a WIP patch on that
somewhere.
rob