#8930 IdM should call into Dogtag to dynamically update the security domain info
Closed: fixed 2 years ago by rcritten. Opened 2 years ago by rcritten.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 8): Bug 1740702

Description of problem:
When an IdM system with CA/KRA role is removed from  IdM topology, IdM should
call into Dogtag to also remove this system from the security domain info.

At the moment there is an inconsistency between the output from 'pki' and 'ipa'

See also https://bugzilla.redhat.com/show_bug.cgi?id=1740697

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:

Metadata Update from @rcritten:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1740702

2 years ago

Metadata Update from @rcritten:
- Issue assigned to rcritten

2 years ago

We can use the CA REST API to send a DELETE to:


This would delete the CA replica.example.test on port 443. The format is similar for the KRA.

From the CLI this looks like:

# pki -d /etc/pki/pki-tomcat/alias/ -n 'subsystemCert cert-pki-ca' -C
/etc/pki/pki-tomcat/alias/pwdfile.txt securitydomain-host-del 'CA
ipa.example.test 443'

This uses the subsystem cert because the IPA RA lacks permission to modify the security domain.

There is a Security Domain Administrators group but it too lacks permission to modify the domainxml.

@edewata do you have any suggestions on which group we should use, or should we modify the resourceACL?

It appears that the controlling ACL is:

resourceACLS: certServer.securitydomain.domainxml:read,modify:allow (read) user="anybody";allow (modify) group="Subsystem Group" || group="Enterprise CA Administrators" || group="Enterprise KRA Administrators" || group="Enterprise RA Administrators" || group="Enterprise OCSP Administrators" || group="Enterprise TKS Administrators" || group="Enterprise TPS Administrators":Anybody is allowed to read domain.xml but only Subsystem group and Enterprise Administrators are allowed to modify the domain.xml

It seems like the Security Domain Admins group missing is an oversight. I'm not sure I want to poke this deeply into the CA config though.

I'd lean towards Enterprise RA but that group can create other RAs which seems like a bad idea. The other groups seem worse.

@edewata never mind, I got it worked out. IPA created that resourceACL so I can just update it on our side.

According to b3c2197 the update file install/updates/50-dogtag10-migration.update was added for dogtag 9 -> 10 migration. This defines a set of resourceACLS that grant the RA agent rights to modify certain parts of the CA.

Later commit ba4df64 tweaked this to only apply the change on a replica, non-promotion installation. A pretty narrow case, purportedly to save a CA restart.

We need these resourceACLS and this update is applied currently while the CA is stopped so no extra restart is added.


  • db69855 Clean up the PKI securitydomain when removing a server
  • c0d6c05 ipatests: Verify that securitydomain is updated on server-del


  • be3a0f3 Clean up the PKI securitydomain when removing a server
  • a417810 ipatests: Verify that securitydomain is updated on server-del

Metadata Update from @rcritten:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.