On 01/02/2021 13:33, Rob Crittenden wrote:
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
I also wonder if there something up with
389-ds-base-1.4.3.8-6.module_el8.3.0+604+ab7bf9cc.x86_64(which
I've not tried) VS
389-ds-base-1.4.3.16-8.module_el8.4.0+644+ed25d39e.x86_64
(ps. also IPA 4.9.0 has just vanished from Centos' repos, so
it seems)