So you will need to clarify one thing for me and we will probably have to both do a little more testing. The Novell docs state that ldapssl_init(,,0) is the same as ldap_init(). The only difference is that the potential connection has been prepared to become an SSL/TLS connection if desired. Where an ldapssl_init(,,1) forces the connection to be SSL. Is this true for other SDKs. If so, then there shouldn't be a problem calling ldapssl_init(,,0), adding the client certificate and then telling it to become and SSL/TLS connection, correct?
The problem that I have found on the Novell SDK is that if I call ldap_init() rather than ldapssl_init(,,0), the connection is forced to be unsecure. In other words, ldapssl_start_tls() fails for that connection. If I call ldap_init() followed by ldapssl_install_routines() then the connection is forced to be secure and ldap_start_tls() also fails. The only way to establish a TLS connection is by calling ldapssl_init(,,0) followed by ldapssl_start_tls() which means without the #ifdef in the code as it stands, the Novell SDK can't do start_tls. But this should have no effect on the way other SDKs work. I haven't done any testing with mutual authentication, so I don't know what the gotchas are there yet. But for the Novell SDK, I should be able to call ldapssl_init(,,0), set the client certificate and then call ldapssl_start_tls(). I should also be able to call ldapssl_init(,,1) and just make sure that I set the client certificate before calling ldap_bind(). The docs also state that there is no communication or connection established until the ldap_bind() happens. Which should mean that as long as all the certificates are in place before the ldap_bind() call, things should be good. Brad >>> Graham Leggett <[EMAIL PROTECTED]> Tuesday, January 11, 2005 11:08:51 AM >>> Brad Nicholes wrote: > As the code stands now with only the Novell SDK always calling > ldapssl_init(), is this a problem? It is - suddenly you need to use APR differently if you are using Novell, as opposed to when you are using all the other toolkits which is what we're trying to avoid. If you are forced to set the SSL mode to none|ssl|tls inside the apr_ldap_init() step, you effectively prevent all non Novell platforms from being able to set client certs on a connection (affecting specifically OpenLDAP and Netscape/Mozilla, possibly Microsoft). Client cert settings must be defined after ldap_init() and before enabling either SSL or TLS on the connection. According to the Novell docs, ldapssl_init() is equivalent to ldap_init() followed by ldap_install_routines(), which was why I chose that approach. The comment about ldap_install_routines() following ldap_init() directly was vague in the docs: It said "success could not be guaranteed", but it didn't clarify whether it meant "ldap_install_routines() would fail neatly with an error message" or "the library will crash". I am being optimistic and assuming "the library would fail neatly". I suspect the warning is about trying to do ldap_init(), followed by ldap_bind(), followed by ldap_install_routines() (which will fail, as the connection is now finalised at the ldap_bind() step). > One thing that bothered me while I was testing this. Even if the > start_tls fails, authentication still succeeds and content is returned. > Since we are assuming forced TLS, authentication should fail if the TLS > connection fails. It probably shouldn't be allowed to fall back to > unsecure. This is the app's problem though - if starttls fails it will return an error, and it's normal on error to give up, which is the expected behaviour. If the app chooses to ignore the error and go on with the insecure connection, then it was the app's choice - it may have wanted to do so. I think it should be pretty clearly documented that this is the case though. Regards, Graham --
