We need to hook this into CA/KRA uninstaller but also a cleanup job could be done in ipa-server-upgrade.

Adding dependency on 1740697.

*** This bug has been marked as a duplicate of bug 1902173 ***

Re-opening as the related BZ didn't address the security domain cleanup.

Upstream ticket:
https://pagure.io/freeipa/issue/8930

Fixed upstream
master:
https://pagure.io/freeipa/c/db6985564600fdd7778ab2d16d73cbab4df944db
https://pagure.io/freeipa/c/c0d6c05d00f97d7a46a9e480d4c984eda22ec70c

Test added upstream in test_integration/test_server_del.py::TestLastServices::test_removal_of_server_raises_error_about_last_kra

Additioanl fix that prevented upgrades in a CA-less environment

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

Fixed upstream
ipa-4-9:
https://pagure.io/freeipa/c/be3a0f3201bbb060a9d53fb65cbbccf6c7bf9bb4
https://pagure.io/freeipa/c/a417810df5500b5780396ab88d53eaea74f74ccc

Additional fix that prevented upgrades in a CA-less environment

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

*** Bug 2018535 has been marked as a duplicate of this bug. ***

Sorry about that. The CA has its own authentication system outside of IPA.

This should do the trick:

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

These options authenticate using the certificate that the CA uses for its LDAP binds. It has permissions to do this removal.

Take care when executing this as removing the wrong host may require re-installation of that host. I'm not aware of a way to re-create these entries.

*** Bug 2021880 has been marked as a duplicate of this bug. ***

the issue is when a replica with a CA or KRA role is uninstalled, the IPA LDAP backend keeps that replica roles references under cn=masters,cn=ipa,cn=etc,dc=idm,dc=example,dc=test so IPA and the ipa-healthcheck 's IPADogtagCertsMatchCheck test think the is a configured CA

could be tested with

cat << EOF > ~/test.api
api.Command.ping()
from ipaserver.install import cainstance
ca=cainstance.CAInstance(api.env.realm)
ca.is_configured()
EOF

cat ~/test.api | ipa console



./freeipa-healthcheck/src/ipahealthcheck/ipa/certs.py
@registry
class IPADogtagCertsMatchCheck(IPAPlugin):
...
    @duration
    def check(self):
        if not self.ca.is_configured():  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< finds a CA role from ipaConfigString in cn=CA,cn=some-replica-hostname,cn=masters,cn=ipa,cn=etc,dc=xx
            logger.debug('CA is not configured, skipping connectivity check')
            return

        def match_ldap_nss_cert(plugin, ldap, db, cert_dn, attr, cert_nick):
            try:
                entry = ldap.get_entry(cert_dn)
...
            if not cert_matched:
                yield Result(plugin, constants.ERROR,
                             key=cert_nick,
                             nickname=cert_nick,
                             dbdir=db.secdir,
                             msg=('{nickname} certificate in NSS DB {dbdir} '
                                  'does not match entry in LDAP'))
                return False
            return True



for example on an ipaserver1 where ipaserver was removed/uninstalled:

ipa server-role-find --role="CA server"
----------------------
2 server roles matched
----------------------
  Server name: ipaserver1.idm.example.test
  Role name: CA server
  Role status: enabled

  Server name: ipaserver2.idm.example.test <<<<<<<<<<<<<<<<<<
  Role name: CA server   <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 
  Role status: configured  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
----------------------------
Number of entries returned 2
----------------------------
[root@ipaserver1 ~]# 


ldapsearch -o ldif-wrap=no -LLLx -D "cn=directory manager" -w password -b cn=masters,cn=ipa,cn=etc,dc=idm,dc=example,dc=test cn=CA cn ipaConfigString
dn: cn=CA,cn=ipaserver1.idm.example.test,cn=masters,cn=ipa,cn=etc,dc=idm,dc=example,dc=test
cn: CA
ipaConfigString: startOrder 50
ipaConfigString: caRenewalMaster
ipaConfigString: enabledService

dn: cn=CA,cn=ipaserver2.idm.example.test,cn=masters,cn=ipa,cn=etc,dc=idm,dc=example,dc=test  <<<<<<<<<<<
cn: CA
ipaConfigString: configuredService  <<<<<<<<<<<<<<<<<
ipaConfigString: startOrder 50       <<<<<<<<<<<<<<<<<<<<<



