On 01/02/2021 11:58, Alexander Bokovoy wrote:
On ma, 01 helmi 2021, lejeczek via FreeIPA-users wrote:
Hi guys,
I'm trying to set up replication for a non-IPA database
following RHEL's docs, I'm on Centos Stream, and I get
errors:
....
[01/Feb/2021:11:25:38.854769282 +0000] - 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 "dzien.private:636")
[01/Feb/2021:11:25:38.856822436 +0000] - ERR -
NSMMReplicationPlugin - bind_and_check_pwp -
agmt="cn=swir-dzien-agreement" (dzien:636) - Replication
bind with SIMPLE auth failed: LDAP error -1 (Can't
contact LDAP server) (error:0407008A:rsa
routines:RSA_padding_check_PKCS1_type_1:invalid padding)
[01/Feb/2021:11:25:41.874045655 +0000] - 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 "dzien.private:636")
...
Instructions seem rather solid & easy to follow. What am
I missing when you look at the errors?
From seeing openssl errors ('rsa
routines:RSA_padding_check_PKCS1_type_1:invalid padding'),
I guess your
other LDAP server was set up using SSL parameters which
don't work
against the current system-wide crypto policy in CentOS 8
Stream.
In particular, error:0407008A means signature verification
failures.
These might also be connected with TLS 1.0 and RSA
1024-bit length keys
or being under POODLE attacks on that RSA key.
What you can do: to verify if this is indeed an issue with
the other
key, you can temporarily set a LEGACY crypto policy with
update-crypto-policies --show
update-crypto-policies --set LEGACY
on IPA server side, restart IPA, retry. If that fixes the
issue, it
means the other side's LDAPS support is bad with regards
to contemporary
crypto standards. Upgrading the other side to TLS 1.2 +
most likely
regenarating the RSA key in that LDAP server would be
needed anyway.
Once you have figured out an upgrade on the other LDAP
server side, make
sure to switch IPA's server's crypto policy back to DEFAULT.
But these are just guesses.
Before I begin fiddling - both ends/nodes show "DEFAULT" and
both ends had this policy at the time new ds instance were
created, this way:
-> $ dscreate interactive
so, it then may make you wonder how come 'dscreate' process
(and 389ds in entirety) "allowed" such a ds instance which
did not stick to policy to come into existence.
Could it be that something which should "just" work, did not
and it's possibly buggy?
many! thanks, L.
_______________________________________________
FreeIPA-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.fedorahosted.org/archives/list/[email protected]
