On Wed, Oct 30, 2013 at 6:44 AM, Todd Lyons <tlyons@???> wrote:
> On Wed, Oct 30, 2013 at 6:00 AM, Heiko Schlichting
> <exim-users@???> wrote:
>>
>> - The problem occurs if LDAP configuration file (e.g. ~/.ldaprc) contains
>> one of these:
>> TLS_REQCERT allow
>> TLS_REQCERT demand
>> TLS_REQCERT hard
>> TLS_REQCERT try
>>
>> - exim does not hang if ~/.ldaprc contains
>> TLS_REQCERT never
>> or there is no configuration at all¹.
>
> What do you normally have in .ldaprc? Is this the exim user? Some other user?
I don't think this is what is causing your problem, but I want to make
sure we both have the same expectation of the ldap TLS spec. In man
ldap.conf:
TLS_REQCERT <level>
Specifies what checks to perform on server certificates in a TLS
session, if any. The <level> can be specified as one of the follow-
ing keywords:
never The client will not request or check any server certificate.
allow The server certificate is requested. If no certificate is
provided, the session proceeds normally. If a bad certifi-
cate is provided, it will be ignored and the session pro-
ceeds normally.
try The server certificate is requested. If no certificate is
provided, the session proceeds normally. If a bad certifi-
cate is provided, the session is immediately terminated.
demand | hard
These keywords are equivalent. The server certificate is
requested. If no certificate is provided, or a bad certifi-
cate is provided, the session is immediately terminated.
This is the default setting.
In these descriptions, a self-signed certificate is what it calls a
"bad" certificate. So if you are using a self-signed cert, only
"allow" or "never" can be used with it, and of course "never" means
don't try TLS at all.
> I am in #exim on Freenode each weekday from about 12:00-21:00 UTC each
> day as user cannonball. Come find me and we can work through this.
Come find me if you can. I have a local test ldap server with a
self-signed cert that I can bounce data off of:
build-Linux-i386/exim -d -C
/work/home/exim/tmp/etc/exim/exim_ldap.conf -be '${lookup ldap{
user=cn=pam,ou=employees,dc=ivenue,dc=net
ldap://ivwm01.ivenue.net/uid=tlyons,ou=users,ou=employees,dc=ivenue,dc=net?cn,uid?}
} ${lookup ldap{ user=cn=pam,ou=employees,dc=ivenue,dc=net
ldap://ivwm01.ivenue.net/cn=pam,ou=employees,dc=ivenue,dc=net?cn,uid?}}'
<snip>
perform_ldap_search: ldap URL =
"ldap://ivwm01.ivenue.net/uid=tlyons,ou=users,ou=employees,dc=ivenue,dc=net?cn,uid?"
server=NULL port=0 sizelimit=0 timelimit=0 tcplimit=0
after ldap_url_parse: host=ivwm01.ivenue.net port=389
ldap_initialize with URL ldap://ivwm01.ivenue.net:389/
initialized for LDAP (v3) server ivwm01.ivenue.net:389
Require certificate overrides LDAP_OPT_X_TLS option (3)
binding with user=cn=pam,ou=employees,dc=ivenue,dc=net
<snip>
perform_ldap_search: ldap URL =
"ldap://ivwm01.ivenue.net/cn=pam,ou=employees,dc=ivenue,dc=net?cn,uid?"
server=NULL port=0 sizelimit=0 timelimit=0 tcplimit=0
after ldap_url_parse: host=ivwm01.ivenue.net port=389
re-using cached connection to LDAP server ivwm01.ivenue.net:389
<snip>
uid="tlyons" cn="Todd Lyons" cn="pam"
search_tidyup called
unbind LDAP connection to ivwm01.ivenue.net:389
Looking at my system, I see that I'm using STARTTLS, and so was the
bug submitter. Without having dug too far into the code, it seems
like fixing STARTTLS is what broke your port 636 ldaps:/// access. If
you use port 389 on your master server and let STARTTLS occur with
require_cert=allow, I wonder if that would fix it.
...Todd
--
The total budget at all receivers for solving senders' problems is $0.
If you want them to accept your mail and manage it the way you want,
send it the way the spec says to. --John Levine
