[Freeipa-users] Third party SSL certificate renewal

Jan Cholasta jcholast at redhat.com
Mon Nov 3 10:39:43 UTC 2014


Hi Dragan,

first of all sorry for the delay, I was on leave last week.

Dne 24.10.2014 v 20:31 Dragan Prostran napsal(a):
> Hi Jan,
>
> I'm grateful for your help. I've researched how to follow your
> recommendations above, but I'm not having a lot of luck. According to
> old posts in this mailing list,
> https://www.redhat.com/archives/freeipa-users/2013-May/msg00199.html,
> the command ipa-server-certinstall is the way to go. That said, I
> found an issue you've filed to allow for this, and it was implemented
> in FreeIPA 3.3: https://fedorahosted.org/freeipa/ticket/3641
> Unfortunately, this system is running FreeIPA 3.0:
>
> # rpm -qa | grep -P "ipa[_-]"
> ipa-pki-common-theme-9.0.3-7.el6.noarch
> ipa-server-selinux-3.0.0-26.el6_4.4.x86_64
> ipa-pki-ca-theme-9.0.3-7.el6.noarch
> ipa-client-3.0.0-26.el6_4.4.x86_64
> ipa-admintools-3.0.0-26.el6_4.4.x86_64
> libipa_hbac-1.9.2-82.10.el6_4.x86_64
> libipa_hbac-python-1.9.2-82.10.el6_4.x86_64
> ipa-python-3.0.0-26.el6_4.4.x86_64
> ipa-server-3.0.0-26.el6_4.4.x86_64
> #
>
> I've found these instructions:
> http://www.freeipa.org/page/Howto/CA_Certificate_Renewal. I've read
> those instructions, and I believe I may have a misconception about
> this process. The procedure calls to:
> # cp /root/ipa.crt /usr/share/ipa/html/ca.crt
> # cp /root/ipa.crt /etc/ipa/ca.crt
>
> Can you clear up what /root/ipa.crt ought to contain? I assume it
> ought to contain *only* the root CA certificate which is the *first*
> key in the bundle provided by the 3rd party Certificate Authority. Is
> that correct?

The instructions you have found do not apply entirely in your situation. 
The file /etc/ipa/ca.crt should contain only the *leaf* CA cert, i.e. 
the one with subject name equal to issuer name in your LDAP/HTTP server 
certs. The file /usr/share/ipa/html/ca.crt should contain the whole CA 
cert chain.

>
> The files /etc/ip/ca.crt already exists, but it is a single
> certificate. The file I have, issued alongside with the certificate by
> GoDaddy, is a CA bundle. It contains 3 public keys in sequence in a
> single file. Could you please be more detailed as to how to accomplish
> this: "you need to import the CA certificate to NSS databases at
> /etc/dirsrv/slapd-DIRSRV_REDACTED, /etc/httpd/alias and
> /etc/pki/nssdb, copy it to /etc/ipa/ca.crt and
> /usr/share/ipa/html/ca.crt and update
> cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com in LDAP with it."

Once you have the correct CA cert in /etc/ipa/ca.crt, you can run the 
following command to import the cert to each NSS database:

     # certutil -d <path> -A -n <nickname> -t C,, -a -i /etc/ipa/ca.crt

(use any nickname you like)

For the LDAP update, see "Update the CA in LDAP" in the instructions you 
have found.

>
> I certainly hope these are not inappropriate questions: I'd just like
> to ensure this is done correctly. Thank you.

Don't worry, these are very appropriate questions ;-)

