Unable to establish replication with STARTTLS

[John Thurston]

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

[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
>

[William Brown]

>  
>  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.
The first check would be from on the host instance #1:

openssl s_client -connect hostname-of-instance-two:636 -showcerts

And assert that the connection proceeds and the certificate chain presented is as you
expect. 



--
Sincerely,

William Brown

Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia

[John Thurston]

Revisiting this problem of replication and certificates. Thank you Marc 
Sauton for pointing out the 'dsconf' command to spill the ca-cert list.

The synopsis is: instance #1 can replicate with instance #3 when #3 has 
a GlobalSign cert, but not when #3 has a Let's Encrypt cert. Instance #2 
has no such problem replicating.

(All instances are running 1.4.4.17 B2021.280.1354 on CentOS)

On instance #1 (and on instance #2), when we use dsconf to ask about the 
ca-certificate list, we get:

>  Certificate Name: GlobalSign Root R3
>  Subject DN: CN=GlobalSign,O=GlobalSign,OU=GlobalSign Root CA - R3
>  Issuer DN: CN=GlobalSign,O=GlobalSign,OU=GlobalSign Root CA - R3
>  Expires: 2029-03-18 10:00:00
>  Trust Flags: CT,,
>
>  Certificate Name: GlobalSign RSA Organization Validation CA - 2018
>  Subject DN: CN=GlobalSign RSA OV SSL CA 2018,O=GlobalSign nv-sa,C=BE
>  Issuer DN: CN=GlobalSign,O=GlobalSign,OU=GlobalSign Root CA - R3
>  Expires: 2028-11-21 00:00:00
>  Trust Flags: CT,,
>
>  Certificate Name: Lets Encrypt Top
>  Subject DN: CN=ISRG Root X1,O=Internet Security Research Group,C=US
>  Issuer DN: CN=DST Root CA X3,O=Digital Signature Trust Co.
>  Expires: 2024-09-30 18:14:03
>  Trust Flags: CT,,
>
>  Certificate Name: Lets Encrypt Intermediate
>  Subject DN: CN=R3,O=Let's Encrypt,C=US
>  Issuer DN: CN=ISRG Root X1,O=Internet Security Research Group,C=US
>  Expires: 2025-09-15 16:00:00
>  Trust Flags: CT,, 
On instance #3, when a GlobalSign cert is installed and port 636 is 
queried with openssl s_client:

>  CONNECTED(00000003)
>  depth=2 OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
>  verify return:1
>  depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
>  verify return:1
>  depth=0 C = US, ST = Alaska, L = Juneau, O = State of Alaska, CN = 
>  ancds10.state.ak.us
>  verify return:1
>  ---
>  Certificate chain
>   0 s:C = US, ST = Alaska, L = Juneau, O = State of Alaska, CN = 
>  ancds10.state.ak.us
>     i:C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
>     a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>     v:NotBefore: Apr 26 18:06:15 2023 GMT; NotAfter: May 27 18:06:14 
>  2024 GMT
>   1 s:C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
>     i:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
>     a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>     v:NotBefore: Nov 21 00:00:00 2018 GMT; NotAfter: Nov 21 00:00:00 
>  2028 GMT
>   2 s:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
>     i:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
>     a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>     v:NotBefore: Mar 18 10:00:00 2009 GMT; NotAfter: Mar 18 10:00:00 
>  2029 GMT
>  ---
>  Server certificate
>  -----BEGIN CERTIFICATE-----
>  MIIGijCCBXKgAwIBAgIMfqUEla3ttBPK/lvlMA0GCSqGSIb3DQEBCwUAMFAxCzAJ
>  BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSYwJAYDVQQDEx1H
>  bG9iYWxTaWduIFJTQSBPViBTU0wgQ0EgMjAxODAeFw0yMzA0MjYxODA2MTVaFw0y
>  NDA1MjcxODA2MTRaMGcxCzAJBgNVBAYTAlVTMQ8wDQYDVQQIEwZBbGFza2ExDzAN
>  BgNVBAcTBkp1bmVhdTEYMBYGA1UEChMPU3RhdGUgb2YgQWxhc2thMRwwGgYDVQQD
>  ExNhbmNkczEwLnN0YXRlLmFrLnVzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
>  CgKCAQEA12s9pW28BNfMPMUdV54DFGg7EmJv7pcmYhnOvq0vqQ845tEillOHptUj
>  muwVOgj8Dcl+PPiDHXeggwKdMA9253Pov7eVGzKfmNN1IwSmOZYKaNLKy1CNQS13
>  eD0Wov0+yq35CqRHWwsl8+7Og56IfPXSmmRQPp21VBC//qkcBezomtTaSSzeE1op
>  248cN8H0wjL0gsPdujzrJmr7xP1gNT4gZQVkNlEAo8hJ3IxvSPvJ+E24FJwMixVb
>  ICUz/crjRXG9nSSudP/225GxaaG3QPOSzOIZD4sT+Pt7lxmQU1syTChd5SHVK1AS
>  WW4I2z1j68/o/ujXiqeP4iiMysRzXQIDAQABo4IDSzCCA0cwDgYDVR0PAQH/BAQD
>  AgWgMIGOBggrBgEFBQcBAQSBgTB/MEQGCCsGAQUFBzAChjhodHRwOi8vc2VjdXJl
>  Lmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3JzYW92c3NsY2EyMDE4LmNydDA3Bggr
>  BgEFBQcwAYYraHR0cDovL29jc3AuZ2xvYmFsc2lnbi5jb20vZ3Nyc2FvdnNzbGNh
>  MjAxODBWBgNVHSAETzBNMEEGCSsGAQQBoDIBFDA0MDIGCCsGAQUFBwIBFiZodHRw
>  czovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAIBgZngQwBAgIwCQYD
>  VR0TBAIwADA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24u
>  Y29tL2dzcnNhb3Zzc2xjYTIwMTguY3JsMB4GA1UdEQQXMBWCE2FuY2RzMTAuc3Rh
>  dGUuYWsudXMwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMB8GA1UdIwQY
>  MBaAFPjvf/LNeGeo3m+PJI2I8YcDArPrMB0GA1UdDgQWBBQ7Sj3cl8+m/NHTW2Gs
>  QN+x7P7iMTCCAX8GCisGAQQB1nkCBAIEggFvBIIBawFpAHYAc9meiRtMlnigIH1H
>  neayxhzQUV5xGSqMa4AQesF3crUAAAGHvr64EQAABAMARzBFAiBQcBIdszriaxKs
>  vUFlLbKEH4jRYQoKwWjWX7sKIJRn2AIhAJ54vIDKjHY+si3R6qKS/xKhHUWASU4l
>  YKxu/GPB+Z22AHYA7s3QZNXbGs7FXLedtM0TojKHRny87N7DUUhZRnEftZsAAAGH
>  vr65OAAABAMARzBFAiBFFZn7eXA4dcDwX4+DbuHqMgtFSqGWcb18/kNymrcXzAIh
>  AI1RfNaDFrbkPE2l/xc/Rj9C6zI4BvlGpcyw7CI+qAB3AHcA2ra/az+1tiKfm8K7
>  XGvocJFxbLtRhIU0vaQ9MEjX+6sAAAGHvr64vwAABAMASDBGAiEAjTr0QpjbfuZw
>  kH1C6/rvfI8vcuZsMijy3cByBjpiO4ACIQDYFzAcyjiG+8WA0KpM1roXLFZp/GXf
>  8hJP+yYVvKVtXzANBgkqhkiG9w0BAQsFAAOCAQEAld/5Th8eHwDUO273c0ISRWfI
>  ts1j/AzyhbKhhKJI/CuALjB34jsynQoqDOS4LevMsVwftGcw0LYzTNDyKaKtUKb5
>  Uj5El1dUdhne2Je+5jKu6lOeCvM5HZg/kEBdb5JRsl1GQxvnxlgEMq+kfFaphUAj
>  3u+zVkJsdbMk6mUBy8+7+NZM7l5c1QiXbFMP/VGh3u3fgVOgcLUuKMZaHa9UbhUq
>  mS6nOmmuVE9xNBgyCYfS2Fwrp+2j5zktFBzoxe+L8i37DVp83GKZQZxx5mOCC28J
>  YN57RNh3T7i+nDsGRVoVp28b2SmDKTh20tOYMs89khe0npancuIl7rklo+BlSg==
>  -----END CERTIFICATE-----
>  subject=C = US, ST = Alaska, L = Juneau, O = State of Alaska, CN = 
>  ancds10.state.ak.us
>  issuer=C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
>  ---
>  No client certificate CA names sent
>  Peer signing digest: SHA256
>  Peer signature type: RSA-PSS
>  Server Temp Key: X25519, 253 bits
>  ---
>  SSL handshake has read 4159 bytes and written 387 bytes
>  Verification: OK
>  ---
>  New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
>  Server public key is 2048 bit
>  Secure Renegotiation IS NOT supported
>  Compression: NONE
>  Expansion: NONE
>  No ALPN negotiated
>  Early data was not sent
>  Verify return code: 0 (ok)
>  ---
>  DONE 
On instance #3 when a Let's Encrypt cert is installed and port 636 
queried with openssl s_client:


>  CONNECTED(00000003)
>  depth=2 OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
>  verify return:1
>  depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
>  verify return:1
>  depth=0 C = US, ST = Alaska, L = Juneau, O = State of Alaska, CN = 
>  ancds10.state.ak.us
>  verify return:1
>  ---
>  Certificate chain
>   0 s:C = US, ST = Alaska, L = Juneau, O = State of Alaska, CN = 
>  ancds10.state.ak.us
>     i:C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
>     a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>     v:NotBefore: Apr 26 18:06:15 2023 GMT; NotAfter: May 27 18:06:14 
>  2024 GMT
>   1 s:C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
>     i:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
>     a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>     v:NotBefore: Nov 21 00:00:00 2018 GMT; NotAfter: Nov 21 00:00:00 
>  2028 GMT
>   2 s:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
>     i:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
>     a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>     v:NotBefore: Mar 18 10:00:00 2009 GMT; NotAfter: Mar 18 10:00:00 
>  2029 GMT
>  ---
>  Server certificate
>  -----BEGIN CERTIFICATE-----
>  MIIGijCCBXKgAwIBAgIMfqUEla3ttBPK/lvlMA0GCSqGSIb3DQEBCwUAMFAxCzAJ
>  BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSYwJAYDVQQDEx1H
>  bG9iYWxTaWduIFJTQSBPViBTU0wgQ0EgMjAxODAeFw0yMzA0MjYxODA2MTVaFw0y
>  NDA1MjcxODA2MTRaMGcxCzAJBgNVBAYTAlVTMQ8wDQYDVQQIEwZBbGFza2ExDzAN
>  BgNVBAcTBkp1bmVhdTEYMBYGA1UEChMPU3RhdGUgb2YgQWxhc2thMRwwGgYDVQQD
>  ExNhbmNkczEwLnN0YXRlLmFrLnVzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
>  CgKCAQEA12s9pW28BNfMPMUdV54DFGg7EmJv7pcmYhnOvq0vqQ845tEillOHptUj
>  muwVOgj8Dcl+PPiDHXeggwKdMA9253Pov7eVGzKfmNN1IwSmOZYKaNLKy1CNQS13
>  eD0Wov0+yq35CqRHWwsl8+7Og56IfPXSmmRQPp21VBC//qkcBezomtTaSSzeE1op
>  248cN8H0wjL0gsPdujzrJmr7xP1gNT4gZQVkNlEAo8hJ3IxvSPvJ+E24FJwMixVb
>  ICUz/crjRXG9nSSudP/225GxaaG3QPOSzOIZD4sT+Pt7lxmQU1syTChd5SHVK1AS
>  WW4I2z1j68/o/ujXiqeP4iiMysRzXQIDAQABo4IDSzCCA0cwDgYDVR0PAQH/BAQD
>  AgWgMIGOBggrBgEFBQcBAQSBgTB/MEQGCCsGAQUFBzAChjhodHRwOi8vc2VjdXJl
>  Lmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3JzYW92c3NsY2EyMDE4LmNydDA3Bggr
>  BgEFBQcwAYYraHR0cDovL29jc3AuZ2xvYmFsc2lnbi5jb20vZ3Nyc2FvdnNzbGNh
>  MjAxODBWBgNVHSAETzBNMEEGCSsGAQQBoDIBFDA0MDIGCCsGAQUFBwIBFiZodHRw
>  czovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAIBgZngQwBAgIwCQYD
>  VR0TBAIwADA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24u
>  Y29tL2dzcnNhb3Zzc2xjYTIwMTguY3JsMB4GA1UdEQQXMBWCE2FuY2RzMTAuc3Rh
>  dGUuYWsudXMwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMB8GA1UdIwQY
>  MBaAFPjvf/LNeGeo3m+PJI2I8YcDArPrMB0GA1UdDgQWBBQ7Sj3cl8+m/NHTW2Gs
>  QN+x7P7iMTCCAX8GCisGAQQB1nkCBAIEggFvBIIBawFpAHYAc9meiRtMlnigIH1H
>  neayxhzQUV5xGSqMa4AQesF3crUAAAGHvr64EQAABAMARzBFAiBQcBIdszriaxKs
>  vUFlLbKEH4jRYQoKwWjWX7sKIJRn2AIhAJ54vIDKjHY+si3R6qKS/xKhHUWASU4l
>  YKxu/GPB+Z22AHYA7s3QZNXbGs7FXLedtM0TojKHRny87N7DUUhZRnEftZsAAAGH
>  vr65OAAABAMARzBFAiBFFZn7eXA4dcDwX4+DbuHqMgtFSqGWcb18/kNymrcXzAIh
>  AI1RfNaDFrbkPE2l/xc/Rj9C6zI4BvlGpcyw7CI+qAB3AHcA2ra/az+1tiKfm8K7
>  XGvocJFxbLtRhIU0vaQ9MEjX+6sAAAGHvr64vwAABAMASDBGAiEAjTr0QpjbfuZw
>  kH1C6/rvfI8vcuZsMijy3cByBjpiO4ACIQDYFzAcyjiG+8WA0KpM1roXLFZp/GXf
>  8hJP+yYVvKVtXzANBgkqhkiG9w0BAQsFAAOCAQEAld/5Th8eHwDUO273c0ISRWfI
>  ts1j/AzyhbKhhKJI/CuALjB34jsynQoqDOS4LevMsVwftGcw0LYzTNDyKaKtUKb5
>  Uj5El1dUdhne2Je+5jKu6lOeCvM5HZg/kEBdb5JRsl1GQxvnxlgEMq+kfFaphUAj
>  3u+zVkJsdbMk6mUBy8+7+NZM7l5c1QiXbFMP/VGh3u3fgVOgcLUuKMZaHa9UbhUq
>  mS6nOmmuVE9xNBgyCYfS2Fwrp+2j5zktFBzoxe+L8i37DVp83GKZQZxx5mOCC28J
>  YN57RNh3T7i+nDsGRVoVp28b2SmDKTh20tOYMs89khe0npancuIl7rklo+BlSg==
>  -----END CERTIFICATE-----
>  subject=C = US, ST = Alaska, L = Juneau, O = State of Alaska, CN = 
>  ancds10.state.ak.us
>  issuer=C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
>  ---
>  No client certificate CA names sent
>  Peer signing digest: SHA256
>  Peer signature type: RSA-PSS
>  Server Temp Key: X25519, 253 bits
>  ---
>  SSL handshake has read 4159 bytes and written 387 bytes
>  Verification: OK
>  ---
>  New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
>  Server public key is 2048 bit
>  Secure Renegotiation IS NOT supported
>  Compression: NONE
>  Expansion: NONE
>  No ALPN negotiated
>  Early data was not sent
>  Verify return code: 0 (ok)
>  ---
>  DONE 

It looks to me like that certificate is signed by the certs included in 
the list of ca-certs shown with dsconf.

But when I try to establish a replication agreement (#1 as the 
supplier/#3 as the consumer), I get the following in the error log:

>  slapi_ldap_bind - Could not send bind request for id [cn=replication
>
>  manager,cn=config] authentication mechanism [SIMPLE]: error -1 (Can't 
>  contact LDAP server), system error -5987 (Invalid function argument.), 
>  network error 0 (Unknown error, host "ancds10.state.ak.us:636")
>
>  NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=DS11-ancds10" 
>  (ancds10:636) - Replication bind with SIMPLE auth failed: LDAP error 
>  -1 (Can't contact LDAP server) (error:1416F086:SSL 
>  routines:tls_process_server_certificate:certificate verify failed 
>  (unable to get issuer certificate)) 
That says to me that instance #1 is unable to validate the certificate 
being offered by instance #3

But if I define #2 as the supplier, the replication works just fine to 
#3 . . and dsconf on instance #2 shows exactly the same ca-certs list as 
on #1

I can't figure out what I'm missing.


--
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

On 4/26/2023 12:43 PM, John Thurston 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.
>

[Marc Sauton]

the error message
NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=DS11-ancds10"
(ancds10:636) - Replication bind with SIMPLE auth failed: LDAP error -1
(Can't contact LDAP server) (error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify failed (unable
to get issuer certificate))

seems to indicate the LDAP service on the system trying to connect
to ancds10:636 does not trust the issuer of the SSL server certificate
installed for ancds10:636

a test command can be a LDAP search from DS11 trying to reach to ancds10:636
ldapsearch -LLLxD "cn=directory manager" -W -H ldaps://ancds10:636 -s base
-b "" vendorVersion

Thanks,
M.


On Fri, May 19, 2023 at 4:22 PM John Thurston <john.thurston(a)alaska.gov&gt;
wrote:

>  Revisiting this problem of replication and certificates. Thank you
> Marc
>  Sauton for pointing out the 'dsconf' command to spill the ca-cert list.
>
>  The synopsis is: instance #1 can replicate with instance #3 when #3 has a
>  GlobalSign cert, but not when #3 has a Let's Encrypt cert. Instance #2 has
>  no such problem replicating.
>
>  (All instances are running 1.4.4.17 B2021.280.1354 on CentOS)
>
>  On instance #1 (and on instance #2), when we use dsconf to ask about the
>  ca-certificate list, we get:
>
>  Certificate Name: GlobalSign Root R3
>  Subject DN: CN=GlobalSign,O=GlobalSign,OU=GlobalSign Root CA - R3
>  Issuer DN: CN=GlobalSign,O=GlobalSign,OU=GlobalSign Root CA - R3
>  Expires: 2029-03-18 10:00:00
>  Trust Flags: CT,,
>
>  Certificate Name: GlobalSign RSA Organization Validation CA - 2018
>  Subject DN: CN=GlobalSign RSA OV SSL CA 2018,O=GlobalSign nv-sa,C=BE
>  Issuer DN: CN=GlobalSign,O=GlobalSign,OU=GlobalSign Root CA - R3
>  Expires: 2028-11-21 00:00:00
>  Trust Flags: CT,,
>
>  Certificate Name: Lets Encrypt Top
>  Subject DN: CN=ISRG Root X1,O=Internet Security Research Group,C=US
>  Issuer DN: CN=DST Root CA X3,O=Digital Signature Trust Co.
>  Expires: 2024-09-30 18:14:03
>  Trust Flags: CT,,
>
>  Certificate Name: Lets Encrypt Intermediate
>  Subject DN: CN=R3,O=Let's Encrypt,C=US
>  Issuer DN: CN=ISRG Root X1,O=Internet Security Research Group,C=US
>  Expires: 2025-09-15 16:00:00
>  Trust Flags: CT,,
>
>
>  On instance #3, when a GlobalSign cert is installed and port 636 is
>  queried with openssl s_client:
>
>  CONNECTED(00000003)
>  depth=2 OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
>  verify return:1
>  depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
>  verify return:1
>  depth=0 C = US, ST = Alaska, L = Juneau, O = State of Alaska, CN =
>  ancds10.state.ak.us
>  verify return:1
>  ---
>  Certificate chain
>   0 s:C = US, ST = Alaska, L = Juneau, O = State of Alaska, CN =
>  ancds10.state.ak.us
>     i:C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
>     a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>     v:NotBefore: Apr 26 18:06:15 2023 GMT; NotAfter: May 27 18:06:14 2024
>  GMT
>   1 s:C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
>     i:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
>     a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>     v:NotBefore: Nov 21 00:00:00 2018 GMT; NotAfter: Nov 21 00:00:00 2028
>  GMT
>   2 s:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
>     i:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
>     a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>     v:NotBefore: Mar 18 10:00:00 2009 GMT; NotAfter: Mar 18 10:00:00 2029
>  GMT
>  ---
>  Server certificate
>  -----BEGIN CERTIFICATE-----
>  MIIGijCCBXKgAwIBAgIMfqUEla3ttBPK/lvlMA0GCSqGSIb3DQEBCwUAMFAxCzAJ
>  BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSYwJAYDVQQDEx1H
>  bG9iYWxTaWduIFJTQSBPViBTU0wgQ0EgMjAxODAeFw0yMzA0MjYxODA2MTVaFw0y
>  NDA1MjcxODA2MTRaMGcxCzAJBgNVBAYTAlVTMQ8wDQYDVQQIEwZBbGFza2ExDzAN
>  BgNVBAcTBkp1bmVhdTEYMBYGA1UEChMPU3RhdGUgb2YgQWxhc2thMRwwGgYDVQQD
>  ExNhbmNkczEwLnN0YXRlLmFrLnVzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
>  CgKCAQEA12s9pW28BNfMPMUdV54DFGg7EmJv7pcmYhnOvq0vqQ845tEillOHptUj
>  muwVOgj8Dcl+PPiDHXeggwKdMA9253Pov7eVGzKfmNN1IwSmOZYKaNLKy1CNQS13
>  eD0Wov0+yq35CqRHWwsl8+7Og56IfPXSmmRQPp21VBC//qkcBezomtTaSSzeE1op
>  248cN8H0wjL0gsPdujzrJmr7xP1gNT4gZQVkNlEAo8hJ3IxvSPvJ+E24FJwMixVb
>  ICUz/crjRXG9nSSudP/225GxaaG3QPOSzOIZD4sT+Pt7lxmQU1syTChd5SHVK1AS
>  WW4I2z1j68/o/ujXiqeP4iiMysRzXQIDAQABo4IDSzCCA0cwDgYDVR0PAQH/BAQD
>  AgWgMIGOBggrBgEFBQcBAQSBgTB/MEQGCCsGAQUFBzAChjhodHRwOi8vc2VjdXJl
>  Lmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3JzYW92c3NsY2EyMDE4LmNydDA3Bggr
>  BgEFBQcwAYYraHR0cDovL29jc3AuZ2xvYmFsc2lnbi5jb20vZ3Nyc2FvdnNzbGNh
>  MjAxODBWBgNVHSAETzBNMEEGCSsGAQQBoDIBFDA0MDIGCCsGAQUFBwIBFiZodHRw
>  czovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAIBgZngQwBAgIwCQYD
>  VR0TBAIwADA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24u
>  Y29tL2dzcnNhb3Zzc2xjYTIwMTguY3JsMB4GA1UdEQQXMBWCE2FuY2RzMTAuc3Rh
>  dGUuYWsudXMwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMB8GA1UdIwQY
>  MBaAFPjvf/LNeGeo3m+PJI2I8YcDArPrMB0GA1UdDgQWBBQ7Sj3cl8+m/NHTW2Gs
>  QN+x7P7iMTCCAX8GCisGAQQB1nkCBAIEggFvBIIBawFpAHYAc9meiRtMlnigIH1H
>  neayxhzQUV5xGSqMa4AQesF3crUAAAGHvr64EQAABAMARzBFAiBQcBIdszriaxKs
>  vUFlLbKEH4jRYQoKwWjWX7sKIJRn2AIhAJ54vIDKjHY+si3R6qKS/xKhHUWASU4l
>  YKxu/GPB+Z22AHYA7s3QZNXbGs7FXLedtM0TojKHRny87N7DUUhZRnEftZsAAAGH
>  vr65OAAABAMARzBFAiBFFZn7eXA4dcDwX4+DbuHqMgtFSqGWcb18/kNymrcXzAIh
>  AI1RfNaDFrbkPE2l/xc/Rj9C6zI4BvlGpcyw7CI+qAB3AHcA2ra/az+1tiKfm8K7
>  XGvocJFxbLtRhIU0vaQ9MEjX+6sAAAGHvr64vwAABAMASDBGAiEAjTr0QpjbfuZw
>  kH1C6/rvfI8vcuZsMijy3cByBjpiO4ACIQDYFzAcyjiG+8WA0KpM1roXLFZp/GXf
>  8hJP+yYVvKVtXzANBgkqhkiG9w0BAQsFAAOCAQEAld/5Th8eHwDUO273c0ISRWfI
>  ts1j/AzyhbKhhKJI/CuALjB34jsynQoqDOS4LevMsVwftGcw0LYzTNDyKaKtUKb5
>  Uj5El1dUdhne2Je+5jKu6lOeCvM5HZg/kEBdb5JRsl1GQxvnxlgEMq+kfFaphUAj
>  3u+zVkJsdbMk6mUBy8+7+NZM7l5c1QiXbFMP/VGh3u3fgVOgcLUuKMZaHa9UbhUq
>  mS6nOmmuVE9xNBgyCYfS2Fwrp+2j5zktFBzoxe+L8i37DVp83GKZQZxx5mOCC28J
>  YN57RNh3T7i+nDsGRVoVp28b2SmDKTh20tOYMs89khe0npancuIl7rklo+BlSg==
>  -----END CERTIFICATE-----
>  subject=C = US, ST = Alaska, L = Juneau, O = State of Alaska, CN =
>  ancds10.state.ak.us
>  issuer=C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
>  ---
>  No client certificate CA names sent
>  Peer signing digest: SHA256
>  Peer signature type: RSA-PSS
>  Server Temp Key: X25519, 253 bits
>  ---
>  SSL handshake has read 4159 bytes and written 387 bytes
>  Verification: OK
>  ---
>  New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
>  Server public key is 2048 bit
>  Secure Renegotiation IS NOT supported
>  Compression: NONE
>  Expansion: NONE
>  No ALPN negotiated
>  Early data was not sent
>  Verify return code: 0 (ok)
>  ---
>  DONE
>
>
>  On instance #3 when a Let's Encrypt cert is installed and port 636 queried
>  with openssl s_client:
>
>
>  CONNECTED(00000003)
>  depth=2 OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
>  verify return:1
>  depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
>  verify return:1
>  depth=0 C = US, ST = Alaska, L = Juneau, O = State of Alaska, CN =
>  ancds10.state.ak.us
>  verify return:1
>  ---
>  Certificate chain
>   0 s:C = US, ST = Alaska, L = Juneau, O = State of Alaska, CN =
>  ancds10.state.ak.us
>     i:C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
>     a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>     v:NotBefore: Apr 26 18:06:15 2023 GMT; NotAfter: May 27 18:06:14 2024
>  GMT
>   1 s:C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
>     i:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
>     a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>     v:NotBefore: Nov 21 00:00:00 2018 GMT; NotAfter: Nov 21 00:00:00 2028
>  GMT
>   2 s:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
>     i:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign
>     a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>     v:NotBefore: Mar 18 10:00:00 2009 GMT; NotAfter: Mar 18 10:00:00 2029
>  GMT
>  ---
>  Server certificate
>  -----BEGIN CERTIFICATE-----
>  MIIGijCCBXKgAwIBAgIMfqUEla3ttBPK/lvlMA0GCSqGSIb3DQEBCwUAMFAxCzAJ
>  BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSYwJAYDVQQDEx1H
>  bG9iYWxTaWduIFJTQSBPViBTU0wgQ0EgMjAxODAeFw0yMzA0MjYxODA2MTVaFw0y
>  NDA1MjcxODA2MTRaMGcxCzAJBgNVBAYTAlVTMQ8wDQYDVQQIEwZBbGFza2ExDzAN
>  BgNVBAcTBkp1bmVhdTEYMBYGA1UEChMPU3RhdGUgb2YgQWxhc2thMRwwGgYDVQQD
>  ExNhbmNkczEwLnN0YXRlLmFrLnVzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
>  CgKCAQEA12s9pW28BNfMPMUdV54DFGg7EmJv7pcmYhnOvq0vqQ845tEillOHptUj
>  muwVOgj8Dcl+PPiDHXeggwKdMA9253Pov7eVGzKfmNN1IwSmOZYKaNLKy1CNQS13
>  eD0Wov0+yq35CqRHWwsl8+7Og56IfPXSmmRQPp21VBC//qkcBezomtTaSSzeE1op
>  248cN8H0wjL0gsPdujzrJmr7xP1gNT4gZQVkNlEAo8hJ3IxvSPvJ+E24FJwMixVb
>  ICUz/crjRXG9nSSudP/225GxaaG3QPOSzOIZD4sT+Pt7lxmQU1syTChd5SHVK1AS
>  WW4I2z1j68/o/ujXiqeP4iiMysRzXQIDAQABo4IDSzCCA0cwDgYDVR0PAQH/BAQD
>  AgWgMIGOBggrBgEFBQcBAQSBgTB/MEQGCCsGAQUFBzAChjhodHRwOi8vc2VjdXJl
>  Lmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3JzYW92c3NsY2EyMDE4LmNydDA3Bggr
>  BgEFBQcwAYYraHR0cDovL29jc3AuZ2xvYmFsc2lnbi5jb20vZ3Nyc2FvdnNzbGNh
>  MjAxODBWBgNVHSAETzBNMEEGCSsGAQQBoDIBFDA0MDIGCCsGAQUFBwIBFiZodHRw
>  czovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAIBgZngQwBAgIwCQYD
>  VR0TBAIwADA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24u
>  Y29tL2dzcnNhb3Zzc2xjYTIwMTguY3JsMB4GA1UdEQQXMBWCE2FuY2RzMTAuc3Rh
>  dGUuYWsudXMwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMB8GA1UdIwQY
>  MBaAFPjvf/LNeGeo3m+PJI2I8YcDArPrMB0GA1UdDgQWBBQ7Sj3cl8+m/NHTW2Gs
>  QN+x7P7iMTCCAX8GCisGAQQB1nkCBAIEggFvBIIBawFpAHYAc9meiRtMlnigIH1H
>  neayxhzQUV5xGSqMa4AQesF3crUAAAGHvr64EQAABAMARzBFAiBQcBIdszriaxKs
>  vUFlLbKEH4jRYQoKwWjWX7sKIJRn2AIhAJ54vIDKjHY+si3R6qKS/xKhHUWASU4l
>  YKxu/GPB+Z22AHYA7s3QZNXbGs7FXLedtM0TojKHRny87N7DUUhZRnEftZsAAAGH
>  vr65OAAABAMARzBFAiBFFZn7eXA4dcDwX4+DbuHqMgtFSqGWcb18/kNymrcXzAIh
>  AI1RfNaDFrbkPE2l/xc/Rj9C6zI4BvlGpcyw7CI+qAB3AHcA2ra/az+1tiKfm8K7
>  XGvocJFxbLtRhIU0vaQ9MEjX+6sAAAGHvr64vwAABAMASDBGAiEAjTr0QpjbfuZw
>  kH1C6/rvfI8vcuZsMijy3cByBjpiO4ACIQDYFzAcyjiG+8WA0KpM1roXLFZp/GXf
>  8hJP+yYVvKVtXzANBgkqhkiG9w0BAQsFAAOCAQEAld/5Th8eHwDUO273c0ISRWfI
>  ts1j/AzyhbKhhKJI/CuALjB34jsynQoqDOS4LevMsVwftGcw0LYzTNDyKaKtUKb5
>  Uj5El1dUdhne2Je+5jKu6lOeCvM5HZg/kEBdb5JRsl1GQxvnxlgEMq+kfFaphUAj
>  3u+zVkJsdbMk6mUBy8+7+NZM7l5c1QiXbFMP/VGh3u3fgVOgcLUuKMZaHa9UbhUq
>  mS6nOmmuVE9xNBgyCYfS2Fwrp+2j5zktFBzoxe+L8i37DVp83GKZQZxx5mOCC28J
>  YN57RNh3T7i+nDsGRVoVp28b2SmDKTh20tOYMs89khe0npancuIl7rklo+BlSg==
>  -----END CERTIFICATE-----
>  subject=C = US, ST = Alaska, L = Juneau, O = State of Alaska, CN =
>  ancds10.state.ak.us
>  issuer=C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018
>  ---
>  No client certificate CA names sent
>  Peer signing digest: SHA256
>  Peer signature type: RSA-PSS
>  Server Temp Key: X25519, 253 bits
>  ---
>  SSL handshake has read 4159 bytes and written 387 bytes
>  Verification: OK
>  ---
>  New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
>  Server public key is 2048 bit
>  Secure Renegotiation IS NOT supported
>  Compression: NONE
>  Expansion: NONE
>  No ALPN negotiated
>  Early data was not sent
>  Verify return code: 0 (ok)
>  ---
>  DONE
>
>
>  It looks to me like that certificate is signed by the certs included in
>  the list of ca-certs shown with dsconf.
>
>  But when I try to establish a replication agreement (#1 as the supplier/#3
>  as the consumer), I get the following in the error log:
>
>  slapi_ldap_bind - Could not send bind request for id [cn=replication
>  manager,cn=config] authentication mechanism [SIMPLE]: error -1 (Can't
>  contact LDAP server), system error -5987 (Invalid function argument.),
>  network error 0 (Unknown error, host "ancds10.state.ak.us:636")
>
>  NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=DS11-ancds10"
>  (ancds10:636) - Replication bind with SIMPLE auth failed: LDAP error -1
>  (Can't contact LDAP server) (error:1416F086:SSL
>  routines:tls_process_server_certificate:certificate verify failed (unable
>  to get issuer certificate))
>
>  That says to me that instance #1 is unable to validate the certificate
>  being offered by instance #3
>
>  But if I define #2 as the supplier, the replication works just fine to #3
>  . . and dsconf on instance #2 shows exactly the same ca-certs list as on #1
>
>  I can't figure out what I'm missing.
>
>
>  --
>  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
>
>  On 4/26/2023 12:43 PM, John Thurston 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.
>
>  _______________________________________________
>  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
>

[Jakob Moser]

A similar problem seems to have been posted on Server Fault:

https://serverfault.com/questions/1131289/ldap-replication-to-server-with...

It uses Implict TLS instead of STARTTLS, but apart from that shows the same symptoms, I
believe.
Sadly, Server Fault has so far also been unable to figure out what the problem is.

Regards
Jakob

[Marc Sauton]

The "unable to get issuer certificate" part really means it, and this has
been quite a common issue for either LDAPS or STARTTLS, about a missing
cert or missing trust flag in the PKI chain of trust of the issuer, and it
is usually solved by a "trust anchor" command for the system, or a certutil
-A in the LDAP NSS db directory, .
For the operating system point of view with a LDAP client,  a"-d 4" added
to ldapsearch, or a strace could show in which directory or key store the
issuer is not trusted.
Does a "trust anchor some.ca.cert.pem.txt" help?
Thanks,
M.

On Tue, May 23, 2023 at 3:30 AM Jakob Moser <lms0m27i(a)duck.com&gt; wrote:

>  A similar problem seems to have been posted on Server Fault:
>
>
>
> https://serverfault.com/questions/1131289/ldap-replication-to-server-with...
>
>  It uses Implict TLS instead of STARTTLS, but apart from that shows the
>  same symptoms, I believe.
>  Sadly, Server Fault has so far also been unable to figure out what the
>  problem is.
>
>  Regards
>  Jakob
>  _______________________________________________
>  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
>

[Jakob Moser]

Sadly, the problem persists after executing "trust anchor <ca>.pem" for
both the ISRG Root X1 and Let's Encrypt R3 cert files as extracted from the
fullchain.pem provided by Certbot.

Regards
Jakob

[Jakob Moser]

Actually, trusting the certificate made everything worse. 

# trust list | grep ISRG\ Root\ X1

yielded the same certificate twice, and the supplier was then unable to connect to the
consumer (or itself), yielding "unable to get issuer certificate" (so not only
when replicating, but also when using ldapsearch etc.).

To fix this, I needed to execute:

# rm /etc/pki/ca-trust/source/*.p11-kitt
# update-ca-trust

Now, I am again faced with the original problem (but luckily, only that one).

[Jakob Moser]

Could it be a programming error in 389-ds-base?

After all, the error message we're getting is:

[06/Jun/2023:14:41:05.346079522 +0200] - ERR - slapi_ldap_bind - Could not send bind
request for id [cn=replication manager,cn=config] authentication mechanism [SIMPLE]: error
-1 (Can't contact LDAP server), system error -5987 (Invalid function argument.),
network error 0 (Unknown error, host "consumer.mydomain.example:636")

which contains "system error -5987 (Invalid function argument.)". That log seems
to be created by slapi_ldap_bind in file:

https://github.com/389ds/389-ds-base/blob/c6b2236c39e248005fa5ccd3aecdc0d...

which is called by

https://github.com/389ds/389-ds-base/blob/c6b2236c39e248005fa5ccd3aecdc0d...

So could it be that there is a bug in this call (or in the slapi_ldap_bind implementation
itself). Apparently, slapi_ldap_bind seems to be also only called by the replication,
chainingdb and dna plugins, so maybe that is the reason why the error doesn't occur
anywhere else.

Kind regards
Jakob