[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: TLS very strange behaviour
On 10/14/2011 01:48 AM, Olivier Guillard wrote:
Hi Rich
as far as I remember, when I used this version :
openldap-servers-2.4.23-15.el6_1.1.x86_64
I could use external mecanism in syncrepl and was
able to present the client certificate without asking for
the server one.
My syncrepl sections looked like this :
syncrepl rid=121
provider=ldap://ldap2.example.fr
searchbase="dc=example,dc=fr"
schemachecking=on
type=refreshOnly
interval=00:00:00:05
retry="10 +"
bindmethod=sasl
saslmech=external
tls_cert=/etc/openldap/cacerts/syncrepl.crt
tls_key=/etc/openldap/cacerts/syncrepl.key
And that worked. BTW, I'm not sure that his should have
worked since I think normaly the protocole indicates that
the client should check the server cert before sending its.
Yes, that's odd.
Anyway that worked (-:
With openldap-servers-2.4.23-15.el6_1.3.x86_64, I'm not
able to use the external mecanism anymore if I don't add
explicitely the following directives in syncrepl: "starttls=yes",
"tls_cacert=.../cacerts/CA.crt" and "tls_reqcert=allow/try/demand"
I don't think it ever should have worked without at least specifying
starttls=yes (and assuming that didn't fallback - I think starttls=yes
is misleading, as it will just silently fallback to plain LDAP if it
doesn't establish a TLS connection - everything will seem to be working,
but unless you have set up the server to require a TLS connection, it
will just work and you won't know that it is not using TLS). I
recommend always using starttls=critical to make sure your client will
only work if TLS was successfully established.
That works in master/slave mode, that doesn't in multimaster.
Now last thing : I've never been able to make work syncrepl
with : "starttls=yes", "tls_cacert=.../cacerts/CA.crt" and
"tls_reqcert=allow/try/demand" in multimaster N-WAY mode
anyway (nor now, nor before).
I only made it work in master/salve and that weither using
simple or sasl bindmethod.
So the problem is not linked to sasl in my view but with
tls in synchrepl (may be both slapd try to use the first
TLS session opened to exchange in both direction in
multimaster, a shared variable mixing information about
certicates ? something like that).
Would it be possible for you to get it working with simple
binddn/password auth first, to see if that is working? Then we could at
least narrow down the problem to being related to sasl/external auth.
I just realise that I had a core dump collected by abrtd (not
sure if that could help nor how to use it, I'm not familiar with
this kind of debugging) : let me know if that file could help
(or if I could try to run any gdb command using that file).
Yes indeed that would be very helpful.
https://bugzilla.redhat.com/show_bug.cgi?id=701678#c6 has some
information about handling openldap core dumps on RHEL6
Best,
---
Olivier
On Wed, Oct 12, 2011 at 10:25 PM, Rich Megginson
<rich.megginson@gmail.com> wrote:
On 10/11/2011 02:38 AM, Olivier Guillard wrote:
Thanks Rich, see below :
-12272 is SSL_ERROR_BAD_MAC_ALERT and -12273 is SSL_ERROR_BAD_MAC_READ
I've seen this when the client and server do not have the same SSL
certificate signature algorithm support. Is everything running on RHEL6
and/or Fedora 14 and later?
[root@ldap2 ~]# cat /etc/issue
Red Hat Enterprise Linux Server release 6.1 (Santiago)
Kernel \r on an \m
[root@ldap2 ~]# rpm -qa | grep -i openldap
openldap-2.4.23-15.el6_1.3.x86_64
openldap-servers-2.4.23-15.el6_1.3.x86_64
openldap-debuginfo-2.4.23-15.el6_1.1.x86_64
openldap-clients-2.4.23-15.el6_1.3.x86_64
[root@ldap1 ~]# cat /etc/issue
Red Hat Enterprise Linux Server release 6.1 (Santiago)
Kernel \r on an \m
[root@ldap1 ~]# rpm -qa | grep -i openldap
openldap-debuginfo-2.4.23-15.el6_1.1.x86_64
openldap-clients-2.4.23-15.el6_1.3.x86_64
openldap-2.4.23-15.el6_1.3.x86_64
openldap-servers-2.4.23-15.el6_1.3.x86_64
[root@ldap2 cacerts]# rpm -qa | grep openssl
openssl-1.0.0-10.el6_1.4.x86_64
[root@ldap1 ldap1]# rpm -qa | grep openssl
openssl-1.0.0-10.el6_1.4.x86_64
Not sure if that made a difference but I "yum-updated"
on last friday and openldap servers version passed :
from
openldap-servers-2.4.23-15.el6_1.1.x86_64
to
openldap-servers-2.4.23-15.el6_1.3.x86_64
Was it working before you yum updated?
---
Olivier
On Mon, Oct 10, 2011 at 9:54 PM, Rich Megginson
<rich.megginson@gmail.com> wrote:
here is what I get :
ldap1 # /usr/sbin/slapd -f slapd.conf -h ldap:/// -u ldap -d Sync
...
TLS: error: accept - force handshake failure: errno 11 - moznss error
-12273
TLS: can't accept: TLS error -12273:Unknown code ___P 15.
TLS: error: connect - force handshake failure: errno 0 - moznss error
-12272
TLS: can't connect: TLS error -12272:Unknown code ___P 16.
slap_client_connect: URI=ldap://ldap2.example.fr Warning,
ldap_start_tls failed (-11)
slap_client_connect: URI=ldap://ldap2.example.fr
ldap_sasl_interactive_bind_s failed (-6)
do_syncrepl: rid=121 rc -6 retrying
ldap2 # /usr/sbin/slapd -f slapd.conf -h ldap:/// -u ldap -d Sync
...
TLS: error: connect - force handshake failure: errno 0 - moznss error
-12272
TLS: can't connect: TLS error -12272:Unknown code ___P 16.
slap_client_connect: URI=ldap://ldap1.eaxample.fr:389 Warning,
ldap_start_tls failed (-11)
slap_client_connect: URI=ldap://ldap1.example.fr:389
ldap_sasl_interactive_bind_s failed (-6)
do_syncrepl: rid=211 rc -6 retrying
TLS: error: accept - force handshake failure: errno 11 - moznss error
-12273
TLS: can't accept: TLS error -12273:Unknown code ___P 15.
Any idea ?