Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Creating a Red Hat Enterprise Linux 7 replica from a Red Hat Enterprise Linux 6 replica running the CA service sometimes failed in IdM deployments where the initial Red Hat Enterprise Linux 6 CA master had been removed. This could cause problems in some situations, such as when migrating from Red Hat Enterprise Linux 6 to Red Hat Enterprise Linux 7. The bug occurred due to a problem in a previous version of IdM where the subsystem user, created during the initial CA server installation, was removed together with the initial master. This update adds the restore-subsystem-user.py script that restores the subsystem user in the described situation, thus enabling administrators to create a Red Hat Enterprise Linux 7 replica in this scenario.
Description of problem:
This is a little complicated. The scenario is as follows:
1. Create CA-0 on RHEL 6.6 (Dogtag 9)
2. Create CA-1 on RHEL 6.6 as replica of CA-0
3. Remove CA-0 (using pkiremove)
4. Create CA-2 as replica of CA-1 on RHEL 7.1 (Dogtag 10)
Step 4 fails in the UpdateDomainXML step, because the subsystem user no longer exists and therefore cannot be used for authentication.
In more detail:
1. In step 1 above, a user is created :
uid=CA-<master_host>-<nmaster_port>, ou=People, $suffix
which uses the CA subsystem cert as its cert.
2. In step 2, no new user is created because a user already exists which uses
the subsystem cert. We want to be sure that only one user exists with a
given cert.
3. In step 3, pkiremove contacts CA-0 (itself) calling updateDomainXML to
remove the server's entry from the security domain. It also removes the user
created in step 1. At this point - because the change is replicated through
the DB to CA-1, there is no subsystem user available.
4. In step 4, we attempt to make a call to updateDomainXML. We attempt to do
this on the admin port using an install token, but this fails because the
RHEL 6 CA-1 does not serve the newer servlets on the admin port. We then
fall back to the agent port which requires client authentication. We
attempt to use the subsystem cert as auth, but fail because no subsystem
user exists. Thus, the replica creation process fails.
Comment 2Endi Sukma Dewata
2015-05-29 03:40:25 UTC
Comment 4Endi Sukma Dewata
2015-06-03 00:11:41 UTC
ACKed by alee.
Fixed in rhel-6.7 branch: a681bc9f87368a2f61fdaa5e59b8acbff4a27656
Comment 6Endi Sukma Dewata
2015-06-05 17:15:28 UTC
It may not be possible to replicate the problem with the current packages, but the following steps should emulate the problem and verify the fix:
1. Install master.
2. Remove the subsystem user (i.e. CA-<hostname>-<port>).
3. Remove the user from the Subsystem Group.
4. Run the restore-subsystem-user.py to restore the user and the group.
5. Install replica.
Verification steps:
1. Install master CA
2. Remove the subsystem user and the user from the Subsystem group
[root@ipaqa64vme ~]# pki-server ca-group-member-find "Subsystem Group"
User ID: CA-ipaqa64vme.idmqe.lab.eng.bos.redhat.com-9443
Common Name: CA-ipaqa64vme.idmqe.lab.eng.bos.redhat.com-9443
Surname: CA-ipaqa64vme.idmqe.lab.eng.bos.redhat.com-9443
Type: agentType
Description: 2;4;CN=Certificate Authority,OU=pki-ca,O=IdmqeLabEngBosRedhat Domain;CN=CA Subsystem Certificate,OU=pki-ca,O=IdmqeLabEngBosRedhat Domain
E-mail:
[root@ipaqa64vme ~]# pki-server ca-group-member-del "Subsystem Group" CA-ipaqa64vme.idmqe.lab.eng.bos.redhat.com-9443
[root@ipaqa64vme ~]# pki-server ca-group-member-find "Subsystem Group"[root@ipaqa64vme ~]# pki-server ca-user-del CA-ipaqa64vme.idmqe.lab.eng.bos.redhat.com-9443
3. Run the restore-subsystem-user.py to restore the user and the group.
[root@ipaqa64vme scripts]# ./restore-subsystem-user.py
Restoring subsystem user
Subsystem certificate: 2;4;CN=Certificate Authority,OU=pki-ca,O=IdmqeLabEngBosRedhat Domain;CN=CA Subsystem Certificate,OU=pki-ca,O=IdmqeLabEngBosRedhat Domain
-----BEGIN CERTIFICATE-----
MIID2TCCAsGgAwIBAgIBBDANBgkqhkiG9w0BAQsFADBXMSQwIgYDVQQKExtJZG1xZUxhYkVuZ0Jvc1JlZGhhdCBEb21haW4xDzANBgNVBAsTBnBraS1jYTEeMBwGA1UEAxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE1MDYwNTIwMTc0N1oXDTE3MDUyNTIwMTc0N1owWjEkMCIGA1UEChMbSWRtcWVMYWJFbmdCb3NSZWRoYXQgRG9tYWluMQ8wDQYDVQQLEwZwa2ktY2ExITAfBgNVBAMTGENBIFN1YnN5c3RlbSBDZXJ0aWZpY2F0ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMYaKmasuQiJy08Z3F/V6qAXkFtPD35wFRtSwRFdGza61/+jpQehc5ZYiNeszbCm1JgDUoB/6gDJnFQsP38gDtslZrkNKNeFahPUXSNmg+yz5EN0Uxp4YdBFvGvmah18SgGz6fyCOAWejFGJwcTLW8HJCGm3R2zsnz9pY821SzniAp0bhoft3X6w6lEpPWN44S5VNuUl7ENH6J5OW9iCHoQu8neaFxFy3mFOMZKmcQRp7X/Pt+sfCQJzP9nFlbvCS6RbC/q9CIu0J0gUUw34FPa4WsCpT2S+geHyl3G2SpMEbg2aE3j3bbRUg0LyOIm6AMnjK3Mvcj+S/6mE0c9N+C0CAwEAAaOBrDCBqTAfBgNVHSMEGDAWgBR9VwboMsiSS9G2SpEcpC1qKfZm6jBXBggrBgEFBQcBAQRLMEkwRwYIKwYBBQUHMAGGO2h0dHA6Ly9pcGFxYTY0dm1lLmlkbXFlLmxhYi5lbmcuYm9zLnJlZGhhdC5jb206OTE4MC9jYS9vY3NwMA4GA1UdDwEB/wQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDQYJKoZIhvcNAQELBQADggEBAEl4RxNennbw009tpY5T6Y+n6C2dOK8rW5u7Saj3CWDrpHeS0ZNlELQf8fLZP1eZJNTQOeQ+EKF6/7U3PijRysTy1/fw+1qX7s+6Mo6MnUrP9dbJjRR3ufd/n0K9dczAhoatgRefV3o/nEd8uzMdmMKmk6eR/CpZpNU2dcc8sJ0NbmN5l9TrvXUwosZtE6Qp3NslodJRQBY9ia5yxqwI/k5ZcRC42fZNS1QhXE2wuH1sZNoScXMpnZL/cGjf4hqaO72fOk51cYu6he1NQXFQxhodhbktOiGaJMV9Z+N2pF/Dx3Kn52jyE4ifsIsWFl4HAJC1rmjlL6dpveEX25sGkGU=
-----END CERTIFICATE-----
New subsystem user CA-ipaqa64vme.idmqe.lab.eng.bos.redhat.com-9443 added
User added to Subsystem Group
Subsystem user CA-ipaqa64vme.idmqe.lab.eng.bos.redhat.com-9443 restored
[root@ipaqa64vme scripts]# pki-server ca-group-member-find "Subsystem Group" User ID: CA-ipaqa64vme.idmqe.lab.eng.bos.redhat.com-9443
Common Name: CA-ipaqa64vme.idmqe.lab.eng.bos.redhat.com-9443
Surname: CA-ipaqa64vme.idmqe.lab.eng.bos.redhat.com-9443
Type: agentType
Description: 2;4;CN=Certificate Authority,OU=pki-ca,O=IdmqeLabEngBosRedhat Domain;CN=CA Subsystem Certificate,OU=pki-ca,O=IdmqeLabEngBosRedhat Domain
4. Installed a clone of the above master CA successfully
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, 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://rhn.redhat.com/errata/RHSA-2015-1347.html
Description of problem: This is a little complicated. The scenario is as follows: 1. Create CA-0 on RHEL 6.6 (Dogtag 9) 2. Create CA-1 on RHEL 6.6 as replica of CA-0 3. Remove CA-0 (using pkiremove) 4. Create CA-2 as replica of CA-1 on RHEL 7.1 (Dogtag 10) Step 4 fails in the UpdateDomainXML step, because the subsystem user no longer exists and therefore cannot be used for authentication. In more detail: 1. In step 1 above, a user is created : uid=CA-<master_host>-<nmaster_port>, ou=People, $suffix which uses the CA subsystem cert as its cert. 2. In step 2, no new user is created because a user already exists which uses the subsystem cert. We want to be sure that only one user exists with a given cert. 3. In step 3, pkiremove contacts CA-0 (itself) calling updateDomainXML to remove the server's entry from the security domain. It also removes the user created in step 1. At this point - because the change is replicated through the DB to CA-1, there is no subsystem user available. 4. In step 4, we attempt to make a call to updateDomainXML. We attempt to do this on the admin port using an install token, but this fails because the RHEL 6 CA-1 does not serve the newer servlets on the admin port. We then fall back to the agent port which requires client authentication. We attempt to use the subsystem cert as auth, but fail because no subsystem user exists. Thus, the replica creation process fails.