Okay, I think I finally got somewhere.
Created the host for the load balancers:
# ipa host-add
ipa.example.com
Added a LDAP service for it:
# ipa service-add
LDAP/ipa.example.com
Added both IPA servers to the "managed by" attribute:
# ipa service-add-host
LDAP/ipa.example.com --host
ipa-11.example.com
# ipa service-add-host
LDAP/ipa.example.com --host
ipa-12.example.com
Then to get the certificate on each server...
on ipa-11 specifically:
# mkdir nssdb-test
# ipa-getcert request -d ./nssdb-test -n Server-Cert -K ldap/
ipa-11.example.com -N
CN=ipa-11.example.com,O=EXAMPLE.COM -D
ipa-11.example.com -D
ipa.example.com -g 2048
on ipa-12 specifically:
# mkdir nssdb-test
# ipa-getcert request -d ./nssdb-test -n Server-Cert -K ldap/
ipa-12.example.com -N
CN=ipa-12.example.com,O=EXAMPLE.COM -D
ipa-12.example.com -D
ipa.example.com -g 2048
I should then be able to replace the certificate that FreeIPA installed in
each 389DS instance with the corresponding new certificate that adds the LB
hostname as SAN, restart them, and it should just work I imagine? Is there
any extra magic involved wtih replacing the existing certificates (special
trust issues or whatever) due to being part of a FreeIPA installation or
would it be the same as updating any old 389DS installation, just replace
the existing certs? Also, will I need to be concerned that at some point
FreeIPA is going to helpfully auto-renew the certificates and put the
non-SAN ones back in (and if so, how do I get it to helpfully renew the SAN
certs and auto install them instead) ?
You don't really need to work through a
temporary NSS database with
this.
It is really not different from
Since certmonger is used to track all those certificates, you can simply
modify the tracking request parameters to include what you need on top
of existing ones.
A bonus point is that renewal with new parameters will happen
automatically.
On Tue, Aug 20, 2019 at 6:38 PM Jonathan Vaughn <jonathan(a)creatuity.com>
wrote:
> I've seen some guides for doing reverse proxy of SSL using Apache/Nginx
> which seem to side step the SSL issue by terminating SSL in the proxy but
> that only works for actual HTTPS connections to the FreeIPA UI, not for
> LDAPS.
>
> I have got keepalived + HAProxy configured such that accessing
>
ipa.example.com will go through HAProxy and on to FreeIPA for LDAP(S).
> LDAP works perfectly fine, LDAPS works if the client can ignore the SSL
> certificate name mismatch (since of course, the SSL certificate will be
>
ipa-11.example.com or
ipa-12.example.com or whatever the FreeIPA server
> actually is).
>
> We need this because Atlassian doesn't want to support multiple LDAP host
> names in configuration without paying for Crowd (which is a pretty
> redundant product when we have FreeIPA already). Additionally, I can't
> disable the hostname check for SSL either, which would at least work around
> the issue, so we need to get
ipa.example.com into each FreeIPA LDAP
> server's SSL certificate.
>
> How can I add
ipa.example.com as SAN to the SSL certificate used by 389DS
> in FreeIPA?
>
> At first I thought maybe I should start with adding HTTP/ipa.example.com
> as a principal alias to each HTTP/ipa-(server).example.com and then
> reissue the SSL but apparently I can only add the alias to a single
> principal (can't have it on multiple servers)...
>
> The basic layout is this:
>
> 10.0.0.10 :
ipa.example.com (virtual IP / VRRP)
> 10.0.0.11 :
ipa-11.example.com
> 10.0.0.12 :
ipa-12.example.com
>
> HAproxy runs on both ipa-11 and ipa-12 and each instance of HAproxy is
> configured to sticky sessions.
>
> Keepalived runs on both ipa-11 and ipa-12, both configured as master but
> with ipa-11 set as a higher priority so that nominally all requests go to
> ipa-11 unless ipa-11 is down, in which case the virtual IP moves to the
> other server.
>
> When connecting to
ipa.example.com, connection may end up at either of
>
ipa-11.example.com or
ipa-12.example.com, and we need them both to have
>
ipa.example.com in addition to their real server name in the SSL
> certificate for LDAPS to work correctly. So the certificate for
>
ipa-11.example.com should include in SAN both
ipa-11.example.com and
>
ipa.example.com, and the certificate for
ipa-12.example.com should
> include in SAN both
ip-12.example.com and
ipa.example.com.
>
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland