"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) https://access.redhat.com/solutions/6449561 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 https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/html/securing_red_hat_directory_server/assembly_enabling-tls-encrypted-connections-to-directory-server_securing-rhds#proc_adding-the-ca-certificate-used-by-directory-server-to-the-trust-store-of-red-hat-enterprise-linux_assembly_enabling-tls-encrypted-connections-to-directory-server 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 <tbor...@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/html/securing_red_hat_directory_server/assembly_enabling-tls-encrypted-connections-to-directory-server_securing-rhds#doc-wrapper > [2] > https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/html/securing_red_hat_directory_server/assembly_changing-the-ca-trust-flagssecuring-rhds#doc-wrapper > [3] > https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/html/configuring_and_managing_replication/assembly_troubleshooting-replication-related-problems_configuring-and-managing-replication > > > 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 <spich...@redhat.com> <spich...@redhat.com> > *Sent:* Thursday, January 25, 2024 5:44:57 PM > *To:* General discussion list for the 389 Directory server project. > <389-users@lists.fedoraproject.org> <389-users@lists.fedoraproject.org> > *Cc:* alexander_nazare...@harvard.edu <alexander_nazare...@harvard.edu> > <alexander_nazare...@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_nazare...@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/html-single/configuring_and_managing_replication/index> > 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/html/securing_red_hat_directory_server/assembly_enabling-tls-encrypted-connections-to-directory-server_securing-rhds> > ) , 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@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@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.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > > > -- > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@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.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > > -- > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@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.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue >
-- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@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.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
