[389-users] Re: SSL replication error

[Michal Medvecky]

So I finally made it work.

I tried with F28 and I got the error message "system error -8157 (Certificate 
extension not found.)”. After some investigations, I realized that one of certs 
in my certificate chain was incorrectly imported (under wrong nickname, thus 
not imported at all).

After fixing that, it worked.

Then, I tried the same setup with Ubuntu 18.04 (389-ds 1.3.7.10, ldap-utils 
2.4.45+dfsg-1ubuntu1) and it works.

It’s still broken with 16.04 though (389 1.3.4.9-1, ldap-utils 
2.4.42+dfsg-2ubuntu3.2)

Thanks for all your effort,

Michal

> On 5 Jun 2018, at 15:41, Mark Reynolds  wrote:
> 
> What version of openldap is on your system?  There is known issue fixed in 
> openldap-2.4.23-31 and up
> 
> Can you do a ldapsearch from one system to the the other?
> 
> ldapsearch -ZZ -xLLL -h HOST -p PORT -b "" -s base
> 
> Then check the DS access and errors logs.  There should be more info there 
> for the failure.
> 
> I just setup self-signed certs on a F28 and everything works for me (with 
> host name checking set to "on").
> 
> 
> -
> [root@ibm-ls22-04 slapd-localhost]# certutil -d . -L
> 
> Certificate Nickname Trust Attributes
>  
> SSL,S/MIME,JAR/XPI
> 
> CA certificate   CTu,Cu,Cu
> Server-Cert  u,u,Pu
> --
> 
> Can you run "certutil -L" on your cert db?  Do your trust attrs match mine?
> 
> Maybe your cert is missing the basic constraints extension (See my CA cert 
> for an example)?
> 
> 
> 
> Here is my info:
> 
> 
> Server Cert:
> 
> 
> # certutil -d /etc/dirsrv/slapd-HOST -L -n Server-Cert
> 
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number: 1001 (0x3e9)
> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
> Issuer: "CN=CAcert"
> Validity:
> Not Before: Tue Jun 05 11:19:13 2018
> Not After : Mon Jun 05 11:19:13 2028
> Subject: "CN=ibm-ls22-04.rhts.eng.brq.redhat.com,OU=389 Directory 
> Server"
> Subject Public Key Info:
> Public Key Algorithm: PKCS #1 RSA Encryption
> RSA Public Key:
> Modulus:
> cb:16:8f:2d:72:66:b3:35:83:35:ce:df:48:b1:82:cd:
> a3:ee:95:5d:a5:21:62:ae:a9:55:52:bb:f3:03:5c:cf:
> f0:51:64:83:17:44:1a:58:70:e7:57:9b:5d:3e:6d:0a:
> f4:a2:96:28:10:82:03:9c:4a:5c:a1:cf:27:5f:97:62:
> d6:c3:57:5f:0d:ca:c1:62:41:43:47:59:5c:b0:31:c6:
> f7:fe:18:d9:2d:14:ac:08:c8:82:a3:97:66:bf:b5:6d:
> d9:99:9a:7a:19:4e:94:01:52:b5:02:2f:46:70:08:25:
> 81:7f:82:13:27:95:04:04:1f:2b:4d:21:f9:3e:1c:3d:
> 19:82:de:d3:8e:7b:80:5c:ff:12:42:19:fa:60:e6:c1:
> d4:62:8b:00:21:5a:91:e6:12:b7:82:67:3c:14:18:59:
> 43:4d:9d:cb:f8:d7:85:a3:26:f3:19:68:96:47:38:c3:
> c9:c2:7a:9d:0d:b6:86:a4:f7:bd:7e:f8:5e:a5:a3:b1:
> 82:f6:b0:f2:e0:18:83:90:95:20:52:5b:73:d6:6d:70:
> 8d:ad:55:79:43:ba:04:21:aa:e3:e8:9b:24:81:5d:f3:
> dd:8d:e0:2c:8f:c9:28:ec:ff:24:d4:ac:85:d1:2b:4e:
> 03:9d:f8:77:4f:09:88:25:65:27:98:55:a2:30:35:65
> Exponent: 65537 (0x10001)
> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
> Signature:
> 4a:06:4d:21:b4:be:fe:5f:47:3d:6f:0d:e6:8d:10:52:
> 0c:74:61:33:e5:f2:4f:68:13:7f:e4:b4:0b:b2:39:52:
> 79:ca:6e:1c:ce:df:02:a1:01:3b:0d:cd:39:d2:aa:42:
> bc:17:2c:29:bf:08:25:dd:3e:8c:24:6b:80:bd:59:f9:
> 0b:91:2b:f7:41:81:4f:42:7f:1e:30:b5:4e:7b:47:67:
> 08:58:87:0d:93:76:9a:04:d0:ee:fd:f5:9f:b7:2c:9e:
> 1e:a5:6f:69:4d:d9:3c:a6:cd:5f:a6:7d:b9:9a:cc:43:
> ef:ab:1d:38:b1:9f:33:cd:2e:84:5a:96:38:9d:99:a6:
> 1a:29:ec:f2:16:2f:e7:a0:8f:56:6d:a5:62:b2:59:3a:
> b4:2c:d4:c8:b3:30:1d:23:f6:0a:e7:6d:9b:e1:d5:5c:
> c7:27:36:52:33:88:75:1a:be:0d:8e:70:fc:25:75:2f:
> 6a:70:d4:36:81:81:87:ec:ea:53:f0:22:8f:e0:6c:26:
> 40:54:ec:29:b9:c9:e3:73:3c:d9:cd:50:b5:45:51:fd:
> 1f:cb:71:e9:ae:01:65:31:f5:b1:b7:13:3d:63:b7:20:
> 1c:72:4c:2d:50:2a:be:f7:77:e2:fb:0f:09:59:4a:0c:
> ba:83:a6:72:d4:96:77:36:28:bf:56:18:2c:e9:75:6d
> Fingerprint (SHA-256):
> 
> D9:DB:31:8F:A7:57:03:8F:28:9D:53:C1:32:AE:28:B3:02:F5:CE:E7:72:62:A8:BF:DD:92:39:A9:FD:98:05:C0
> Fingerprint (SHA1):
> 85:C4:0B:3F:FC:A3:57:FB:90:D5:BE:B7:E5:8A:9A:B6:48:CB:63:4C
> 
> Mozilla-CA-Policy: false (attribute missing)
> Certificate Trust Flags:
> SSL

