Eric Covener wrote:
ldap_ssl_client_init() should be called once per process, not once per connection.
The LDAP SDK uses the ldap_set_option function for both once-per-process values (LDAP* is NULL) and once-per-connection values, and apr_ldap_set_option follows this pattern as well.
Remember that one of the basic design goals of the APR LDAP code is to offer a consistent interface to 8 distinct APR LDAP clients, regardless of the underlying LDAP implementation, and this has been a mindbending task. Adding init code exclusively to apr_ldap_ssl_init() instead of apr_ldap_set_option() makes the Tivoli support work differently to the support maintained by other toolkits, and introduces inconsistent behaviour, which is exactly what the API is trying to avoid.
While the z/os manual says calling into ldap_ssl_client_init() repeatedly just produces error, I've seen some reports that doing so with different values (for the keyring) does have affect (on non-z/OS, where this SDK is equally useful).
Attempting to call ldap_ssl_client_init() on a per-connection basis will return an error as per the patch, so this is maintained.
It also struck me as a little odd that in apr_ldap_init (establish a connection) calling apr_ldap_set_option(..., APR_LDAP_OPT_TLS) wasn't conditional on SSL in either form being requested.
A user might choose to open a normal connection first, and an SSL connection later, and the toolkit must be given the opportunity to be able to initialise the SSL before the first connection.
It cannot be assumed that other toolkits may be able to be further configured after the first LDAP connection is established.
From a general 1.3 perspective, the Tivoli and z/OS LDAP SDK problem with client certs is resolvable by allowing apr_ldap_init() be passed something indicating client cert selection (these SDKS must specify the client cert "label" at connection time). Just mentioning in this case this meshes with anything else you're looking at.
According to the Tivoli docs, the client code will either choose the default client cert in the CMS store, or will rely on an environment variable.
Supporting a certificate label isn't something easily done within the current API, and the API cannot be changed until APR v2.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
