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 <jchol...@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

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Reply via email to