I was going through some of our fixes for 2.x and noticed that the new rlm_ldap for 3.0 has the same problem. Apparently Arron wondered about the use of ldap_int_tls_config as well and wrote up this issue: https://github.com/FreeRADIUS/freeradius-server/issues/236 The short story is that ldap_int_tls_config was never meant to be a public LDAP API, that's why it's not in the public header! But more to the point OpenLDAP has addressed the TLS configuration issues a while ago. Note OpenLDAP provides the *client* library most everyone uses, this is not an OpenLDAP server issue, we're talking client code here independent of your LDAP server of choice. The code in question centers around setting the REQUIRE_CERT option. To be able to use the correct API for setting REQUIRE_CERT one has to enable the NEW_TLS_CTX option (this is how OpenLDAP fixed the use of bogus use ldap_int_tls_config, by moving the TLS options into the standard config area). The old deprecated LDAP API took string arguments, the new API uses enumerated constants. To preserve backwards compatibility with rlm_ldap and because we really don't want enumerated constants in the rlm_ldap module config we also need to translate the string option to an enumerated constant. I could not figure out how to attach a patch to the github issue, so a git formatted patch is attached which can be applied with git-am or git-apply. This patch is against master (the rewritten rlm_ldap). Caveat: I have not actually tested the proposed patch against master, I simply ported our 2.x patch which had been tested. Note, the 2.x rlm_ldap has the same issue and the only reason we didn't push a 2.x patch yet is because while testing we discovered a bug in the OpenLDAP TLS driver code in which operations related to TLS were performed in the wrong order, that has since been fixed and was restricted to the case where NSS was the TLS provider. Once we finish testing the 2.x I'll submit that as well. But as far as I'm concerned in the new FreeRADIUS 3.x version there should be no reference whatsoever to a non-public deprecated LDAP API, instead 3.x should only use the currently defined public LDAP API's, trying to be backward compatible to something that was broken is not something that should be carried forward into a new version. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/