[389-users] Re: SSL replication error

[Mark Reynolds]

What version of openldap is on your system?  There is known issue fixed 
in openldap-2.4.23-31 and up


Can you do a ldapsearch from one system to the the other?

ldapsearch -ZZ -xLLL -h HOST -p PORT -b "" -s base

Then check the DS access and errors logs.  There should be more info 
there for the failure.



I just setup self-signed certs on a F28 and everything works for me 
(with host name checking set to "on").



-
[root@ibm-ls22-04 slapd-localhost]# certutil -d . -L

Certificate Nickname Trust 
Attributes

SSL,S/MIME,JAR/XPI

CA certificate CTu,Cu,Cu
Server-Cert  u,u,Pu
--

Can you run "certutil -L" on your cert db?  Do your trust attrs match mine?

Maybe your cert is missing the basic constraints extension (See my CA 
cert for an example)?




Here is my info:


Server Cert:


# certutil -d /etc/dirsrv/slapd-HOST -L -n Server-Cert

Certificate:
    Data:
    Version: 3 (0x2)
    Serial Number: 1001 (0x3e9)
    Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
    Issuer: "CN=CAcert"
    Validity:
    Not Before: Tue Jun 05 11:19:13 2018
    Not After : Mon Jun 05 11:19:13 2028
    Subject: "CN=ibm-ls22-04.rhts.eng.brq.redhat.com,OU=389 
