apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: [Patch] LDAP SSL support for Tivoli
Date Sat, 01 Dec 2007 18:07:50 GMT
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
--

Mime
View raw message