Bug 852088

Summary: server to server ssl client auth broken with latest openldap
Product: Red Hat Enterprise Linux 6 Reporter: Rich Megginson <rmeggins>
Component: 389-ds-baseAssignee: Rich Megginson <rmeggins>
Status: CLOSED ERRATA QA Contact: Sankar Ramalingam <sramling>
Severity: unspecified Docs Contact:
Priority: high    
Version: 6.4CC: jgalipea, jvcelak, nhosoi, nkinder
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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 08:20:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Rich Megginson 2012-08-27 15:12:18 UTC
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 Severance 2012-08-27 16:05:36 UTC
What is the openldap rhel 6.4 bugzilla this is dependent on?
Thanks

Comment 2 Rich Megginson 2012-08-27 16:07:54 UTC
(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 08:26:08 UTC
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 14:10:31 UTC
(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 21:08:06 UTC
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>
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 21:11:52 UTC
(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>
> 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 21:20:59 UTC
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 18:37:37 UTC
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 19:48:58 UTC
Hi Noriko, can we mark this bug as verified if all mmrepl/accept tests PASS?

Comment 11 Noriko Hosoi 2012-11-15 20:02:56 UTC
(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 10:40:25 UTC
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 08:20:35 UTC
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