This bug is created as a clone of upstream ticket:
Currently the --subject option for ipa-server-install only allows you to add other attributes (e.g. O, OU, C) to the existing CN=Certificate Authority for the IPA CA. In some OSs, certificate authorities are only listed by CN (instead of other attributes in the DN), thus the rather bare entry of "Certificate Authority". In older versions of IPA, there was at least the realm added before such that you had EXAMPLE.COM Certificate Authority. It would be nice to be able to at a minimum return to this behavior, or, even better, be able to set the entire subject including the CN itself such that you would include the organization name in the CN.
*** Bug 1283602 has been marked as a duplicate of this bug. ***
Created attachment 1176656 [details]
Proposed patch (PoC) to add --subject_cn and --subject_mail options to ipa-server-install
This patch replaces all hardcoded "Certificate Authority" settings for the CA Cert subject with an optional subject_cn and even an additional subject_mail as RDN.
The patch also extends the ipaGuiConfig OC with ipaCertificateSubjectRdn attribute to keep track of this new setting.
This patch is certainly not perfect and has only been tested in a limited number of use cases. However, it should be a viable starting point for productizing this new feature.
A clarification regarding requirements and use case:
3. What is the nature and description of the request?
Currently, the subject for a IPA generated CA cert is built of two components,
a subject base DN (subject_base) and a static common name: 'CN=Certificate
Authority'. While the subject_base is customizable via a command line option to
ipa-server-install, the common name is hard coded into the installer.
It is required to have the common name component of the subject DN
customizable. In addition, it is required to allow an additional and optional
emailAddress component prepended to the subject DN as most significant
4. Why does the customer need this? (List the business requirements here)
The customer needs to integrate IPA into an existing chain of trust. The IPA
generated CA certificate needs to be signed by an superordinate PKI. To allow
the IPA CA cert to be signed by the superordinate PKI, it needs to meet certain
criteria, including a particular customer specific common name and an
additional emailAddress to clearly identify the subordinate CA.
The current hard coded common name does not meet the requirements and therefor
makes the integration of IPA into the existing PKI impossible. This in turn
leaves the Linux/Unix IT operations dependent from the superordinate PKI even
in cases, where creation of service certs could perfectly be delegated to this
Linux/Unix IT Ops in accordance to existing compliance rules and operational
5. How would the customer like to achieve this? (List the functional requirements here)
The customer would like to get options to customize the common name and add an
email address to the CA cert subject upon creation with ipa-server-install --external-ca.
6. For each functional requirement listed in question 5, specify how Red Hat
and the customer can test to confirm the requirement is successfully implemented.
The new feature (option) must result in a CA cert CSR with subject line like
/usr/lib64/nss/unsupported-tools/pp -t cr -a -i /root/ipa.csr|grep Subject:
Subject: Efirstname.lastname@example.org,CN=Custom CA Name,OU=Example IT,O=Example Corp,L=City,ST=State,C=US
openssl req -text -noout -in /root/ipa.csr |grep Subject:
Subject: C=US,ST=State,L=City,O=Example Corp,OU=Example IT,CN=Custom CA Name/emailAddressemail@example.com
This IPA CA CSR must be signable by an Active Directory PKI and that signed
certificate must be usable to proceed with the IPA server installation. In
particular, IPA must be able to provide and accept the canonical order of
subject attributes with emailAddress as most significant attribute, like shown
in the example above.
Verified using IPA version :: ipa-server-4.5.0-13.el7.x86_64
Marking BZ as verified.
See attachment for console.log.
Created attachment 1281012 [details]
Please note that Red Hat officially released public RHEL-7.4 Beta this week, as announced here:
The new RHEL-7.4 release includes a lot of new IdM functionality, including this RFE. Highlights can be found in RHEL-7.4 Release Notes, especially in the Authentication & Interoperability chapter:
IdM Engineering team would like to encourage everyone interested in this new functionality (and especially customers or community members requesting it) to try Beta and provide us with your feedback!
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.