pfsense authentication server ldaps / wildcard problem

tsmalmbe

The scenario. pfsense-01 is using pfsense-02/haproxy with ssl-termination as an authentication server ldap frontend. This does NOT work however -> pfsense-02/haproxy reports an SSL handshake issue. Other services (mainly Atlassian-based) are happily using the pfsense-02/haproxy ldap frontend without problems.

I have tried to use all the CA's in the chain as well as the Global CA chain. This is an Entrust wildcard certificate. All intermediates are located in both pfsense-01 and pfsense-02. No combination (Entrust L1K, G2 nor Global CA chain) in pfsense-01 works.

I have tried SSL encrypted and STARTTLS in pfsense-01 as well as different options in pfsense-02/haproxy (tcp, ssl/https) but the result is the same.

Pfsense-01 authentication directly to the underlying ldap-server works. But as I want to utilize an ldap-cluster, I need this to go through the pfsense-02/haproxy.

What should I do next to debug this? Is there an inherent incompatibility in the pfsense authentication prohibiting me from using wildcards? Or is the issue the haproxy part? I think I have iterated all the different possibilities for setup but I have to be missing something here?

tsmalmbe

openssl s_client -connect ldap.mintsecurity.fi:636
CONNECTED(00000003)
depth=3 C = US, O = "Entrust, Inc.", OU = www.entrust.net/CPS is incorporated by reference, OU = "(c) 2006 Entrust, Inc.", CN = Entrust Root Certification Authority
verify return:1
depth=2 C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-terms, OU = "(c) 2009 Entrust, Inc. - for authorized use only", CN = Entrust Root Certification Authority - G2
verify return:1
depth=1 C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-terms, OU = "(c) 2012 Entrust, Inc. - for authorized use only", CN = Entrust Certification Authority - L1K
verify return:1
depth=0 C = FI, L = Espoo, O = Mint Security Oy, CN = *.mintsecurity.fi
verify return:1
---
Certificate chain
 0 s:/C=FI/L=Espoo/O=Mint Security Oy/CN=*.mintsecurity.fi
   i:/C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2012 Entrust, Inc. - for authorized use only/CN=Entrust Certification Authority - L1K
 1 s:/C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2012 Entrust, Inc. - for authorized use only/CN=Entrust Certification Authority - L1K
   i:/C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2009 Entrust, Inc. - for authorized use only/CN=Entrust Root Certification Authority - G2
 2 s:/C=US/O=Entrust, Inc./OU=See www.entrust.net/legal-terms/OU=(c) 2009 Entrust, Inc. - for authorized use only/CN=Entrust Root Certification Authority - G2
   i:/C=US/O=Entrust, Inc./OU=www.entrust.net/CPS is incorporated by reference/OU=(c) 2006 Entrust, Inc./CN=Entrust Root Certification Authority

tsmalmbe

I requested a new cert with a SAN.

DNS Name=*.mintsecurity.fi
DNS Name=mintsecurity.fi
DNS Name=ldap.mintsecurity.fi

This made a change in my desktop client (ldapadmin, freeware) but made no change in this communication between pfsense-01 and pfsense-02/haproxy.

tsmalmbe

I think I have covered everything that is mentioned here https://docs.netgate.com/pfsense/en/latest/troubleshooting/authentication.html#Debugging_LDAP

tsmalmbe

Now I'm trying to wrap my head around this https://github.com/pfsense/pfsense/blob/master/src/etc/inc/auth.inc to understand where the checks are actually made.

tsmalmbe

I think I have verified that the "Entrust Certification Authority - L1K" is not in /usr/local/share/certs/ca-root-nss.crt. Hence Global CA list will never work with the Entrust certs. Choosing any of the intermediates in the chain does not work either, as explained in the previous posts.

tsmalmbe

So really, any discussion or commentary would be appreciated here.

tsmalmbe

Is it appropriate to say I would gladly pay a 100€ "bounty" if this could be fixed?

viktor_g

@tsmalmbe Please create a detailed bugreport:
https://docs.netgate.com/pfsense/en/latest/development/bug-reports.html

tsmalmbe

@viktor_g It is here https://redmine.pfsense.org/issues/11332

jimp

There aren't enough details here yet to say what the problem is for sure. But your best bet is to use a 2.5.0 snapshot.

Import the chain into 2.5.0, and for the root and intermediates, check the box that adds them to the trust store.

The PHP LDAP code is cranky sometimes, but that can help. Also, when debugging, after any change in the LDAP settings, open a console menu and run option 16 then option 11.

If none of that helps, I'm not sure there is anything we can do to fix it -- it could be a problem in PHP LDAP itself.

We've also recently found that some things won't trust wildcard certificates on purpose, so you might try a server cert with only the SAN for the hostname if you can.

tsmalmbe

@jimp Okay, thanks for the input. I don't have the possibility to (easily) setup a test environment with a new version of the software, so I will have to test this once there is a release available.

tsmalmbe

An update to this - there has been no change/improvement to this with 2.5.0 nor 2.5.1.