Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

    pfsense authentication server ldaps / wildcard problem

    General pfSense Questions
    3
    12
    226
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • T
      tsmalmbe last edited by

      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?

      1 Reply Last reply Reply Quote 0
      • T
        tsmalmbe last edited by

        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
        
        
        T 1 Reply Last reply Reply Quote 0
        • T
          tsmalmbe @tsmalmbe last edited by

          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.

          T 1 Reply Last reply Reply Quote 0
          • T
            tsmalmbe @tsmalmbe last edited by

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

            1 Reply Last reply Reply Quote 0
            • T
              tsmalmbe last edited by

              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.

              T 1 Reply Last reply Reply Quote 0
              • T
                tsmalmbe @tsmalmbe last edited by

                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.

                T 1 Reply Last reply Reply Quote 0
                • T
                  tsmalmbe @tsmalmbe last edited by

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

                  1 Reply Last reply Reply Quote 0
                  • T
                    tsmalmbe last edited by

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

                    viktor_g 1 Reply Last reply Reply Quote 0
                    • viktor_g
                      viktor_g Netgate @tsmalmbe last edited by

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

                      T 1 Reply Last reply Reply Quote 0
                      • T
                        tsmalmbe @viktor_g last edited by

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

                        1 Reply Last reply Reply Quote 0
                        • jimp
                          jimp Rebel Alliance Developer Netgate last edited by

                          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.

                          1 Reply Last reply Reply Quote 1
                          • T
                            tsmalmbe last edited by

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

                            1 Reply Last reply Reply Quote 0
                            • First post
                              Last post

                            Products

                            • Platform Overview
                            • TNSR
                            • pfSense
                            • Appliances

                            Services

                            • Training
                            • Professional Services

                            Support

                            • Subscription Plans
                            • Contact Support
                            • Product Lifecycle
                            • Documentation

                            News

                            • Media Coverage
                            • Press
                            • Events

                            Resources

                            • Blog
                            • FAQ
                            • Find a Partner
                            • Resource Library
                            • Security Information

                            Company

                            • About Us
                            • Careers
                            • Partners
                            • Contact Us
                            • Legal
                            Our Mission

                            We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                            Subscribe to our Newsletter

                            Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                            © 2021 Rubicon Communications, LLC | Privacy Policy