Directory Server"

    Subject Public Key Info:
    Public Key Algorithm: PKCS #1 RSA Encryption
    RSA Public Key:
    Modulus:
    cb:16:8f:2d:72:66:b3:35:83:35:ce:df:48:b1:82:cd:
    a3:ee:95:5d:a5:21:62:ae:a9:55:52:bb:f3:03:5c:cf:
    f0:51:64:83:17:44:1a:58:70:e7:57:9b:5d:3e:6d:0a:
    f4:a2:96:28:10:82:03:9c:4a:5c:a1:cf:27:5f:97:62:
    d6:c3:57:5f:0d:ca:c1:62:41:43:47:59:5c:b0:31:c6:
    f7:fe:18:d9:2d:14:ac:08:c8:82:a3:97:66:bf:b5:6d:
    d9:99:9a:7a:19:4e:94:01:52:b5:02:2f:46:70:08:25:
    81:7f:82:13:27:95:04:04:1f:2b:4d:21:f9:3e:1c:3d:
    19:82:de:d3:8e:7b:80:5c:ff:12:42:19:fa:60:e6:c1:
    d4:62:8b:00:21:5a:91:e6:12:b7:82:67:3c:14:18:59:
    43:4d:9d:cb:f8:d7:85:a3:26:f3:19:68:96:47:38:c3:
    c9:c2:7a:9d:0d:b6:86:a4:f7:bd:7e:f8:5e:a5:a3:b1:
    82:f6:b0:f2:e0:18:83:90:95:20:52:5b:73:d6:6d:70:
    8d:ad:55:79:43:ba:04:21:aa:e3:e8:9b:24:81:5d:f3:
    dd:8d:e0:2c:8f:c9:28:ec:ff:24:d4:ac:85:d1:2b:4e:
    03:9d:f8:77:4f:09:88:25:65:27:98:55:a2:30:35:65
    Exponent: 65537 (0x10001)
    Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
    Signature:
    4a:06:4d:21:b4:be:fe:5f:47:3d:6f:0d:e6:8d:10:52:
    0c:74:61:33:e5:f2:4f:68:13:7f:e4:b4:0b:b2:39:52:
    79:ca:6e:1c:ce:df:02:a1:01:3b:0d:cd:39:d2:aa:42:
    bc:17:2c:29:bf:08:25:dd:3e:8c:24:6b:80:bd:59:f9:
    0b:91:2b:f7:41:81:4f:42:7f:1e:30:b5:4e:7b:47:67:
    08:58:87:0d:93:76:9a:04:d0:ee:fd:f5:9f:b7:2c:9e:
    1e:a5:6f:69:4d:d9:3c:a6:cd:5f:a6:7d:b9:9a:cc:43:
    ef:ab:1d:38:b1:9f:33:cd:2e:84:5a:96:38:9d:99:a6:
    1a:29:ec:f2:16:2f:e7:a0:8f:56:6d:a5:62:b2:59:3a:
    b4:2c:d4:c8:b3:30:1d:23:f6:0a:e7:6d:9b:e1:d5:5c:
    c7:27:36:52:33:88:75:1a:be:0d:8e:70:fc:25:75:2f:
    6a:70:d4:36:81:81:87:ec:ea:53:f0:22:8f:e0:6c:26:
    40:54:ec:29:b9:c9:e3:73:3c:d9:cd:50:b5:45:51:fd:
    1f:cb:71:e9:ae:01:65:31:f5:b1:b7:13:3d:63:b7:20:
    1c:72:4c:2d:50:2a:be:f7:77:e2:fb:0f:09:59:4a:0c:
    ba:83:a6:72:d4:96:77:36:28:bf:56:18:2c:e9:75:6d
    Fingerprint (SHA-256):
D9:DB:31:8F:A7:57:03:8F:28:9D:53:C1:32:AE:28:B3:02:F5:CE:E7:72:62:A8:BF:DD:92:39:A9:FD:98:05:C0
    Fingerprint (SHA1):
    85:C4:0B:3F:FC:A3:57:FB:90:D5:BE:B7:E5:8A:9A:B6:48:CB:63:4C

    Mozilla-CA-Policy: false (attribute missing)
    Certificate Trust Flags:
    SSL Flags:
    User
    Email Flags:
    User
    Object Signing Flags:
    Terminal Record
    Trusted
    User




CA Cert:
=

