On 28/09/2020 08.01, Fraser Tweedale via FreeIPA-users wrote:
> On Thu, Sep 24, 2020 at 02:15:11PM -0000, Willie Lima via FreeIPA-users wrote:
> > Hi guys,
> > I have 12 freeipa servers deployed with integrated DNS and CA
> > (realm and domain int.example.com
> > I would like to make a DNS round-robin, for instance: request
> > ldap.int.example.com
and forward for one of the servers and also
> > an external domain ldap.example.com
> > The problem is with the certificate, the TLS handshake fails
> > because there's no alternative name with ldap.int.example.com
> > ldap.example.com
> > I read the redhat documentation about certificate manipulation,
> > but I got very confused in fact how it works.
> > How can I do that? Are there another recommendation?
> Hello Willie,
> It is not supported. With some effort you could create the
> necessary objects and relationship in FreeIPA to permit issuance of
> such a certificate, then you could modify the certmonger tracking
> request (on every server) to request a certificate with those SANs.
> But the tracking request modifications would eventually be lost
> during ipa-server-upgrade (FreeIPA will see that the tracking
> request doesn't match expectations and replace it).
> A possible alternative approach (I haven't tested it yet) is if you
> discover the LDAP servers via SRV records, i.e.
. This would give "round robin"
> (actually service weighting but you get the idea) to all the LDAP
> servers in the topology. I'd have to check if openldap client
> performs certificate validation properly in this scenario though.
OpenLDAP does not support SRV lookup. The python-ldap feature request
information on the topic. I have recently implemented a new feature that
would allow you to implement SRV lookup more efficiently.
TLS hostname verification is not an issue. A client does not directly
use the SRV address. Instead you perform a SRV lookup which gives you a
list of hostnames with weights and priorities. An LDAP client connects
to the hostnames and uses the hostname to verify the identity of the
This is cool but also problematic wrt security unless DNSSEC is used,
as it is relatively easy to spoof a SRV record reply to point the
client to an attacker controlled server.
RHEL Crypto Team
Red Hat, Inc