[389-users] Re: Unable to establish replication with STARTTLS

[Marc Sauton]

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...
9.3. MANAGING THE NSS DATABASE USED BY DIRECTORY SERVER

Thanks,
M.

On Wed, Apr 26, 2023 at 1:43 PM John Thurston <john.thurston(a)alaska.gov&gt;
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    907-465-8591John.Thurston(a)alaska.gov
>  Department of Administration
>  State of Alaska
>
>  _______________________________________________
>  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/[e-mail]...
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>