Originally filed as https://pagure.io/freeipa/issue/7347

Request for enhancement

ipa-server-install should work when a custom RDN is used, when the RDN contains escaped commas. Alternatively, if this is not possible due to interactions with Dogtag code, the documentation should expressly indicate that such escaped values cannot be used.

Issue

When running ipa-server-install with the --subject-base option to override the default realm name as the organization, a comma that is properly escaped will cause an authentication failure later in the setup script.

One legitimate reason that the RDN would include a comma is a corporation's legal name — for example, "O=Acme\, Inc.,ST=Massachusetts,C=US". According to RFC 4514, commas can be escaped with a prefixed backslash (section 2.4; examples in section 4).

Steps to Reproduce

1. On a clean minimal CentOS installation, install the FreeIPA packages with yum install ipa-server from the default repositories. Ensure that the hostname for the local system has been added to /etc/hosts.
2. Invoke ipa-server-install with a --subject-base option whose value contains an escaped comma.
3. Accept default values for other installation prompts.

Actual behavior

The installation proceeds, but halts with an error at step 25 of the CA setup with the following message:

Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
  [1/29]: configuring certificate server instance
  [2/29]: exporting Dogtag certificate store pin
  [3/29]: stopping certificate server instance to update CS.cfg
  [2/29]: exporting Dogtag certificate store pin
  [3/29]: stopping certificate server instance to update CS.cfg
  [4/29]: backing up CS.cfg
  [5/29]: disabling nonces
  [6/29]: set up CRL publishing
  [7/29]: enable PKIX certificate path discovery and validation
  [8/29]: starting certificate server instance
  [9/29]: configure certmonger for renewals
  [10/29]: requesting RA certificate from CA
  [11/29]: setting up signing cert profile
  [12/29]: setting audit signing renewal to 2 years
  [13/29]: restarting certificate server
  [14/29]: publishing the CA certificate
  [15/29]: adding RA agent as a trusted user
  [16/29]: authorizing RA to modify profiles
  [17/29]: authorizing RA to manage lightweight CAs
  [18/29]: Ensure lightweight CAs container exists
  [19/29]: configure certificate renewals
  [20/29]: configure Server-Cert certificate renewal
  [21/29]: Configure HTTP to proxy connections
  [22/29]: restarting certificate server
  [23/29]: updating IPA configuration
  [24/29]: enabling CA instance
  [25/29]: migrating certificate profiles to LDAP
  [error] RemoteRetrieveError: Failed to authenticate to CA REST API
ipa.ipapython.install.cli.install_tool(CompatServerMasterInstall): ERROR    Failed to authenticate to CA REST API
ipa.ipapython.install.cli.install_tool(CompatServerMasterInstall): ERROR    The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information

The certificate authority has already been configured at this point. A valid /etc/ipa/ca.crt has already been created, whose issuer and subject names are properly formatted.

Expected behavior

The installation should succeed.

Version/Release/Distribution

ipa-server-4.5.0-22.el7.centos.x86_64
ipa-client-4.5.0-22.el7.centos.x86_64
389-ds-base-1.3.6.1-24.el7_4.x86_64
pki-ca-10.4.1-17.el7_4.noarch
krb5-server-1.15.1-8.el7.x86_64

Additional info:

Log file locations: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/config-files-logs.html
Troubleshooting guide: https://www.freeipa.org/page/Troubleshooting

Here's the generated CA certificate, showing that the base DN has been properly applied (meaning that the escaped comma was properly processed here).

The contents of /var/log/pki/pki-tomcat/ca/system show that it was "IPA RA" that failed to authenticate — and reveal the jumbled subject name given to that certificate:

0.localhost-startStop-1 - [04/Jan/2018:05:15:52 UTC] [13] [3] authz instance DirAclAuthz initialization failed and skipped, error=Property internaldb.ldapconn.port missing value
0.http-bio-8443-exec-3 - [04/Jan/2018:05:17:03 UTC] [3] [3] Cannot build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate
0.http-bio-8443-exec-3 - [04/Jan/2018:05:17:06 UTC] [3] [3] CASigningUnit: Object certificate not found. Error Certificate object not found
0.Thread-14 - [04/Jan/2018:05:17:38 UTC] [8] [3] Publishing: Could not publish certificate serial number 0x7. Error Failed to publish using rule: No rules enabled
0.http-bio-8443-exec-3 - [04/Jan/2018:05:18:35 UTC] [6] [3] Cannot authenticate agent with certificate Serial 0x7 Subject DN CN=IPA RA,CN=Inc.,O=Acme\\,ST=Massachusetts,C=US. Error: User not found

