RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 852088 - server to server ssl client auth broken with latest openldap
Summary: server to server ssl client auth broken with latest openldap
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base
Version: 6.4
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: Sankar Ramalingam
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-08-27 15:12 UTC by Rich Megginson
Modified: 2020-09-13 20:15 UTC (History)
4 users (show)

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.
Clone Of:
Environment:
Last Closed: 2013-02-21 08:20:35 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 430 0 None None None 2020-09-13 20:15:55 UTC
Red Hat Product Errata RHSA-2013:0503 0 normal SHIPPED_LIVE Moderate: 389-ds-base security, bug fix, and enhancement update 2013-02-21 08:18:44 UTC

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
Note You need to log in before you can comment on or make changes to this bug.