>
> ---
> Dragan Prostran
>
> On Fri, Oct 24, 2014 at 6:12 AM, Jan Cholasta <jcholast at redhat.com> wrote:
>> Hi,
>>
>> Dne 24.10.2014 v 04:36 Dragan Prostran napsal(a):
>>
>>> Hello,
>>>
>>> This is my first time posting to this list, so if I've made a faux pas
>>> or mistake, please do correct me.
>>>
>>> Can anyone please point me to the correct method to renewing 3rd party
>>> SSL certificates used by FreeIPA 3.0? I suspect I've not done this
>>> correctly.
>>>
>>> Here is what has worked correctly so far:
>>> 1. FreeIPA is installed and configured to work correctly. It uses 3rd
>>> party SSL certificates. I have access to the CSR, the certificate, the
>>> private key, and the new CA bundle.
>>> 2. I have successfully followed these instructions to update the SSL
>>> certificates used by Apache to serve the FreeIPA web interface:
>>> http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP.
>>> Of note is that there are 2 IPA servers, and the procedure has been
>>> followed on both.
>>> 3. Upon visiting the FreeIPA web interface, I can see that the
>>> certificate is valid, and expires in the future. Login to FreeIPA and
>>> modifying (for example) an LDAP password, work correctly.
>>> 4. 3rd party services that take advantage of LDAP work correctly. I
>>> can login and authenticate via LDAP.
>>>
>>> Here is what does not work correctly:
>>> 1. A distinct, 3rd party webservice that takes advantage of LDAP *via
>>> SSL* no longer is able to authenticate. Prior to certificate update
>>> mentioned, this did work correctly. I must admit I'm unfamiliar with
>>> LDAP (via SSL), and so instead of troubleshooting that service, I had
>>> a closer look at the FreeIPA instance.
>>
>>
>> The 3rd party webservice needs to trust the CA certificate of the LDAP
>> server certificate in order for this to work.
>>
>>> 2. When connected to the FreeIPA instance, and issuing 'ipa
>>> user-status username', the following error is returned:
>>>
>>> ipa: ERROR: cert validation failed for "CN=CERT_CN_REDACTED,OU=Domain
>>> Control Validated" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate
>>> issuer has been marked as not trusted by the user.)
>>> ipa: ERROR: cert validation failed for "CN=CERT_CN_REDACTED,OU=Domain
>>> Control Validated" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate
>>> issuer has been marked as not trusted by the user.)
>>> ipa: ERROR: cannot connect to Gettext('any of the configured servers',
>>> domain='ipa', localedir=None): https://IPA1_FQDN_REDACTED/ipa/xml,
>>> https://IPA2_FQDN_REDACTED/ipa/xml
>>>
>>> Note that, CERT_CN_REDACTED is the *.domain.tld cert that has been
>>> renewed. Of note is that, prior to the certificate update noted above,
>>> this did work correctly, and would return the status of the user.
>>
>>
>> This means that the CA certificate of the HTTP server certificate is missing
>> from the NSS database at /etc/pki/nssdb.
>>
>>
>>>
>>> Further, when issuing 'ipa service restart' on the IPA instance, the
>>> following is returned:
>>>
>>> # service ipa restart
>>> Restarting Directory Service
>>> Shutting down dirsrv:
>>>       DIRSRV_REDACTED...                                     [  OK  ]
>>> Starting dirsrv:
>>>       DIRSRV_REDACTED...[21/Oct/2014:19:07:22 -0700] - SSL alert:
>>> CERT_VerifyCertificateNow: verify certificate failed for cert
>>> CERT_CN_REDACTED - GoDaddy.com, Inc. of family
>>> cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8172
>>> - Peer's certificate issuer has been marked as not trusted by the
>>> user.)
>>>                                                              [  OK  ]
>>> Restarting KDC Service
>>> Stopping Kerberos 5 KDC:                                   [  OK  ]
>>> Starting Kerberos 5 KDC:                                   [  OK  ]
>>> Restarting KPASSWD Service
>>> Stopping Kerberos 5 Admin Server:                          [  OK  ]
>>> Starting Kerberos 5 Admin Server:                          [  OK  ]
>>> Restarting MEMCACHE Service
>>> Stopping ipa_memcached:                                    [  OK  ]
>>> Starting ipa_memcached:                                    [  OK  ]
>>> Restarting HTTP Service
>>> Stopping httpd:                                            [  OK  ]
>>> Starting httpd:                                            [  OK  ]
>>> #
>>
>>
>> This means that the CA certificate of the LDAP server certificate is missing
>> from the NSS database at /etc/dirsrv/slapd-DIRSRV_REDACTED.
>>
>>>
>>> Can anyone instruct me as to what may be misconfigured? I assume this
>>> is the root cause of LDAP via SSL not working correctly, but I'm not
>>> quite sure how to verify that.
>>> It is of note to say that the CA bundle (a chain of public keys
>>> leading to a root, 3rd party CA) issued with the new certificate is
>>> different from the previous certificate bundle. I know this as I have
>>> records of the original certificate, key, bundle, and CSR. The CA
>>> bundle issued with this new certificate is *different* from the CA
>>> bundle used with the original certificate. As I have not provided, or
>>> otherwise used, this new CA bundle when renewing the certificates in
>>> FreeIPA, I suspect this is the root cause of the error, and so I ask
>>> for help here.
>>
>>
>> You are right this is the root cause. To fix IPA, you need to import the CA
>> certificate to NSS databases at /etc/dirsrv/slapd-DIRSRV_REDACTED,
>> /etc/httpd/alias and /etc/pki/nssdb, copy it to /etc/ipa/ca.crt and
>> /usr/share/ipa/html/ca.crt and update
>> cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com in LDAP with it.
>>
>>>
>>> ---
>>> Dragan Prostran
>>>
>>
>> Honza
>>
>> --
>> Jan Cholasta
>
>
>


-- 
Jan Cholasta




More information about the Freeipa-users mailing list