Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1356226 - fails to connect when agreement is configured under ssl.
Summary: fails to connect when agreement is configured under ssl.
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.2
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: mreynolds
QA Contact: Viktor Ashirov
Depends On:
TreeView+ depends on / blocked
Reported: 2016-07-13 18:22 UTC by German Parente
Modified: 2017-10-20 11:03 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-03-30 15:17:28 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2455201 None None None 2016-07-28 09:04:55 UTC

Description German Parente 2016-07-13 18:22:17 UTC
Description of problem:

I am not sure if I am using in a wrong way. But from my understanding, either we use it simplest as possible like this: -s -c ipanew:389 -w secret12

and the current instance in 389 port has a replication agreement like this:

dn: cn=torhel6,cn=replica,cn=dc\3Dmyexample\2Cdc\3Dcom,cn=mapping tree,cn=config
objectClass: top
objectClass: nsDS5ReplicationAgreement
cn: torhel6
nsDS5ReplicaRoot: dc=myexample,dc=com
nsDS5ReplicaPort: 636
nsDS5ReplicaTransportInfo: SSL
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsDS5ReplicaBindMethod: SIMPLE
nsDS5ReplicaCredentials: secret12

it seems the server "" is added to the list of servers and in 

sub get_replicas
        $conn = new Mozilla::LDAP::Conn ($host, $shadowport, "$binddn", $bindpwd, $bindcert);


the connection is done with the right host and port but the bind cert is empty.

So, the connection hangs.

It seems to be the same if I use "-f file" with the connections to the server usingport 389 because it's still browsing the agreemnts (from what I have seen) and trying to use the host and port defined in the agreement.

Perhaps I am not using the script as expected ?

Please, feel free to close this bug if it's the case.

Version-Release number of selected component (if applicable):


How reproducible:

it's shown in description.

Comment 1 Viktor Ashirov 2016-07-13 18:32:54 UTC
Hi German,

you should pass cert file in the connection string like this:
-c "host:port:binddn:bindpwd:bindcert"

Or specify the same in the replication config file.

Comment 7 mreynolds 2016-12-07 18:08:29 UTC
Upstream ticket:

Comment 8 mreynolds 2017-03-28 20:21:40 UTC
German this appears to work correctly for me: -c localhost.localdomain:636:cn=directory manager:password:/etc/dirsrv/slapd-localhost/ -s

Supplier: localhost.localdomain:636
Replica Root: dc=example,dc=com
Replica ID: 1
Max CSN: 58dabb25000000010000 (03/28/2017 15:36:05)
Consumer: localhost.localdomain:6360 ldap://localhost.localdomain:6360/
Type: consumer
Time Lag: 0:00:00
Supplier Max CSN: 58dabb25000000010000 (03/28/2017 15:36:05)
Consumer Max CSN: 58dabb25000000010000 (03/28/2017 15:36:05)
Last Modify Time: 3/28/2017 15:36:05
Supplier: localhost.localdomain:636
Sent/Skipped: 5 / 0
Update Status: Error (0) Replica acquired successfully: Incremental update succeeded
Update Started: 03/28/2017 15:36:05
Update Ended: 03/28/2017 15:36:05
Schedule: always in sync
SSL: n

You do have to set the cert dir and secure port in the connection details because it is using SSL in the agreement.

On a side note - I did find a problem with the output not detecting that SSL is being used.

Back to the original issue...  Does the example above work for you?  Or is there a different scenario I should try?

Comment 9 German Parente 2017-03-30 08:18:42 UTC
Hi Mark,

thanks. Let's close this bug.

In fact, if we have several repl. agreements and one of them under ssl and not the others, for instance, and in the connection details we decide to use clear port, this could fail.

But if we use the secure port will not, as you have shown.

Thanks. Let's close it.

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