#3360 Handle CA certs with no Friendly Name
Closed: Invalid None Opened 11 years ago by orion.

I'm trying to install ipa with a certificate provided by Comodo SSL. The CA chain certificate provided does not have a "Friendly Name" in it.

When installing with --dirsrv_pkcs12/httpd_pkcs12 I get:

[16/35]: configuring ssl for ds instance
Unexpected error - see ipaserver-install.log for details:
Could not find a CA cert in STAR_cora_nwra_com.p12

I've attached the output of pk12util -l for this ca cert. When imported by certutil it ends up with the name:

PositiveSSL CA 2 - AddTrust AB ,,

I'm not sure how this is being generated. A strange combination of the CN= of the Subject and the O= of the issuer?


I hacked find_root_cert_from_pkcs12() in /usr/lib/python2.6/site-packages/ipaserver/install/certs.py to parse it with:

               #m = re.match("\W+Friendly Name: (.*)", line)
               m = re.match("\W+Subject: \"CN=([^,]*),", line)

But this still leads to some install issues with the cert:

 [16/35]: configuring ssl for ds instance
ipa         : ERROR    Setting trust on PositiveSSL CA 2 failed
 [7/13]: setting up ssl
ipa         : ERROR    Setting trust on PositiveSSL CA 2 failed

because the name doesn't match.

Fix with:

 certutil -M -d /etc/dirsrv/slapd-NWRA-COM -n 'PositiveSSL CA 2 - AddTrust AB' -t CT,C,C
 service dirsrv restart
 certutil -M -d /etc/httpd/alias -n 'PositiveSSL CA 2 - AddTrust AB' -t CT,C,C
 service httpd restart

A brief comment explaining why would be greatly appreciated. Thank you.

We are planning to deprecate the utility since it cause more trouble than benefit.
The chaining during the install is the way to go.
Over time we will also develop the utility to deal with rotation of the chaining certs that might expire.

This was all done with "ipa-server-install", i.e. during the install. But especially for wildcard certs, the key and cert will be pre-generated.

That is part of what we are deprecating. The capability to provide external certs via PKCS#12 files was added early into IPA before a full CA was integrated. It has gotten to the point it causes more problems than it fixes.

Thanks for the explanations. FWIW - I think it would still be a very valuable feature to be able to specify a different private key and cert signed by another CA for the LDAP server.

Why? Is chaining not enough? Having mixed sources for certs for different components creates a setup that is hard to maintain.

I guess I don't understand "chaining". I'll have to find some docs.

I want to use a wildcard cert for the web and ldap server. This cert has already been issued. chaining appears to only support the signing of key/certs generated by ipa. I suppose I could have IPA generate a new cert with a subject of "O=*.nwra.com", perhaps that would work? I would need to then reissue the cert from our CA and replace it everywhere else it is used, which would be a royal pain.

IPA has an embedded CA by design. It can be a root CA or it can be chained to an external CA. Unfortunately it is a one time installation decision due to the nature of PKI and the way the trust chains are established. Dropping external certs under IPA hood is not going to be a sustainable solution for us, this is why we are closing this particular bug.
But let us step back and understand your use case better.
You have a CA and you have IPA. IPA is currently installed with a root CA so they are completely independent. What are you trying to accomplish? What is the end result that you want to get to?

I was hoping to avoid having to install the root CA in various clients (Thunderbird, Firefox, etc.) by having a certificate that was signed by a CA they already trust.

Note, I'm happy to move this discussion elsewhere (list, irc, etc)

See #3494 for more information. That ticket would track the actual work.

Metadata Update from @orion:
- Issue assigned to someone
- Issue set to the milestone: 0.0 NEEDS_TRIAGE

7 years ago

Login to comment on this ticket.

Metadata