hyc@symas.com wrote:
Michael Ströder wrote:
On the downside it's a pain to deal with all the LDAP_OPT_X_TLS_* options having no or different meaning/features for various crypto libs...
Indeed. Even moreso if, as you seem to be suggesting, a client library gets built against a different TLS API than the server side. The current libldap infrastructure wouldn't even support such a build. (Although it could, as the original version of modular TLS support allowed all of the libraries to be supported concurrently. But we dropped that feature because there was no sane usecase for it.)
Personally I'd even prefer to have completely different LDAP_OPT_X_TLS_* values and configuration directives for the different crypto APIs. In this case one could really distinguish the different cases.
E.g. pointing to an OpenSSL CA certificate path is something completely different than a libnss cert7.db/key3.db directory regarding the content even though in both cases the option just is a directory path. IMHO this would avoid a lot of the user/deployer confusion one can see on the mailing lists.
Well, for discussing this openldap-devel list would be the better forum.
The real solution, if there are platform-specific keystores and such that you want to gain access to, is to submit patches for them to the OpenSSL project.
Hmm, openssl engine things are not really easy to deal with. I know that PKCS#11 engine for OpenSSL exists. But such a stack has lots of loose ends.
Ciao, Michael.