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

    LDAP authentication with STARTTLS fails randomly with CA cert issues

    Scheduled Pinned Locked Moved OpenVPN
    3 Posts 2 Posters 1.1k Views
    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.
    • C
      croadfeldt
      last edited by

      Have been fighting with getting the correct CA identified for my FreeIPA LDAP server so that the Authentication Server will work as expected. The ultimate goal being to authenticate OpenVPN against my FreeIPA LDAP server, SSO.

      I use let's encrypt certs on FreeIPA, and have injected the listed root CA certs from let's encrypt into the CA section of pfSense, I have also pulled the issued cert chain from the LDAP server and ensured that all those certs are injected in the CA section of pfSense. On top of that, I've selected all the CA certs as the approriate CA cert for the FreeIPA LDAP authentication server in the Auth Server section of pfSense.

      Here's the kicker, it will work sometimes, then randomly stop working. I've verified the cert chain using openssl and ldapsearch from the pfSense box itself, using a ssh shell. When it does fail, the error is always the same.

      From pfSense logs:
      php-fpm[961]: /diag_authentication.php: ERROR! could not connect to LDAP server FreeIPA using STARTTLS.

      From LDAP server access logs:
      conn=25916 op=-1 fd=100 closed - Peer does not recognize and trust the CA that issued your certificate.

      I'm well versed in SSL, firewalls, etc... but this one has me running in circles. Any help would be greatly appreciated.

      Thanks!

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

        The LE cert should be trusted by default since it's in the global CA list.

        That said, after making any change to LDAP servers, you should go to the console or ssh menu and use options 16 then 11 to make sure the environment gets reset for the new LDAP settings. I hoped to fix this but apparently PHP's new LDAP settings that aren't environment-based don't work properly either.

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 1
        • C
          croadfeldt
          last edited by

          Thank you sir, that appears to have done the trick.

          You already know what was happening, but I'd like to document it for the next guy. :)

          Keywords: FreeIPA LDAP pfSense Authentication Server OpenVPN

          Scenario: When using a LDAP server, either stand alone or as part of FreeIPA, and that LDAP server is using a "real cert" such as a Let's Encrypt cert, you should use the Global Root CA when defining the Authentication Server in pfSense. Then login to the pfSense system via ssh, issue a restart command for PHP-FM via option 16, followed by a Restart webConfigurator command via option 11 before testing via Diag->Auth or requesting a list of containers via the Select Containers button.

          If you are custom a self signed cert in your LDAP server as part of FreeIPA, then you should insert the Root CA cert for the FreeIPA PKI into the CA section of pfSense, then select that CA cert when defining the Authentication Server in pfSense, followed by the option 16, option 11 commands mentioned previously.

          I followed the instructions at the link below which work, except for the use of a "real" cert, which you should use my modified instructions above for.

          https://fattylewis.com/2018/01/19/using-freeipa-to-authenticate-openvpn-users-on-pfsense/

          1 Reply Last reply Reply Quote 0
          • First post
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.