lejeczek via FreeIPA-users wrote:
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.
Crypto policies are enforced regardless of what the user requests.
This may also point that one side is using TLS and the other side is not.
rob