Subject: How do I get libldap to pick up changes in TLS_CACERTDIR? Date: Wed, 1 Jul 2009 10:51:52 -0400

Hi,

I'm writing an application that connects to a slapd and the

application uses ldap_start_tls_s to secure communication between itself and slapd before doing anything else. The version of openLDAP I'm using is 2.2.29... I know I should get a newer version, but I have no say on this matter, this is the version I have to use. The /etc/openldap/ldap.conf config file contains only one modification:

TLS_CACERTDIR /usr/sw/certs

I'm not sure how I can get libldap to re-process/re-check the contents

of TLS_CACERTDIR without ending the application and restarting it. I initially thought that tearing down the session and re-creating one from scratch would do the trick, but that isn't working.

Thanks, Lawrence

I answered my own question and I'll add my solution to the mailing list archive for future reference.

Going through the openldap code revealed to me that libldap keeps a default tls context. If you don't specify your own tls context for the LDAP session, then this is the one you're getting. This gets initialized once. So if you decide to change the contents of TLS_CACERTDIR while your LDAP client app is still running, the changes won't get detected (at least not immediately).

This was troublesome, since new certificates wouldn't get picked up and deleted certificates didn't cause start_tls to fail.

I got around this by managing my own tls context and setting this context to my session via ldap_set_option(ld, LDAP_OPT_X_TLS_CTX, my_ctx). Whenever the contents of the directory changed, I would disconnect the session and re-create the context and set it to the session. Managing your own context also implies that setting TLS_CACERTDIR is unnecessary.

Caveat: In 2.2.29, the case statement in ldap_pvt_tls_set_option looks something like: case LDAP_OPT_X_TLS_CTX: if ( ld == NULL ) { tls_def_ctx = (SSL_CTX *) arg; } else { ld->ld_defconn->lconn_tls_ctx = arg; } return 0;

It seems that ld_defconn can be NULL in some cases. So I tried to get around this by doing an anonymous bind before setting LDAP_OPT_X_TLS_CTX. Probably not the best strategy, but this strategy is the best I have right now and it seems to work.

Cheers, Lawrence