Eric Covener wrote:

Upon return from apr_ldap_ssl_init(), SSL has not been initialised on
the underlying toolkit.  If the entire function, and not just the
setting of certificates is deprecated, we should make that more clear.

Additionally, it looks like if you "fail" to initialize SSL (native
return code indicating "already initialized" but maybe with different
SSL parameters)  in the per-connection context you're going to trigger
a failure in apr_ldap_init() which the program will see unnecessarily
and would have a difficult time coping with..

When I looked at this earlier, I also noticed this wasn't clear.

The original LDAP implementation had no "init" concept, you set "global" parameters using ldap_set_option(NULL, ...), and when you were ready, you created an LDAP context with ldap_init().

The Mozilla/Novell toolkits broke this by introducing the ldapssl_client_init() functions and friends, which had to be called at some point during a global initialisation step.

APR LDAP tries to hide all SSL init inside the apr_ldap_set_option(NULL, ...) function, following the pattern laid down by OpenLDAP.

The toolkits set new frontiers for how inconsistently you you could initialise certificates. Microsoft was the simplest - no certs at all, it is all in the registry. Tivoli is simple: One single global parameter, the path to the CMS database. OpenLDAP was straightforward, paths to each cert, key or CA cert. Then Mozilla came along and specified the various key3.db, cert7.db, etc files. Then, some toolkits set certs globally, others set per connection, some both supported at the same time. Aaargh!

I think the "ssl" in apr_ldap_ssl_init() is a misnomer, the function should only be used to fire off truly global and generic initialisation values, ie do nothing for most toolkits.

If you want to specify *anything* SSL related, you need to use apr_ldap_set_option(), which is geared up to support the different cert combos possible.

This is why the certificate path in the apr_ldap_ssl_init() function is deprecated, as it doesn't support all the possible ways in which SSL can be configured.

The LDAP code in httpd, for example, always passes NULL for the cert name to apr_ldap_ssl_init(), and then immediately follows by calling apr_ldap_set_option() to set zero or more certs globally.

This second call makes sure that any future SSL is possible, without this call all SSL bets are off.

Regards,
Graham
--

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to