pfsense authentication server ldaps / wildcard problem


  • 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?


  • 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
    
    

  • 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.



  • 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.


  • 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.


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


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