Score:0

Troubleshooting LDAPS/TLS/HAproxy, wrong SSL cert being used

jp flag

Ok so I've got two servers.. one old (Ubuntu 16) and one new (Ubuntu 20).

They both Have Haproxy and within the config they are bound to the same port and same .PEM cert. When I test the SSL cert using OpenSSL's s_client from a Windows host.. I see the expected cert when testing the old server.. but the new server for some reason is sending the backend server's certificate which is an internal cert.

So to help paint the picture, the old server sends ldaps.domain.com's certificate info. But the new server is sending internalDC.domain.com's certificate.

Both Haproxy servers have TCP/636 allowed from the DMZ to LAN, they are both using the exact same Backend servers so I'm totally puzzled.

Any advice would be super appreciated!

Ginnungagap avatar
gu flag
Are you using `-servername` when testing with `s_client`? Do certificates depend on SNI in HAProxy?
jp flag
Yup, the cmd string I used is: `openssl s_client -connect ldaps.domain.com:636` for both tests.. switching the servers IP in the Hosts file. AFAIK Haproxy is watching for the domain since that's all that's mentioned in it's config.
Ginnungagap avatar
gu flag
You're not using `-servername` which is the name indicated by OpenSSL when performing the TLS handshake, as it is, you're connecting to the IP ldaps.domain.com resolves to with no SNI.
jp flag
I am mistaken.. SNI is this yes?: https://stuff-things.net/2016/11/30/haproxy-sni/. If so then no.. I'm not using it. my config is simpler: client LDAPS -> haproxy -> backend DC/LDAPS so ldaps.domain.com for the frontend then the backend is a pair of domain controllers.. both front and backend are set for port 636.
Ginnungagap avatar
gu flag
Show your HAProxy configuration, if it's not SNI it's the TLS termination which is improperly configured.
jp flag
Here's the sanitized conf file: https://paste.centos.org/view/52a6000b So my issue is when connecting to ldaps.domain1.com using this new server I get the SSL cert for domain1-dc01 instead.
jp flag
It's been a long time, and responses to this question stopped for some reason. But in the end you were right @Ginnungagap At the time I had no idea that s_client did not relay or otherwise take the domain in the -connect value and use it towards SNI. Having to specify -servername did work and lead me down a road to resolving the issue(s). So If you will add an answer I will accept it. Thanks
Ginnungagap avatar
gu flag
You're in a better position to actually answer the question since you have the relevant details. Self-answers are not a bad thing and you should feel free to document what you did, what indications you used and how you solved your issue since it's more likely to help someone with the same question than what I could write which would be a much more generic TLS oriented answer of which ServerFault has many already.
jp flag
I guess I've posted a fair amount here and Stackoverflow in general only to be self-answered later. I always assumed that was frowned upon when it could be avoided. Often times I'll post my problem then after beating it for an hour find a solution before anyone's commented. But I guess that how it ends up sometimes. Thanks for coming back @Ginnungagap
Score:0
jp flag

In the end, the fix to this was indeed to use the '-servername' switch in s_client. I had had no idea that it did not handle SNI just by default. @Ginnungagap def steered me in that direction.

It also lead me to discover that my SNI config in haproxy.cfg was not quite right. Originally I had a line such as:

use_backend if { ssl_fc_sni_reg domain.com }

And the idiot I am did not realize the 'reg' stood for regex. Once I change to 'end' because I was trying to match on the domina name itself.. things worked out.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.