Bug 2032806

The issue looks similar to https://bugzilla.redhat.com/show_bug.cgi?id=1998016. Can you please detail what pki packages were installed? This should be fixed with pki-ca-11.0.1-3.el9

So my thinking is that there are two parts here:

 - pki-core fix in bug 1998016 is required but not enough. It only fixes the first step -- when RA Agent file is generated, it is no longer encrypted with a legacy cipher

 - IPA needs to drop encryption of existing RA Agent file generated with older PKI version _before_ submitting it to replica via Custodia

So we need to fix it on our side as well and have to do it on the 'older' master side, hence RHEL 8.

(In reply to Alexander Bokovoy from comment #1)
> The issue looks similar to
> https://bugzilla.redhat.com/show_bug.cgi?id=1998016. Can you please detail
> what pki packages were installed? This should be fixed with
> pki-ca-11.0.1-3.el9

My version of pki-ca is 10.11.2-2.module_el8.5.0+945+a81e57da on the CS8 node.
I have destroyed the CS9 node where I tried that. I don't know the version at the time.
I can try again and get the versions in CS9 if needed

I can confirm the issue is reproducible with RHEL 8.5 server + RHEL 9.0 replica:

[server]# rpm -qa ipa-server pki-ca
ipa-server-4.9.6-6.module+el8.5.0+12660+88e16a2c.x86_64
pki-ca-10.11.2-2.module+el8.5.0+12735+8eb38ccc.noarch


[replica]# rpm -qa ipa-server pki-ca
pki-ca-11.0.1-3.el9.noarch
ipa-server-4.9.8-1.el9.x86_64

meaning we need to fix this issue for RHEL 8->9 migration.

The problem is not the encryption of the ra-agent.key file. The Custodia client on the new RHEL 9 replica talks to the Custodia server on the RHEL 8.5 source server. Custodia's export layer on the source server creates an encrypted PKCS#12 file that contains the cert and the key. The code uses OpenSSL's default encryption scheme for PKCS#12, which is no longer supported on RHEL 9. To fix the problem you have to modify the export_key() function at https://github.com/freeipa/freeipa/blob/master/ipaserver/secrets/handlers/pemfile.py#L29 to use a stronger encryption algorithm.

The args:

    -keypbe AES-256-CBC -certpbe AES-256-CBC -macalg sha384

should do the trick to use stronger PBEv2 instead of old, insecure PBEv1. It's a trivial fix, but you have to backport the fix to supported RHEL 8 versions...

The weak encryption is not a security problem. The communication is protected by GSSAPI and HTTPS. We only encrypt because FIPS does not let us export key material without encryption.

PS: There is also a layer of JOSE authentication and encryption in the Custodia protocol. The PKCS#12 encryption is just there for FIPS compliance. The server sends the PKCS#12 blob and plain password inside the JOSE encrypted, JOSE authenticated, HTTPS encrypted, and GSSAPI authenticated response.

(In reply to Christian Heimes from comment #5)
> The problem is not the encryption of the ra-agent.key file. The Custodia
> client on the new RHEL 9 replica talks to the Custodia server on the RHEL
> 8.5 source server. Custodia's export layer on the source server creates an
> encrypted PKCS#12 file that contains the cert and the key. The code uses
> OpenSSL's default encryption scheme for PKCS#12, which is no longer
> supported on RHEL 9. To fix the problem you have to modify the export_key()
> function at
> https://github.com/freeipa/freeipa/blob/master/ipaserver/secrets/handlers/
> pemfile.py#L29 to use a stronger encryption algorithm.
> 
> The args:
> 
>     -keypbe AES-256-CBC -certpbe AES-256-CBC -macalg sha384
> 
> should do the trick to use stronger PBEv2 instead of old, insecure PBEv1.
> It's a trivial fix, but you have to backport the fix to supported RHEL 8
> versions...
> 
> The weak encryption is not a security problem. The communication is
> protected by GSSAPI and HTTPS. We only encrypt because FIPS does not let us
> export key material without encryption.

thanks Christian, I can confirm that the new args fix the issue. I tested with RHEL 8.5 server + RHEL 9.0 replica:

[root@master /]# rpm -qa ipa-server pki-ca
ipa-server-4.9.6-10.module+el8.5.0+13587+92118e57.x86_64
pki-ca-10.11.2-3.module+el8.5.0+13650+763a7202.noarch


[root@replica cloud-user]# rpm -qa ipa-server pki-ca
pki-ca-11.0.3-1.el9.noarch
ipa-server-4.9.8-1.el9.x86_64

Upstream PR: https://github.com/freeipa/freeipa/pull/6155

moving to POST.

Fixed upstream
master:
https://pagure.io/freeipa/c/fd7f4a7411eb639d72dbe1f7749f1932fdcc9e62

Fixed upstream
ipa-4-9:
https://pagure.io/freeipa/c/653a7fe02880c168755984133ee143567cc7bb4e

Thank you for the quick fix.
May I ask if this new version will be pushed to Centos Stream 8?

(In reply to Monkey Bizness from comment #11)
> Thank you for the quick fix.
> May I ask if this new version will be pushed to Centos Stream 8?

The fix will be released in rhel8 first, then at some point it will land in c8s as well.

@ssidhaye pls qa_ack if you have agreed about it with Francisco/Rafael
@rjeffman pls dev_ack (Francisco is missing perms for now)

Verified using automation with these metadata http://idm-artifacts.usersys.redhat.com/mpolovka/trigger/4063/test-suite/metadata.orig.yaml.

All tests passed, as seen in the http://idm-artifacts.usersys.redhat.com/mpolovka/trigger//4063/test-suite//restraint.01/index.html

Therefore marking as verified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (idm:client and idm:DL1 bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2022:1884