Bug 852088 - server to server ssl client auth broken with latest openldap
server to server ssl client auth broken with latest openldap
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base (Show other bugs)
6.4
Unspecified Unspecified
high Severity unspecified
: rc
: ---
Assigned To: Rich Megginson
Sankar Ramalingam
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-27 11:12 EDT by Rich Megginson
Modified: 2013-02-21 03:20 EST (History)
4 users (show)

See Also:
Fixed In Version: 389-ds-base-1.2.11.12-1.el6
Doc Type: Bug Fix
Doc Text:
Cause: Using multi-master replication or database chaining with TLS/SSL and attempting to use client certificate based authentication between the servers. Consequence: Server is unable to connect and there are connection errors in the errors log. Fix: Perform the internal TLS/SSL and certificate setup via the openldap libraries correctly. Result: Server to server communications (replication, chaining) work using certificate based authentication.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-21 03:20:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rich Megginson 2012-08-27 11:12:18 EDT
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/430

openldap 2.4.31 changed how it does crypto initialization.  It now creates a brand new slot/token for each SSL context.  389 relies on the old behavior of a single, global, shared crypto context.  This causes server to server SSL using client cert auth to fail because the cert/key db in the new crypto context is locked, even if the server's main crypto db is unlocked.
Comment 1 Jenny Galipeau 2012-08-27 12:05:36 EDT
What is the openldap rhel 6.4 bugzilla this is dependent on?
Thanks
Comment 2 Rich Megginson 2012-08-27 12:07:54 EDT
(In reply to comment #1)
> What is the openldap rhel 6.4 bugzilla this is dependent on?
> Thanks

Jan, were you planning to get openldap 2.4.31 or later in to RHEL 6.4?  What about RHEL 6.5?
Comment 3 Jan Vcelak 2012-08-28 04:26:08 EDT
There are no plans for OpenLDAP rebase. But we are currently considering the backport of all the fixes/changes in MozNSS backend from 2.4.31 to RHEL-6.4.

I'm aware of this problem. And I will not proceed without consulting you before.

I have a test build with these fixes applied, if you are interested:
http://people.redhat.com/jvcelak/bz707599/
Comment 4 Rich Megginson 2012-08-28 10:10:31 EDT
(In reply to comment #3)
> There are no plans for OpenLDAP rebase. But we are currently considering the
> backport of all the fixes/changes in MozNSS backend from 2.4.31 to RHEL-6.4.

Ok.  So we definitely need to make sure 389-ds-base in RHEL 6.4 has the fix for 
https://fedorahosted.org/389/ticket/430

> 
> I'm aware of this problem. And I will not proceed without consulting you
> before.
> 
> I have a test build with these fixes applied, if you are interested:
> http://people.redhat.com/jvcelak/bz707599/
Comment 6 Noriko Hosoi 2012-09-06 17:08:06 EDT
We may need to reopen this bug again... Reliab15 shows the following errors:

[05/Sep/2012:21:21:50 -0400] - SSL alert: SSL client authentication cannot be used (no password). (Netscape Portable Runtime error -5987 - Invalid function argument.)
[05/Sep/2012:21:21:50 -0400] slapi_ldap_bind - Error: could not send bind request for id [(anon)] mech [EXTERNAL]: error -1 (Can't contact LDAP server) -5987 (Invalid function argument.) 107 (Transport endpoint is not connected)
[05/Sep/2012:21:21:50 -0400] NSMMReplicationPlugin - agmt="cn=M1H1" (blademtv2:38104): Replication bind with EXTERNAL auth failed: LDAP error -1 (Can't contact LDAP server) ((null))

dn: cn=M1H1,cn=replica,cn=o\3Dmy_suffix.com,cn=mapping tree,cn=config
nsDS5ReplicaTransportInfo: SSL
nsDS5ReplicaBindMethod: SSLCLIENTAUTH

[05/Sep/2012:21:29:03 -0400] NSMMReplicationPlugin - agmt="cn=H1C4" (zion:38109)
: binddn = uid=repl_mgr,cn=o\3DNetscapeRoot,cn=mapping tree,cn=config,  passwd =
 {DES}XPo05W/iUC1xJeTsJcFEFQ==
[05/Sep/2012:21:29:03 -0400] slapi_ldap_bind - Error: could not send bind reques
t for id [uid=repl_mgr,cn=o\3DNetscapeRoot,cn=mapping tree,cn=config] mech [SIMP
LE]: error -1 (Can't contact LDAP server) -5987 (Invalid function argument.) 107
 (Transport endpoint is not connected)
[05/Sep/2012:21:29:03 -0400] NSMMReplicationPlugin - agmt="cn=H1C4" (zion:38109)
: Replication bind with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP se
rver) ((null))

dn: cn=H1C4,cn=replica,cn=o\3Dmy_suffix.com,cn=mapping tree,cn=config
nsDS5ReplicaTransportInfo: SSL
nsDS5ReplicaBindMethod: SIMPLE

The openldap is new.
# rpm -q openldap
openldap-2.4.32-2.fc17.x86_64

And my build contains this fix.
commit 53c974f363d633aedfea40690a6aa4bfbeb00de0
Author: Rich Megginson <​rmeggins@redhat.com>
Date: Mon Aug 20 12:20:21 2012 -0600

Ticket #430 - server to server ssl client auth broken with latest openldap
Comment 7 Rich Megginson 2012-09-06 17:11:52 EDT
(In reply to comment #6)
> We may need to reopen this bug again... Reliab15 shows the following errors:
> 
> [05/Sep/2012:21:21:50 -0400] - SSL alert: SSL client authentication cannot
> be used (no password). (Netscape Portable Runtime error -5987 - Invalid
> function argument.)

Is this the same error you saw before?

I thought you tested the new 389 with the new openldap and it worked - now it doesn't?  What changed?

> [05/Sep/2012:21:21:50 -0400] slapi_ldap_bind - Error: could not send bind
> request for id [(anon)] mech [EXTERNAL]: error -1 (Can't contact LDAP
> server) -5987 (Invalid function argument.) 107 (Transport endpoint is not
> connected)
> [05/Sep/2012:21:21:50 -0400] NSMMReplicationPlugin - agmt="cn=M1H1"
> (blademtv2:38104): Replication bind with EXTERNAL auth failed: LDAP error -1
> (Can't contact LDAP server) ((null))
> 
> dn: cn=M1H1,cn=replica,cn=o\3Dmy_suffix.com,cn=mapping tree,cn=config
> nsDS5ReplicaTransportInfo: SSL
> nsDS5ReplicaBindMethod: SSLCLIENTAUTH
> 
> [05/Sep/2012:21:29:03 -0400] NSMMReplicationPlugin - agmt="cn=H1C4"
> (zion:38109)
> : binddn = uid=repl_mgr,cn=o\3DNetscapeRoot,cn=mapping tree,cn=config, 
> passwd =
>  {DES}XPo05W/iUC1xJeTsJcFEFQ==
> [05/Sep/2012:21:29:03 -0400] slapi_ldap_bind - Error: could not send bind
> reques
> t for id [uid=repl_mgr,cn=o\3DNetscapeRoot,cn=mapping tree,cn=config] mech
> [SIMP
> LE]: error -1 (Can't contact LDAP server) -5987 (Invalid function argument.)
> 107
>  (Transport endpoint is not connected)
> [05/Sep/2012:21:29:03 -0400] NSMMReplicationPlugin - agmt="cn=H1C4"
> (zion:38109)
> : Replication bind with SIMPLE auth failed: LDAP error -1 (Can't contact
> LDAP se
> rver) ((null))
> 
> dn: cn=H1C4,cn=replica,cn=o\3Dmy_suffix.com,cn=mapping tree,cn=config
> nsDS5ReplicaTransportInfo: SSL
> nsDS5ReplicaBindMethod: SIMPLE
> 
> The openldap is new.
> # rpm -q openldap
> openldap-2.4.32-2.fc17.x86_64
> 
> And my build contains this fix.
> commit 53c974f363d633aedfea40690a6aa4bfbeb00de0
> Author: Rich Megginson <​rmeggins@redhat.com>
> Date: Mon Aug 20 12:20:21 2012 -0600
> 
> Ticket #430 - server to server ssl client auth broken with latest openldap
Comment 8 Noriko Hosoi 2012-09-06 17:20:59 EDT
Well, the original problem was found in mmrepl/accept:
> It turned out the consumer initialization over SSL is hanging (or may be
too slow???).

And the acceptance test successfully passed.  So, I was assuming it was working fine...
Comment 9 Noriko Hosoi 2012-09-07 14:37:37 EDT
Please ignore my comment6!!  It was a false alarm!!
https://bugzilla.redhat.com/show_bug.cgi?id=852088#c6

The certs used in my first reliab15 run were expired.  Once they are renewed, the test is running gracefully.  No SSL errors at all.
Comment 10 Sankar Ramalingam 2012-11-15 14:48:58 EST
Hi Noriko, can we mark this bug as verified if all mmrepl/accept tests PASS?
Comment 11 Noriko Hosoi 2012-11-15 15:02:56 EST
(In reply to comment #10)
> Hi Noriko, can we mark this bug as verified if all mmrepl/accept tests PASS?

Yes, we can.
Comment 12 Sankar Ramalingam 2012-11-19 05:40:25 EST
No failures encountered from mmrept/accept tests. Hence marking the bug as Verified.

    mmrepl mmraccept startup elapse time : 00:11:22
    mmrepl mmraccept startup Tests PASS      : 100% (2/2)

    mmrepl mmraccept run elapse time : 00:12:17
    mmrepl mmraccept run Tests PASS      : 100% (27/27)
Comment 13 errata-xmlrpc 2013-02-21 03:20:35 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0503.html

Note You need to log in before you can comment on or make changes to this bug.