Here is a simpler workaround using a three-line Python source patch.
First, the title of this thread is, perhaps, misleading. The bug occurs when installing a
replica running a newer version of freeIPA than what is running on the server you are
replicating from. I don't know the entire range of versions, but in my case, the
master server is running freeIPA 4.9.6 and the replica has 4.9.10. The package for which
the fix was tested is ipa-server-4.9.6-10 so I guess that is the boundary.
If only I could upgrade my master server to 4.9.6-10 or later. But it is running CentOS 8
which, I believe, was dead-ended by CentOS Stream. And I didn't want to go through the
version hell associated with trying to put 4.9.6 freeIPA on my Fedora replica/client.
But patching the server turned out to be a piece of cake. The fix is three lines in one
python file:
https://github.com/freeipa/freeipa/pull/6155/commits/018720248ab64300d903...
On the master server, add these lines to
/usr/lib/python3.6/site-packages/ipaserver/secrets/handlers/pemfile.py (path might
differ):
'-keypbe', 'AES-256-CBC',
'-certpbe', 'AES-256-CBC',
'-macalg', 'sha384',
at the end of the call to ipautil.run() in the export_key() function ... around line 34
(see referenced commit delta).
Then delete the contents of the __pycache__ subdirectory (because I am always suspicious
of caches).
Then reboot (because I am always suspicious of caches).
It took a while for my rebooted server's time to sync to good sources. After that the
ipa replica install succeeded.