Notice: CN=IPA RA,CN=Inc.,O=Acme\\,ST=Massachusetts,C=US

Similarly, /var/log/pki/pki-tomcat/ca/transactions shows that when the IPA RA certificate was first enrolled, the requested distinguished name already had this problem:

0.http-bio-8443-exec-5 - [04/Jan/2018:05:17:38 UTC] [20] [1] enrollment reqID 7 fromAgent userID: admin authenticated by certUserDBAuthMgr is completed DN requested: CN=IPA RA,CN=Inc.,O=Acme\\,ST=Massachusetts,C=US cert issued serial number: 0x7 time: 235

I've also attached the dogtag setup log.

I think I've traced it through to a certmonger issue.

How I got there:

1) ipaserver/install/cainstance.py is responsible for this particular enrollment:

            reqId = certmonger.request_and_wait_for_cert(
                certpath=(paths.RA_AGENT_PEM, paths.RA_AGENT_KEY),
                principal='host/%s' % self.fqdn,
                subject=str(DN(('CN', 'IPA RA'), self.subject_base)),
                ...
                storage="FILE")

This isn't the problem. The assembled DN containing the subject base is fine; ipapython/dn.py smartly accounts for escaping. In the example I gave above, minus the state (to make these examples more convenient to illustrate), the subject is appropriately assembled as ('CN','IPA RA'),('O','Acme\, Inc.'),('C','US').

2) However, the parameter above is cast back to a string, instead of being passed as a DN object to certmonger.request_and_wait_for_cert().

Once passed to the certmonger module ipalib/install/certmonger.py, it gets switched back to a DN, reversed, and then back to a string again... this "workaround":

subject = str(DN(*reversed(DN(subject))))

Still not the problem. Despite the list operation and type changes, the ipapython/dn.py module is intelligent, so this line reverses the order of AVAs without damaging the escaping. At this point, the subject is still appropriately grouped, just reversed, as ('C','US'),('O','Acme\, Inc.'),('CN','IPA RA').

3) The Python code eventually sends this still okay DN string, in reversed order, to certmonger over dbus or a socket... something like (string) C=US,O=Acme\, Inc.,CN=IPA RA.

4) As certmonger#62 says, certmonger implements the subject field differently depending on the destined storage. Here, since storage="FILE", it's going to use the OpenSSL implementation in csrgen-o.c. (Unlike the NSS implementation in csrgen-n.c, which can invoke a library helper function CERT_AsciiToName(), the OpenSSL implementation is forced to do its own parsing of the DN, one AVA at a time...)

5) Which brings me to the certmonger source:

/* This isn't really correct, but it will
    * probably do for now. */
p = entry->cm_template_subject;
q = p + strcspn(p, ",");
subject = X509_NAME_new();
if (subject != NULL) {
    while (*p != '\0') {
...

That's it, then; because csrgen-o.c in certmonger naively splits the subject string by commas, all the hard work in ipapython/dn.py was for naught. Despite ipapython/dn.py's intelligent handling of RDN attributes, certmonger just treated it as a string without accounting for escaping or multivalue.

6) Notably, when the code excerpted above splits a string like C=US,O=Acme\, Inc.,CN=IPA RA, it's going to see C=US; O=Acme\; Inc.; CN=IPA RA. And lines 213-218 treat " Inc." as its own common name value:

X509_NAME_add_entry_by_txt(subject,
    "CN", astring_type("CN", p, q - p),
    (unsigned char *) p, q - p,
    -1, 0);

I'm assuming the OpenSSL library adds its own escaping to the dangling \, resulting in the final, observed subject of CN=IPA RA,CN=Inc.,O=Acme\\,C=US.

As I see it, the simple workaround for users is to try the \2c escape code for the comma instead — i.e. O=Acme\2c Inc.,C=US, which the naive C code in certmonger won't damage. But this is definitely not an obvious requirement of --subject-base.

A smarter fix might avoid passing the information as a string. certmonger's code avoids the naive comma-delimiter parsing if a subject is provided in DER.

            if ((entry->cm_template_subject_der != NULL) &&
                (strlen(entry->cm_template_subject_der) != 0)) {
                i = strlen(entry->cm_template_subject_der);
                name = malloc(i);
                if (name != NULL) {
                    i = cm_store_hex_to_bin(entry->cm_template_subject_der,
                                name, i);
                    nametmp = name;
                    subject = d2i_X509_NAME(NULL, &nametmp, i);
                }
            }
            if ((subject == NULL) &&
/* ... go on to split by commas ... */

That might be a more optimal way of passing the information from Python to certmonger.