This issue was exposed from https://fedorahosted.org/pki/ticket/816. When a clone ca imports its ca signing cert from the master, the ca signing cert could be encoded in one way. However, if the clone itself has an inherent different set of encoding order, during system cert creation at installation configuration, this clone ca appeared to apply its own set of encoding order over the issuer dn of the certs it generates at that time. Once the clone is completely configured, however, from our experiment in 816 comment#11, it seems to work properly.
Note: The issue should be reproducible by setting up Dogtag and clone alone without IPA.
The fix of this bug would benefit the following two situation: 1. When one version of Dogtag carries a different default set of encoding order than the next, in a cloning situation (as with ticket 816) 2. When we support migration from another product where importing of an existing CA signing cert into Dogtag is supported. The CA could very well carry different encodings.
The CA should always copy the CA signing cert's subject DN, exactly as specified with encodings, into the Issuer DN space of the certs it issues.
issue #1 above should be addressed by https://fedorahosted.org/pki/ticket/816
issue #2 above should be addressed along with https://fedorahosted.org/pki/ticket/456
Closing this, as it should be handled by addressing the two tickets mentioned in comment#1.
Metadata Update from @cfu: - Issue set to the milestone: N/A
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/1422
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.
Login to comment on this ticket.