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@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>