On 04/17/2012 08:32 PM, Howard Chu wrote:
> Rich Megginson wrote:
>> On 04/17/2012 06:15 PM, Howard Chu wrote:
>>> Dmitri Pal wrote:
>>>> On 04/17/2012 05:21 PM, Howard Chu wrote:
>>>>>>> If the cause of failure isn't as obvious with NSS, then
>>>>>>> to say, it seems to me that you're looking in the wrong
place for a
>>>> I value everybody's time too and understand that creating a good
>>>> abstraction is a cost especially if single solution worked in the
>>>> So following the rules of the meritocracy it is completely
>>>> reasonable to
>>>> expect that whoever has the need does the work. And this is the case
>>>> here. But we want to do the work in the least intrusive way and to
>>>> address as many concerns as possible. So the question was and is
>>>> you please let us know how we should implement it to make things work
>>>> for everybody?".
>>> OK. But at the moment I still don't understand why providing the debug
>>> output (as we already do) isn't sufficient to allow administrators to
>>> identify their misconfiguration issues.
>> We need some way for developers writing applications that use the
>> OpenLDAP API to get more detailed information from TLS/SSL connection
>> and other failures.
> Jan's original proposal is for LDAP_TLS_INITIALIZATION_ERROR to allow
> it to be distinguished from a session negotiation error. The bugzilla
> bug quoted previously complains that TLS settings aren't checked at
> startup time. Sounds to me like your actual problem is that you should
> be forcing the context initialization to occur earlier, to catch these
> cases. Unfortunately, ever since ITS#5696, you'll still be unable to
> catch all possible NSS internal errors this way.
> For your https://bugzilla.redhat.com/show_bug.cgi?id=640393
I suggest you
> add a call to ldap_set_option(ld, LDAP_OPT_X_TLS_NEWCTX,&flag) in
> your app startup sequence to force libldap to perform context
> initialization, and do your pathname/dbname/certname validation at
> that time. That will give you an opportunity to detect
> misconfiguration/initialization errors. Or at least, as much as is
> possible since your real initialization is still deferred.
> This may seem less precise compared to the original proposal, but it
> has the virtue of failing early, rather than waiting until the first
> session attempt to report a config error.
Is this how you would recommend doing this when using the OpenSSL crypto
implementation with OpenLDAP? Because, AFAIK, using OL with ossl
"suffers" the same problem of deferred initialization when the first
TLS/SSL context is required.
Yes, it would also work for OpenSSL (and GnuTLS). You probably want to set the
global context, so use something like:
int is_listener = 0;
ldap_set_option(NULL, LDAP_OPT_X_TLS_NEWCTX, &is_listener);
You will probably want to add some more checks in tlsm_ctx_init() to validate
that cacertdir and cacertfile are usable.
-- Howard Chu
CTO, Symas Corp.