the hint for that error, may be at the end of the line, with: certificate verify failed (unable to get issuer certificate)
the LDAP instances and systems need to trust the issuers of the newer certificates of each other ( PKI trust chain ). trust anchor ~/some.ca.crt trust list | grep -i "some CA" and dsconf some-ldap-instance security ca-certificate add --file ~/some.ca.crt --name testca documentation reference: https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/managing_the_nss_database_used_by_directory_server 9.3. MANAGING THE NSS DATABASE USED BY DIRECTORY SERVER Thanks, M. On Wed, Apr 26, 2023 at 1:43 PM John Thurston <[email protected]> wrote: > I have two hosts with 389-Directory/1.4.4.17 B2021.280.1354 on CentOS > Stream release 8 (4.18.0-448.el8.x86_64) > > On a.state.ak.us, there is one instance defined (call this instance #1) > > On b.state.ak.us, there are two instances defined (call them #2 and #3) > > Instances #1 and #3 have GlobalSign certificates installed. Instance #2 > currently has a Let's Encrypt certificate installed. All instances also > have root and intermediate certs in their databases for GlobalSign, which > are marked with Trust Flags "CT,,". > > I can define instance #2 as a supplier, and define a replication agreement > which populates #3. This works with both LDAPS and STARTTLS. > > If I, instead, try to define the same replication agreement on instance > #1, it fails with: > > slapi_ldap_bind - Error: could not send startTLS request: error -11 > (Connect error) > > NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=DS11-1to3" (b:389) - > Replication bind with SIMPLE auth failed: LDAP error -11 (Connect error) > (error:1416F086:SSL routines:tls_process_server_certificate:certificate > verify failed (unable to get issuer certificate)) > > slapi_ldap_bind - Error: could not send startTLS request: error -11 > (Connect error) > > > I am unable to figure out how instances #1 and #2 differ. > > Instance #1 has long-established supplier-agreements (using both LDAPS and > STARTTLS) with other instances of 389-Directory. So I know instance #1 can > function correctly as a supplier. Instance #3 demonstrates it can be a > consumer when supplied by instance #2. I can perform LDAPS and STARTTLS > queries from a.state.ak.us to instance #3, so I know it is listening on > the network and not blocked by a host-based firewall. > > Any suggestions of where to look, or config-attributes to check, would be > appreciated. > > > -- > -- > Do things because you should, not just because you can. > > John Thurston [email protected] > Department of Administration > State of Alaska > > _______________________________________________ > 389-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue >
_______________________________________________ 389-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
