Sam Morris via FreeIPA-users wrote:
I've added a RHEL 9 server to my IPA domain and I am finding that 'ipa vault-retrieve' fails intermittently.
It turns out that whenever the ipa client talks to the RHEL 9 server, this error happens:
$ ipa vault-retrieve --service host/myhost.example.com manager-password Traceback (most recent call last): File "/usr/lib/python3/dist-packages/ipalib/backend.py", line 141, in execute return self.Command[_name](*args, **options) File "/usr/lib/python3/dist-packages/ipalib/frontend.py", line 471, in __call__ return self.__do_call(*args, **options) File "/usr/lib/python3/dist-packages/ipalib/frontend.py", line 499, in __do_call ret = self.run(*args, **options) File "/usr/lib/python3/dist-packages/ipalib/frontend.py", line 1229, in run return self.forward(*args, **options) File "/usr/lib/python3/dist-packages/ipaclient/plugins/vault.py", line 1069, in forward vault_data = self._unwrap_response( File "/usr/lib/python3/dist-packages/ipaclient/plugins/vault.py", line 1021, in _unwrap_response cipher = Cipher(algo, modes.CBC(nonce), backend=default_backend()) File "/usr/lib/python3/dist-packages/cryptography/hazmat/primitives/ciphers/base.py", line 97, in __init__ mode.validate_for_algorithm(algorithm) File "/usr/lib/python3/dist-packages/cryptography/hazmat/primitives/ciphers/modes.py", line 85, in _check_iv_and_key_length _check_iv_length(self, algorithm) File "/usr/lib/python3/dist-packages/cryptography/hazmat/primitives/ciphers/modes.py", line 69, in _check_iv_length raise ValueError( ValueError: Invalid IV size (16) for CBC. ipa: ERROR: an internal error has occurred
I can reproduce this both on Debian unstable (with ipalib 4.9.8-1) and RHEL 8. I do this by overriding the value of xmlrpc_uri in /etc/ipa/default.conf to point to the RHEL 9 server before running 'ipa vault-retrieve'.
If I run the command on the RHEL 9 server, it works fine. I don't have a RHEL 9 client to test with.
It seems to be an interop problem between the server and client. The RHEL 9 server is wrapping the secret with AES but the client is trying to use TripleDES (and only supports 3DES).
Upstream ticket https://pagure.io/freeipa/issue/6524 changed from a hardcoded wrapping algorithm to be more flexible but this is apparently not backwards compatible.
I'm not deeply familiar with this wrapping code so I don't know if there is a workaround yet.
Any chance you can file a RHEL-8 bug against ipa for this while I continue looking?
thanks
rob