Certificate:
    Data:
    Version: 3 (0x2)
    Serial Number: 1000 (0x3e8)
    Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
    Issuer: "CN=CAcert"
    Validity:
    Not Before: Tue Jun 05 11:19:12 2018
    Not After : Mon Jun 05 11:19:12 2028
    Subject: "CN=CAcert"
    Subject Public Key Info:
    Public Key Algorithm: PKCS #1 RSA Encryption
    RSA Public Key:
    Modulus:
    df:92:6d:6c:82:26:6b:5d:f3:09:d8:68:30:e6:79:24:
    ab:34:ec:33:ed:a5:cc:c4:22:c3:ca:d7:b8:3e:cf:27:
    70:66:02:37:e5:0f:44:e7:8c:6a:81:44:63:b1:07:98:
    1c:15:e1:73:2

[389-users] Re: SSL replication error

[Mark Reynolds]

On 05/09/2018 04:59 PM, Michal Medvecky wrote:
>
>> I'm not sure what is wrong/mismatched as it's failing inside of the
>> openldap client library.  I wonder if the cert nickname having the
>> "CN=" in it is a problem?  It shouldn't be, but who knows.
>>
> I tried changing it to “server-cert”, did not help.
>
>> openldap just describes the flag as:
>>
>> | ||LDAPSSL_AUTH_CNCHECK |indicates that you accept the server's
>> certificate only if you trust the CA who issued the certificate and
>> if the value of the cn attribute is the DNS hostname of the server.
>>
>> Under cn=config what is nsslapd-localhost set to?  Is it the correct
>> FQDN?
>
> yes.
>
>> What is in /etc/openldap/ldap.conf?
>
> ?
Do you have this file?  What platform are you running on?  And what
version of 389-ds-base are you using (rpm -qa | grep 389-ds-base)
>
>> There are no messages containing "conn_connect”?
>
> not a single one.
>
>
>
>
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: SSL replication error

[Michal Medvecky]

> I'm not sure what is wrong/mismatched as it's failing inside of the openldap 
> client library.  I wonder if the cert nickname having the "CN=" in it is a 
> problem?  It shouldn't be, but who knows.
> 
I tried changing it to “server-cert”, did not help.

> openldap just describes the flag as:
> 
>  LDAPSSL_AUTH_CNCHECK indicates that you accept the server's certificate 
> only if you trust the CA who issued the certificate and if the value of the 
> cn attribute is the DNS hostname of the server.  <>
> 
> Under cn=config what is nsslapd-localhost set to?  Is it the correct FQDN?

yes.

> What is in /etc/openldap/ldap.conf?

?

> There are no messages containing "conn_connect”?

not a single one.


___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: SSL replication error

[Mark Reynolds]

On 05/09/2018 03:37 PM, Michal Medvecky wrote:
>>>
>> The server uses the openldap client libraries for replication
>> connections.  Setting nsslapd-ssl-check-hostname sets these flags on
>> the connection as follows:
>>
>> For server authentication it sets this flag:
>>
>>     LDAPSSL_AUTH_CNCHECK   --> This checks the hostname in the
>> certificate subject to that of the host
>>  
>> For SSL client auth it sets this flag:
>>
>>     LDAP_OPT_X_TLS_HARD
>
> Okay so it does more than is documented, now I get it.
I'll file a doc bug for this...
>
>> So the issue here is either openldap is not finding the correct
>> hostname, or the hostname in the certificate subject is wrong.
>
> As I stated previously, my domain name and cert is good. Even the
> reverse dns record is correct.
>
> I tried replacing the certificate with an incorrect one (with invalid
> CN) and the error displayed in log is the very same. So yes, it looks
> like “something” does not match (but what?)
I'm not sure what is wrong/mismatched as it's failing inside of the
openldap client library.  I wonder if the cert nickname having the "CN="
in it is a problem?  It shouldn't be, but who knows.

openldap just describes the flag as:

| ||LDAPSSL_AUTH_CNCHECK |indicates that you accept the server's
certificate only if you trust the CA who issued the certificate and if
the value of the cn attribute is the DNS hostname of the server.

Under cn=config what is nsslapd-localhost set to?  Is it the correct FQDN?

