"LDAP error: Can't contact LDAP server (connection error)" is kind of
generic, but often relates to PKI trust misconfiguration when TLS is used,
a common issue is the issuer / CA certificate(s) chain is not installed, or
not trusted.
There should be a message in the access log, for example "Peer does not
recognize and trust the CA that issued your certificate."
a typical scenario is when the default test /demo/self signed certs are
left over and used between 2 LDAP instances for replication, we have an
example in this article (subscription required)
How To test LDAPS with RHDS instances on 2 systems and default test CA
this happens as there is no shared configuration between instances.
in the links Thierry B. posted, also see this chapter:
1.8. Adding the CA certificate used by Directory Server to the trust store
of Red Hat Enterprise Linux
I usually run a "trust anchor some.file.ca.crt" command, and add the
issuer(s) to the LDAP instance's NSS db.
On Fri, Jan 26, 2024 at 1:21 AM Thierry Bordaz <tbordaz(a)redhat.com> wrote:
You may follow the doc to configure TLS on your both suppliers [1]
and
check the trusted CA on both side [2]. On troubleshooting side you may look
at [3]
[1]
https://access.redhat.com/documentation/en-us/red_hat_directory_server/12...
[2]
https://access.redhat.com/documentation/en-us/red_hat_directory_server/12...
[3]
https://access.redhat.com/documentation/en-us/red_hat_directory_server/12...
On 1/25/24 23:55, Ciara Gadsden wrote:
Idk how to do that lol
Sent from my Boost Samsung Galaxy A23 5G
Get Outlook for Android <
https://aka.ms/AAb9ysg>
------------------------------
*From:* Simon Pichugin <spichugi(a)redhat.com> <spichugi(a)redhat.com>
*Sent:* Thursday, January 25, 2024 5:44:57 PM
*To:* General discussion list for the 389 Directory server project.
<389-users(a)lists.fedoraproject.org> <389-users(a)lists.fedoraproject.org>
*Cc:* alexander_nazarenko(a)harvard.edu <alexander_nazarenko(a)harvard.edu>
<alexander_nazarenko(a)harvard.edu>
*Subject:* [389-users] Re: 389 DS 2.3.6 on RHEL 9 replication over TLS
Hello Alex,
I think we need a bit more information here.
First of all, could you please run the "dsconf repl-agmt create" (LDAPS
one) with "-v" flag? It will give a detailed verbose output.
Also, I recommend checking the server's error and access log for more
information why it fails (additionally, you may enable at least 16384+8192
(Default + Replication debugging) in nsslapd-errorlog-level).
As for possible issues and actions, at first glance, I recommend checking
that the TLS certificates used are correctly installed and trusted on both
the supplier and consumer instances. It's important that the instances
trust each other; even though ldapsearch (OpenLDAP client) on the supplier
already trusts the consumer machine, it's not enough.
Sincerely,
Simon
On Thu, Jan 25, 2024 at 1:07 PM Nazarenko, Alexander <
alexander_nazarenko(a)harvard.edu> wrote:
Hello colleagues,
Lately we started looking into 389 DS 2.3.6 on RHEL 9 platform.
We followed instructions Configuring and managing replication
<
https://access.redhat.com/documentation/en-us/red_hat_directory_server/12...
on Red Hat site to establish replication between two remote instances,
The instances where previously configured to support TLS channel on port
636 (Enabling TLS-encrypted connections to Directory Server
<
https://access.redhat.com/documentation/en-us/red_hat_directory_server/12...
) , and we made sure ldapsearch is working with LDAPS:// protocol with
the certificate verification (TLS_REQCERT demand).
The following issue with the replication over TLS was observed:
After we ran the command below to configure secure replication:
dsconf -D "cn=Directory Manager" -w ***
ldaps://server.example.edu
repl-agmt create --suffix "dc=example,dc=com" --host
"consumer.example.edu"
--port 636 --conn-protocol=LDAPS --bind-dn "cn=replication
manager,cn=config" --bind-passwd "***" --bind-method=SIMPLE --init
consumer.example.edu-RO
the error occurred:
Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP
server (connection error)
We double-checked that after we configure clear text replication with the
command:
dsconf -D "cn=Directory Manager" -w ***
ldaps://server.example.edu
repl-agmt create --suffix "dc=example,dc=com" --host
"consumer.example.edu"
--port 389 --conn-protocol=LDAP --bind-dn "cn=replication
manager,cn=config" --bind-passwd "***" --bind-method=SIMPLE --init
10.140.133.36-RO
no problem occurred, and the replication completed successfully.
My question is whether this means the replication over TLS required
different config steps, and if yes – what they are?
Thank you,
- Alex
--
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue