#2584 Installation fails when CN is set in certificate subject base
Closed: Fixed None Opened 7 years ago by jcholast.

The CN attribute is allowed in certificate subject base. However, when it is set, it makes installation fail:

$ ipa-server-install ... --subject CN=Test

...

Unable to set admin password Command '/usr/bin/ldappasswd -h vm-085.idm.lab.bos.redhat.com -ZZ -x -D cn=Directory Manager -y /var/lib/ipa/tmp3SXnWH -T /var/lib/ipa/tmptPWLlg uid=admin,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' returned non-zero exit status 1
Configuration of client side components failed!
ipa-client-install returned: Command '/usr/sbin/ipa-client-install --on-master --unattended --domain idm.lab.bos.redhat.com --server vm-085.idm.lab.bos.redhat.com --realm IDM.LAB.BOS.REDHAT.COM --hostname vm-085.idm.lab.bos.redhat.com' returned non-zero exit status 1

ipaserver-install.log:

...

2012-03-27T13:08:09Z DEBUG Changing admin password
2012-03-27T13:08:09Z DEBUG args=/usr/bin/ldappasswd -h vm-085.idm.lab.bos.redhat.com -ZZ -x -D cn=Directory Manager -y /var/lib/ipa/tmp3SXnWH -T /var/lib/ipa/tmptPWLlg uid=admin,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
2012-03-27T13:08:09Z DEBUG stdout=
2012-03-27T13:08:09Z DEBUG stderr=ldap_start_tls: Connect error (-11)
        additional info: TLS: hostname does not match CN in peer certificate

2012-03-27T13:08:09Z DEBUG Unable to set admin password Command '/usr/bin/ldappasswd -h vm-085.idm.lab.bos.redhat.com -ZZ -x -D cn=Directory Manager -y /var/lib/ipa/tmp3SXnWH -T /var/lib/ipa/tmptPWLlg uid=admin,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com' returned non-zero exit status 1
2012-03-27T13:08:11Z DEBUG args=/usr/sbin/ipa-client-install --on-master --unattended --domain idm.lab.bos.redhat.com --server vm-085.idm.lab.bos.redhat.com --realm IDM.LAB.BOS.REDHAT.COM --hostname vm-085.idm.lab.bos.redhat.com
2012-03-27T13:08:11Z DEBUG stdout=ESC[?1034hInstallation failed. Rolling back changes.
IPA client is not configured on this system.

2012-03-27T13:08:11Z DEBUG stderr=ipa         : ERROR    LDAP Error: Connect error: TLS: hostname does not match CN in peer certificate
Failed to verify that vm-085.idm.lab.bos.redhat.com is an IPA Server.
This may mean that the remote server is not up or is not reachable
due to network or firewall settings.

ipaclient-install.log:

...

2012-03-27T13:08:11Z DEBUG Init ldap with: ldap://vm-085.idm.lab.bos.redhat.com:389
2012-03-27T13:08:11Z ERROR LDAP Error: Connect error: TLS: hostname does not match CN in peer certificate
2012-03-27T13:08:11Z DEBUG will use domain: idm.lab.bos.redhat.com

2012-03-27T13:08:11Z DEBUG will use server: vm-085.idm.lab.bos.redhat.com

I think the problem may be the use of CN. Normally this would be O=Test.

Can you show the subject of the certificates that were issued?

I have the feeling this is a bug in the way the dogtag profile is pulling out the CN in the certificate request.

I used the subject base CN=Test,O=Acme and ended up with certificate subjects of CN=Test,CN=Test,O=Acme.

The pattern we use for determining the hostname CN value is:

policyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+

I have the feeling it is grabbing whatever the last CN value is.

Confirmed. It is doing something quite funky with the subject.

I set the subject base: --subject=CN=Test,CN=Coyote,CN=Acme

This is the subject of my server certs:

"CN=Coyote,CN=Test,CN=Coyote,O=Acme"

Not sure if this only happens with CN as the RDN or not. Will need to check with dogtag team to see if this is a pattern issue or if we need to ban CN.

Sent e-mail to CS team asking for opinion. Do we need to tweak the pattern or ban CN in the subject base?

This is very easy to reproduce:

ipa-server-install -a password -p password --subject=CN=Test,CN=Coyote,O=Acme

I get the same output as the original report.

The problem is that the IPA server certificates are getting bad subjects assigned:

# certutil -L -d /etc/httpd/alias -n Server-Cert|grep Subject:
        Subject: "CN=Coyote,CN=Test,CN=Coyote,O=Acme"
# certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM/ -n Server-Cert|grep Subject:
        Subject: "CN=Coyote,CN=Test,CN=Coyote,O=Acme"
# certutil -L -d /etc/dirsrv/slapd-PKI-IPA/ -n Server-Cert|grep Subject:
        Subject: "CN=Coyote,CN=Test,CN=Coyote,O=Acme"

The cert for dogtag itself looks like:

# certutil -L -d /var/lib/pki-ca/alias -n 'Server-Cert cert-pki-ca' |grep Subject:
        Subject: "CN=tove.example.com,CN=Test,CN=Coyote,O=Acme"

FWIW, I've changed all the cert subject code to use DN objects. That might impact things. Do you want to continue debugging or wait till the dn code is in? I suppose for 2.2 the DN changes won't be relevant.

The funky subject dn has nothing to do with the profile or how the subject name pattern is used to validate the subject name. Rather it has to do with the way CS parses the PKCS10 subject name to extract the cn and build the relevant subject name.

I'm adding some CS code details here - as a reminder in case I need to revisit this again. Basically, the PKCS10 is parsed in EnrollProfile : fillPKCS10():

11/Jun/2012:17:44:25]http-9444-1: Finish parsePKCS10 - CN=tove.greyoak.com,CN=Test,CN=Coyote,O=Acme

Just before that we call:

String subjectCN = pkcs10.getSubjectName().getCommonName();
if (subjectCN == null)
subjectCN = "";
req.setExtData(REQUEST_SUBJECT_NAME + ".cn", subjectCN);

where getCommonName (in X500Name.java) returns the outermost CN attribute only.

Now, we might be able to change it to return a concatenation of CN attributes instead - or the innermost one or something else, but the question really is whether we should do that.

Looking at the RFCs, I do not see anything that precludes someone from using multiple cn attributes in a subjectDN, but it is unusual and highly unorthodox. Its not clear that all apps that will interact with such a cert would be able to handle it.

FWIW, I did install a CA with such a server cert (cn=hostname, cn=weirdness, o=acme) and it seems to work fine, but there are no guarantees that it would work for all such cases. I also did not try cn=weirdness, cn=hostname, o=acme.

In any case, given that there is no real user case that has been raised for this, and that there are yet uncertainties as to whether such a cert would work, and such a cert subject name is highly unorthodox, I suggest that you ban cn from the the subject base in the installer.

I think I need a clarification.

Is the problem that the subject has CN=tove.greyoak.com prepended to it when you're expecting it to begin with CN=Test?

If isn't that a problem with the CSR having a mangled subject?

FWIW, I'm not aware of any restriction on the number of RDN's containing a CN type in a subject DN. I believe (Robert Relya would know for sure) that the convention is to select the first CN (which is consistent with whata .getCommonName() is doing)

rcrit clarified my first question in IRC, but I'm still confused by comment #13

in pseudo-code what would

'CN=tove.greyoak.com,CN=Test,CN=Coyote,O=Acme'.getCommonName()

return? You say the outermost CN, so isn't that 'tove.greyoak.com'?, I don't have the java code in front of me but I must be misunderstanding something, could you clarify comment #13 please?

Note, I edited comment #15 to be

You say the outermost CN, so isn't that 'tove.greyoak.com'?

(must be the end of a long day because I don't think my brain is firing on all cylinders :-)

From all of the information I have been able to dig up, it is generally discouraged to have multiple CN values in the subject of a certificate. Though not technically illegal, it is not defined how to handle it, so you encounter different behavior with different clients. Furthermore, the ordering of RDNs in the subject does not matter, so it's not as simple as grabbing the left-most CN.

http://tools.ietf.org/html/rfc6125 - This is for PKIX, but sections 2.3.0 and 2.3.1 mention this problem.

I think the best thing to do here would be to reject the use of CN in the --subject option of ipa-server-install.

patch submitted:

freeipa-jdennis-0077-Ticket-2584-Installation-fails-when-CN-is-set-in-cer.patch

I didn't mean to set this to closed, the patch was only submitted not ACK'ed, resetting the state back to open.

pushed by Martin on 8/16/2012

master
390d708 Ticket #2584 - Installation fails when CN is set in certificate subject base

ipa-3-0
390d708 Ticket #2584 - Installation fails when CN is set in certificate subject base

Moving closed RC1 tickets to Beta 3.

Metadata Update from @jcholast:
- Issue assigned to jdennis
- Issue set to the milestone: FreeIPA 3.0 Beta 3

2 years ago

Login to comment on this ticket.

Metadata