What is in /etc/openldap/ldap.conf?
>
> Connecting to ldap server itself works, even openssl s_client verifies
> the server cert ok (including the chain, what was a nice surprise to me).
>
> Just to be clear: I’m using my own root CA, with an intermediate CA
> which issued cert for CN=ldap-master-b01.example.com
>  and
> CN=ldap-master-b02.example.com .
> Both are imported into certstore with nickname “CN=ldap-master-b0[12]”
> (including the “CN=“). 
>
> In cn=RSA,cn=encryption,cn=config, I use
> nsSSLPersonalitySSL='CN=ldap-master-b[01].example.com
> ’.
>
> I tried changing the errorlog-level as you suggested, but I got no
> better message than...
>
> [09/May/2018:21:13:25 +0200] NSMMReplicationPlugin -
> agmt="cn=rw-to-ldap-master-b02.example.com
> " (ldap-master-b02:636):
> binddn = cn=MasterMasterReplicationManager,cn=config,  passwd =
> {AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVGRERBNEJDUXhZamN5WXpNeVppMDNPR00zTXpOaA0KTUMxaE1XTmtabUl5WmkwMVpUVmtOR1l5TlFBQ0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCRDBuaTFJaDRXMmZDcnlqWUtXQmlMRw==}yFb3FVwDwpWKupgUWiS4wg==
> [09/May/2018:21:13:26 +0200] slapi_ldap_bind - Error: could not send
> bind request for id [cn=MasterMasterReplicationManager,cn=config]
> authentication mechanism [SIMPLE]: error -1 (Can't contact LDAP
> server), system error -5987 (Invalid function argument.), network
> error 115 (Operation now in progress, host
> "ldap-master-b02.example.com:636
> ”)
There are no messages containing "conn_connect"?
>
> root@ldap-master-b01:~# host ldap-master-b02.example.com
> 
> ldap-master-b02.example.com  has
> address 100.127.177.145
> root@ldap-master-b01:~# host 100.127.177.145
> 145.177.127.100.in-addr.arpa domain name pointer
> ldap-master-b02.example.com .
>
> root@ldap-master-b02:~# certutil -L -d /etc/dirsrv/nss/ -n
> "CN=ldap-master-b02.example.com
> "|grep Subje
>         Subject: "CN=ldap-master-b02.example.com
> "
>
>
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: SSL replication error

[Michal Medvecky]

>> 
> The server uses the openldap client libraries for replication connections.  
> Setting nsslapd-ssl-check-hostname sets these flags on the connection as 
> follows:
> 
> For server authentication it sets this flag:
> 
> LDAPSSL_AUTH_CNCHECK   --> This checks the hostname in the certificate 
> subject to that of the host
>  
> For SSL client auth it sets this flag:
> 
> LDAP_OPT_X_TLS_HARD

Okay so it does more than is documented, now I get it.

> So the issue here is either openldap is not finding the correct hostname, or 
> the hostname in the certificate subject is wrong.

As I stated previously, my domain name and cert is good. Even the reverse dns 
record is correct.

I tried replacing the certificate with an incorrect one (with invalid CN) and 
the error displayed in log is the very same. So yes, it looks like “something” 
does not match (but what?)

Connecting to ldap server itself works, even openssl s_client verifies the 
server cert ok (including the chain, what was a nice surprise to me).

Just to be clear: I’m using my own root CA, with an intermediate CA which 
issued cert for CN=ldap-master-b01.example.com and 
CN=ldap-master-b02.example.com . Both are 
imported into certstore with nickname “CN=ldap-master-b0[12]” (including the 
“CN=“). 

In cn=RSA,cn=encryption,cn=config, I use 
nsSSLPersonalitySSL='CN=ldap-master-b[01].example.com’.

I tried changing the errorlog-level as you suggested, but I got no better 
message than...

