Eric Covener wrote:
Some research shows only alpha releases of openldap even pretend to
allow the CERTFILE/KEYFILE on a per-connection (i.e. LDAP*) basis --
the latest "stable" and "released" levels (2.3.28, 2.3.27)
ldap_pvt_tls_set_option will explicitly bail out of the
CERTFILE/KEYFILE options if the LDAP* parameter is set (unset=global).
This manifests as a bad rc from ldap_set_option().
util_ldap doesn't hit this condition because it never calls anything
on a per-connection basis, despite documentation.
1) util_ldap ignores LDAPTrustedClientCert if it's in a vhost (loses
track of it)
2) util_ldap treats LDAPTrustedClientCert as LDAPTrustedGlobalCert if
it's in the base server (consequence of how it's stashed away and
retrieved)
3) util_ldap doesn't accept LDAPTrustedClientCert in a directory container
Using a small test program and the alpha openldap (2.4.3), setting a
global CA and per-connection client cert/key got a little farther, but
openldap ended up sending out a client-certificate handshake messages
with 0-length client cert (as compared to doing the same
initialization globally and seeing the proper client cert go out over
the wire).
Almost seems like openldap per-connection settings for SSL are a dead
end at this time, unless I'm getting extremely unlucky.
Sorry for now getting back to you on this, I have been embroiled in
cache-land.
One thing I discovered when trying to unravel the different LDAP
toolkits is that support for the different toolkits for SSL client certs
is very patchy.
Ideally if we can figure out whether mod*ldap is at fault for not
passing in the required certs at the right time, we can try and figure
out whether a bug exists in mod*ldap, or in openldap, or both.
Regards,
Graham
--