as a workaround, the entry 
cn=CA,cn=ipaserver2.idm.example.test,cn=masters,cn=ipa,cn=etc,dc=idm,dc=example,dc=test
could probably be removed with a ldapdelete if there is really no CA installed


and there are left overs under o=ipaca for the either uninstalled or CA role removed from ipaserver2, specially in the "PKI registry" / "PKI security domain"

ldapsearch -o ldif-wrap=no -LLLx -D "cn=directory manager" -w password -b o=ipaca cn=*ipaserver2* dn
dn: uid=CA-ipaserver2.idm.example.test-8443,ou=people,o=ipaca

dn: cn=ipaserver2.idm.example.test:443,cn=CAList,ou=Security Domain,o=ipaca

dn: uid=acme-ipaserver2.idm.example.test,ou=people,o=ipaca

Marc, this is a completely different issue altogether. I've not reproduced it myself. It could have to do with the way the IPA server is being removed from rotation. `ipa server-del <host>` should clean these up.

This bug is about the dogtag-specific securitydomain capability which is what triggers the healthcheck errors because we weren't cleaning it up on uninstall.

version:
ipa-server-4.9.8-2.module+el8.6.0+13621+937b8cd9.x86_64

============================= test session starts ==============================
platform linux -- Python 3.6.8, pytest-3.10.1, py-1.11.0, pluggy-1.0.0 -- /usr/libexec/platform-python
cachedir: /home/cloud-user/.pytest_cache
metadata: {'Python': '3.6.8', 'Platform': 'Linux-4.18.0-358.el8.x86_64-x86_64-with-redhat-8.6-Ootpa', 'Packages': {'pytest': '3.10.1', 'py': '1.11.0', 'pluggy': '1.0.0'}, 'Plugins': {'metadata': '1.11.0', 'html': '1.22.1', 'multihost': '3.0', 'sourceorder': '0.5'}}
rootdir: /usr/lib/python3.6/site-packages/ipatests, inifile:
plugins: metadata-1.11.0, html-1.22.1, multihost-3.0, sourceorder-0.5
collecting ... collected 16 items

test_integration/test_server_del.py::TestServerDel::test_removal_of_nonexistent_master_raises_error PASSED [  6%]
test_integration/test_server_del.py::TestServerDel::test_forced_removal_of_nonexistent_master PASSED [ 12%]
test_integration/test_server_del.py::TestServerDel::test_removal_of_replica1_disconnects_domain_topology PASSED [ 18%]
test_integration/test_server_del.py::TestServerDel::test_removal_of_replica2_disconnects_ca_topology PASSED [ 25%]
test_integration/test_server_del.py::TestServerDel::test_ignore_topology_disconnect_replica1 PASSED [ 31%]
test_integration/test_server_del.py::TestServerDel::test_ignore_topology_disconnect_replica2 PASSED [ 37%]
test_integration/test_server_del.py::TestServerDel::test_removal_of_master_disconnects_both_topologies PASSED [ 43%]
test_integration/test_server_del.py::TestServerDel::test_removal_of_replica1 PASSED [ 50%]
test_integration/test_server_del.py::TestServerDel::test_removal_of_replica2 PASSED [ 56%]
test_integration/test_server_del.py::TestLastServices::test_removal_of_master_raises_error_about_last_dns PASSED [ 62%]
test_integration/test_server_del.py::TestLastServices::test_install_dns_on_replica1_and_dnssec_on_master PASSED [ 68%]
test_integration/test_server_del.py::TestLastServices::test_removal_of_master_raises_error_about_dnssec PASSED [ 75%]
test_integration/test_server_del.py::TestLastServices::test_disable_dnssec_on_master PASSED [ 81%]
test_integration/test_server_del.py::TestLastServices::test_removal_of_master_raises_error_about_last_ca PASSED [ 87%]
test_integration/test_server_del.py::TestLastServices::test_removal_of_server_raises_error_about_last_kra PASSED [ 93%]
test_integration/test_server_del.py::TestLastServices::test_forced_removal_of_master PASSED [100%]

---------------- generated xml file: /home/cloud-user/junit.xml ----------------
----------- generated html file: file:///home/cloud-user/report.html -----------
========================= 16 passed in 3896.89 seconds =========================

Automation passed for test_removal_of_server_raises_error_about_last_kra, Hence marking the bug as verified.

https://ci-jenkins-csb-idmops.apps.ocp-c1.prod.psi.redhat.com/job/ipa-RHEL8.6/job/Nightly/job/tier-2-RHEL8.6-Nightly-upstream-server-del/

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