[09/May/2018:21:13:25 +0200] NSMMReplicationPlugin - 
agmt="cn=rw-to-ldap-master-b02.example.com" (ldap-master-b02:636): binddn = 
cn=MasterMasterReplicationManager,cn=config,  passwd = 
{AES-TUhNR0NTcUdTSWIzRFFFRkRUQm1NRVVHQ1NxR1NJYjNEUUVGRERBNEJDUXhZamN5WXpNeVppMDNPR00zTXpOaA0KTUMxaE1XTmtabUl5WmkwMVpUVmtOR1l5TlFBQ0FRSUNBU0F3Q2dZSUtvWklodmNOQWdjd0hRWUpZSVpJQVdVRA0KQkFFcUJCRDBuaTFJaDRXMmZDcnlqWUtXQmlMRw==}yFb3FVwDwpWKupgUWiS4wg==
[09/May/2018:21:13:26 +0200] slapi_ldap_bind - Error: could not send bind 
request for id [cn=MasterMasterReplicationManager,cn=config] authentication 
mechanism [SIMPLE]: error -1 (Can't contact LDAP server), system error -5987 
(Invalid function argument.), network error 115 (Operation now in progress, 
host "ldap-master-b02.example.com:636”)

root@ldap-master-b01:~# host ldap-master-b02.example.com
ldap-master-b02.example.com has address 100.127.177.145
root@ldap-master-b01:~# host 100.127.177.145
145.177.127.100.in-addr.arpa domain name pointer ldap-master-b02.example.com.

root@ldap-master-b02:~# certutil -L -d /etc/dirsrv/nss/ -n 
"CN=ldap-master-b02.example.com"|grep Subje
Subject: "CN=ldap-master-b02.example.com"___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: SSL replication error

[Mark Reynolds]

On 05/09/2018 05:56 AM, Michal Medvecky wrote:
>> Under cn=config, what is "nsslapd-ssl-check-hostname" set to?  Try
>> setting it to "off" to see if it makes a difference.
>
> Ok, this “helped”, but I have no idea why?
The server uses the openldap client libraries for replication
connections.  Setting nsslapd-ssl-check-hostname sets these flags on the
connection as follows:

For server authentication it sets this flag:

    LDAPSSL_AUTH_CNCHECK   --> This checks the hostname in the
certificate subject to that of the host
 
For SSL client auth it sets this flag:

    LDAP_OPT_X_TLS_HARD

So the issue here is either openldap is not finding the correct
hostname, or the hostname in the certificate subject is wrong.

To check the subject of the certificate use certutil.  Here is an example:

Get the names of the certificates in the in the security database:

# certutil -L -d /etc/dirsrv/slapd-localhost

Find the server's certificate name (server-cert in this example) and run
the command below:

# certutil -L -d /etc/dirsrv/slapd-localhost -n server-cert | grep Subject

The subject should start with "CN=, ...".  Is this host name
complete and correct?

>
> When googling for ‘nsslapd-ssl-check-hostname’, I found this:
>
> > nsslapd-ssl-check-hostname (Verify Hostname for
> OutboundConnections)Specifies whether an SSL-enabled Directory Server
> (with certificate based client authentication turned on) should verify
> authenticity of a request by matching the hostname against the value
> assigned to the Common Name (CN) attributeof the subject name in the
> certificate being presented. 
>
> Two arguments:
>
> - I’m _not_ using certificate based client authentications
> - my hostnames are valid
>
> What I’m confused with is the error log on ldap-master-b01:
>
> [09/May/2018:11:27:21 +0200] NSMMReplicationPlugin -
> agmt="cn=rw-to-ldap-master-b02.example.com
> " (ldap-master-b02:636):
> Replication bind with SIMPLE auth resumed
> [09/May/2018:11:27:21 +0200] NSMMReplicationPlugin -
> agmt="cn=rw-to-ldap-master-b02.example.com
> " (ldap-master-b02:636):
> Unable to acquire replica: there is no replicated area
> “dc=example,dc=com" on the consumer server. Replication is aborting.

This means you do not have replication setup for that suffix on the
consumer.  Replication will not work until this is done.
> [09/May/2018:11:27:21 +0200] NSMMReplicationPlugin -
> agmt="cn=rw-to-ldap-master-b02.example.com
> " (ldap-master-b02:636):
> Incremental update failed and requires administrator action
> [09/May/2018:11:36:07 +0200] NSMMReplicationPlugin - agmt_delete: begin
> [09/May/2018:11:36:11 +0200] NSMMReplicationPlugin - Beginning total
> update of replica "agmt="cn=rw-to-ldap-master-b02.example.com
> " (ldap-master-b02:636)".
> [09/May/2018:11:36:11 +0200] NSMMReplicationPlugin - Need to create
> replication keep alive entry 
> [09/May/2018:11:36:11 +0200] NSMMReplicationPlugin - add dn: cn=repl
> keep alive 37642,dc=example,dc=com
>
> On the fifth line of the log, you can see “ldap-master-b02:636”
> instead of the full hostname “ldap-master-b02.example.com
> ”, but, as seen in my previous
> e-mail, the nsDS5ReplicaHost points to the full hostname.
This is a red herring, the server prints the hostname not the FQDN just
in the logging.

Mark
>
> Michal

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: SSL replication error

[Mark Reynolds]

On 05/08/2018 04:47 PM, Michal Medvecky wrote:
>
>> On 8 May 2018, at 17:45, Mark Reynolds  wrote:
>>
>>
>>
>> On 05/07/2018 08:00 AM, Michal Medvecky wrote:
>>> [07/May/2018:13:51:13 +0200] slapi_ldap_bind - Error: could not send bind 
>>> request for id [cn=MasterMasterReplicationManager,cn=config] authentication 
>>> mechanism [SIMPLE]: error -1 (Can't contact LDAP server), system error 
>>> -5987 (Invalid function argument.), network error 115 (Operation now in 
>>> progress, host "ldap-master-b02.mydomain.com:636”)
>> Is there anything else the errors log?  What about the access log on:
>> ldap-master-b02.mydomain.com? 
> No, absolutely no error log.
Then where did the above error message come from?  :-)  Usually there
are a few more messages when replication fails to connect to a consumer.

You should also see "something" in the consumer's access log.

Under cn=config, what is "nsslapd-ssl-check-hostname" set to?  Try
setting it to "off" to see if it makes a difference.

If that still doesn't help enable connection and replication verbose
error logging:

   
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/configuration_command_and_file_reference/core_server_configuration_reference#cnconfig-nsslapd_errorlog_level_Error_Log_Level

    Set "nsslapd-errorlog-level" to 8200

    Fyi, 8 (conn logging) + 8192 (repl logging) = 8200, then when you
are done set it to zero or simply remove the attribute.

Then send that output please.

Thanks,
Mark




>  I can send you tcpdump :)
>
>> Personally I have not seen this exact
>> error, but I don't see anything that says it's SSL specific.  If you
>> change the agreement to use LDAP instead of SSL does it work?
> Yes, I’m actually modifying my previously working plain replication Ansible 
> playbook to SSL-enabled…
>
> Michal
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: SSL replication error

[Michal Medvecky]

> On 8 May 2018, at 17:45, Mark Reynolds  wrote:
> 
> 
> 
> On 05/07/2018 08:00 AM, Michal Medvecky wrote:
>> [07/May/2018:13:51:13 +0200] slapi_ldap_bind - Error: could not send bind 
>> request for id [cn=MasterMasterReplicationManager,cn=config] authentication 
>> mechanism [SIMPLE]: error -1 (Can't contact LDAP server), system error -5987 
>> (Invalid function argument.), network error 115 (Operation now in progress, 
>> host "ldap-master-b02.mydomain.com:636”)
> Is there anything else the errors log?  What about the access log on:
> ldap-master-b02.mydomain.com? 

No, absolutely no error log. I can send you tcpdump :)

> Personally I have not seen this exact
> error, but I don't see anything that says it's SSL specific.  If you
> change the agreement to use LDAP instead of SSL does it work?

Yes, I’m actually modifying my previously working plain replication Ansible 
playbook to SSL-enabled…

Michal
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: SSL replication error

[Mark Reynolds]

On 05/07/2018 08:00 AM, Michal Medvecky wrote:
> [07/May/2018:13:51:13 +0200] slapi_ldap_bind - Error: could not send bind 
> request for id [cn=MasterMasterReplicationManager,cn=config] authentication 
> mechanism [SIMPLE]: error -1 (Can't contact LDAP server), system error -5987 
> (Invalid function argument.), network error 115 (Operation now in progress, 
> host "ldap-master-b02.mydomain.com:636”)
Is there anything else the errors log?  What about the access log on:
ldap-master-b02.mydomain.com?  Personally I have not seen this exact
error, but I don't see anything that says it's SSL specific.  If you
change the agreement to use LDAP instead of SSL does it work?
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org