Just to follow up on this, I did get HAproxy working with SSL termination in TCP mode.

The only annoyance on this setup now is that HAproxy wants the SSL certificate and key in one PEM encoded file, not separate files. So eventually I'll have to cat the two into one again when it eventually expires ... or write a cron or similar task that checks if they've changed and do so and then restart HAproxy. But it's a couple of years away so we'll just forget about it and then have it bite us later ;)

If only ipa-getcert had a single file combined PEM mode... 

On Thu, Aug 22, 2019 at 4:21 AM Alexander Bokovoy <abokovoy@redhat.com> wrote:
On to, 22 elo 2019, Jonathan Vaughn wrote:
>Well, the specific products we need to talk to FreeIPA support LDAPS
>(implicit SSL via port 636, rather than explicit via STARTTLS on port 389 -
>in fact at least some only support implicit), 389DS does support LDAPS
>(even if it is not a FreeIPA sanctioned mode), so as the saying goes if
>it's stupid and it works, it ain't stupid. :)
>For server sign-on and so forth, SSSD and so on will do what they do
>normally - we aren't mangling any of the pre-defined DNS or other FreeIPA
>magic. This is just to provide a highly available and secure LDAP service
>for everything else that can't use the multiple SRV records or other means
>of assigning / detecting multiple LDAP servers (i.e. Jira, Confluence,
>Bitbucket ... )

Yes, that was clear -- I was more worried on not going that backwards
with LDAPS replacement of what is relying on LDAP STARTTLS + GSSAPI.

>On Thu, Aug 22, 2019 at 1:22 AM Alexander Bokovoy <abokovoy@redhat.com>
>> On ke, 21 elo 2019, Jonathan Vaughn via FreeIPA-users wrote:
>> >Ah, I didn't realize I could do SSL termination in TCP mode. That would
>> >certainly solve our LDAP HA problem with less effort! I'll try that.
>> Note that FreeIPA doesn't really use LDAPS (and there is no such thing
>> as LDAPS in protocol specs, it was never formalized). FreeIPA uses
>> startTLS in LDAP -- at least SSSD will actively rely on it. Also Windows
>> doesn't allow use of LDAPS+GSSAPI.
>> >
>> >On Wed, Aug 21, 2019 at 8:27 PM Daniel Oetken via FreeIPA-users <
>> >freeipa-users@lists.fedorahosted.org> wrote:
>> >
>> >> Why doesn’t terminating SSL on the proxy work with LDAPS? Because it
>> >> should, and says so too here:
>> >> https://www.mail-archive.com/haproxy@formilux.org/msg21657.html
>> >>
>> >>
>> >> Though, I’m looking into the same thing to add SAN to the server
>> >> certificate and wondering about similar questions. When you look at
>> >> “ipa-getcert list” you should see the current certificates already,
>> >> including their settings, so I was thinking to just stop tracking those
>> old
>> >> ones and create new ones like you did, except with the exact same
>> options
>> >> as the old ones (+ SAN). But yeah, I’m not sure if there is anything
>> else
>> >> involved, or if there is a better way. I only started using freeipa
>> >> recently.
>> >> _______________________________________________
>> >> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> >> To unsubscribe send an email to
>> freeipa-users-leave@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.fedorahosted.org
>> >>
>> >_______________________________________________
>> >FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> >To unsubscribe send an email to
>> freeipa-users-leave@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.fedorahosted.org
>> --
>> / Alexander Bokovoy
>> Sr. Principal Software Engineer
>> Security / Identity Management Engineering
>> Red Hat Limited, Finland

/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland