ca_signing_subject_dn will pick the same value as that of rootca if they share the security domain. This is because default.cfg has pki_ca_signing_subject_dn=cn=CA Signing Certificate,o=%(pki_security_domain_name)s
Steps to Reproduce:
1. cfg file for pkispawn should not have values defined for subject dn of ca signing cert so that it picks a default value.
Actual results:
pkispawn fails
Expected results:
default value for ca_signing_subject_dn for subca should be different from that of rootca
Per impromptu 10.2.6 meeting of 7/17/2015: 10.3
Per Bug Triage of 05/03/2016: 10.3.1
In discussions with vakwetu, we propose adding some additional fields to the default DN to provide for greater uniqueness. This would change pki_ca_signing_subject_dn from:
cn=CA Signing Certificate,o=%(pki_security_domain_name)s
to:
cn=CA Signing Certificate,ou=%(pki_instance_name)s,ou=%(pki_subsystem_name)s,o=%(pki_security_domain_name)s
Note that, by default, %(pki_subsystem_name)s is defined as:
CA %(pki_hostname)s %(pki_https_port), KRA %(pki_hostname)s %(pki_https_port)s, OCSP %(pki_hostname)s %(pki_https_port)s, TKS %(pki_hostname)s %(pki_https_port)s, or TPS %(pki_hostname)s %(pki_https_port)s
Obviously, consideration must be made for the following:
If this proposal (or something like it) is implemented, all default DN values should be looked at to see if they require similar uniqueness consideration.
Per discussions with development and QE, it was noted that a simple workaround exists for this ticket by merely placing a revised value for pki_ca_signing_subject_dn in the pkispawn overrides file.
Consequently, it was determined to defer this ticket until 10.4, where we may possibly look at adding uniqueness to the default values of other DNs as well.
Per Offline Triage of 11/30/2016-12/01/2016: 10.4 - minor
Metadata Update from @rpattath: - Issue assigned to mharmsen - Issue set to the milestone: 10.4
Per CS/DS Meeting of August 7, 2017, it was determined to move this issue from 10.4 ==> FUTURE.
Metadata Update from @mharmsen: - Custom field feature adjusted to None - Custom field proposedmilestone adjusted to None - Custom field proposedpriority adjusted to None - Custom field reviewer adjusted to None - Custom field version adjusted to None - Issue close_status updated to: None - Issue set to the milestone: FUTURE (was: 10.4)
Metadata Update from @mharmsen: - Issue assigned to edewata (was: mharmsen)
Per 10.5.x/10.6 Triage: FUTURE
RHBZ: CLOSED UPSTREAM
Metadata Update from @mharmsen: - Custom field rhbz reset (from https://bugzilla.redhat.com/show_bug.cgi?id=1244021)
Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.
This issue has been cloned to GitHub and is available here: https://github.com/dogtagpki/pki/issues/2056
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Metadata Update from @dmoluguw: - Issue close_status updated to: migrated - Issue status updated to: Closed (was: Open)