After step 1 ipa config-show returned this:
ipa config-show
IPA masters: primary.example.com IPA CA servers: primary.example.com IPA KRA servers: primary.example.com
and the primary CA's CS.cfg had this:
CS.cfg
ca.connector.KRA.host=primary.example.com
After step 2 ipa config-show returned this:
IPA masters: primary.example.com, secondary.example.com IPA CA servers: primary.example.com, secondary.example.com IPA KRA servers: primary.example.com, secondary.example.com
The primary CA's CS.cfg had this:
but the secondary CA's CS.cfg had this:
ca.connector.KRA.host=primary.example.com:8443 secondary.example.com:8443
This happened because pkispawn copied the param from the primary CA when installing the secondary CA, then added the secondary KRA into this param when installing the secondary KRA, but currently it has no mechanism to update the param in the primary CA.
pkispawn
After step 3 ~~ipa config-show returned this:~~
IPA masters: secondary.example.com IPA CA servers: primary.example.com, secondary.example.com IPA KRA servers: primary.example.com, secondary.example.com
~~but sometimes it returned this instead:~~
~~This probably happened because the DS on the primary IPA was shutdown and removed before the config changes could be replicated to the DS on the secondary IPA.~~
~~Also,~~ the secondary CA's CS.cfg had this:
This happened because currently pkidestroy has no mechanism to remove the primary KRA from the secondary CA.
pkidestroy
Based on the current design, after step 2 the primary CA's CS.cfg should have this:
and after step 3 ~~ipa config-show should return this consistently:~~
IPA masters: secondary.example.com IPA CA servers: secondary.example.com IPA KRA servers: secondary.example.com
~~and~~ the secondary CA's CS.cfg should have this:
ca.connector.KRA.host=secondary.example.com
Since there's no guarantee that all existing replicas will be available when a replica is added/removed, even if this issue is fixed in PKI pkispawn/pkidestroy could still fail to update all replicas properly and the admin will ultimately be responsible to fix it manually.
One possible solution is to simply connect each CA to the local KRA on the same server so there's no need to add/remove other KRA replicas. This will require installing KRA on each replica (if KRA is needed at all), but this will also make each replica more consistent with each other.
Another possible solution is to migrate the KRA connector config into DS (just like CA profiles) so that the changes will be propagated automatically, then the CA will need to monitor config changes in DS.
@edewata Regarding the un-installation, the correct procedure is to perform:
ipa server-del primary.example.com
ipa-server-install --uninstall
This is described in Uninstalling an IdM server
If you perform the above steps, do you still see the primary server in the output of ipa config-show?
Thanks for the info, I wasn't aware of the ipa server-del command. However, even after executing that command there are still 2 problems remaining:
ipa server-del
ca.connector.KRA.host
secondary.example.com
primary.example.com
As discussed in the meeting IPA does not use cert profiles with key archival so this param (and the whole KRA connector config in CA's CS.cfg) probably can be dropped. Let me do some further investigation.