------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1382
--- Comment #4 from Todd Lyons <tlyons@???> 2013-09-10 00:32:35 ---
(In reply to comment #3)
> Does the fix in bug 1375 solve this for you?
> This appears to also be the same issue as in bug 1273 :
I spoke with him in IRC for a bit and this is a different issue than either of
those options (though I think the 1375 problem will appear once this bug is
fixed, and the 1375 patch will fix it).
The documented action of the ldap_start_tls option:
"If set, Exim will attempt to negotiate TLS with the LDAP server when
connecting on a regular LDAP port. This is the LDAP equivalent of SMTP’s
"STARTTLS". This is distinct from using "ldaps", which is the LDAP form of
SSL-on-connect. In the event of failure to negotiate TLS, the action taken is
controlled by ldap_require_cert."
The problem for this user is that the ldaps:/// URI forces a TLS mode that
requires a CA verifiable cert (LDAP_OPT_X_TLS_HARD). This user has a
self-signed cert, which will always fail that HARD check. The behavior he is
seeking is to assign a value to ldap_require_cert (ACCEPT) and force TLS, but
not require it to verify up the chain to a public CA.
His assertion is that if ldap_start_tls is set and the option ldap_require_cert
is set, the ldap_require_cert value should override the automatic TLS option
HARD assignment. He also asserts that this is the way that the ldap library
seems to operate natively. If we can verify that is the proper operation, then
duplicating the ldap_require_cert logic inside/before the initial TLS options
logic should solve this issue. I provided him with a quickie patch to test at
https://gist.github.com/mrballcb/6501428. It should address the initial
setting, but I have not yet worked through the logic of what happens if that
initial attempt fails TLS negotiation (or fails at all).
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
