[Freeipa-users] Third party SSL certificate renewal

Dragan Prostran dprostran at monexa.com
Fri Oct 24 18:31:09 UTC 2014


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 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."

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

---
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



-- 
Dragan Prostran
System Administrator
Monexa Services Inc.




More information about the Freeipa-users mailing list