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-8591
John.Thurston(a)alaska.gov
Department of Administration
State of Alaska
