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 ?