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 <[email protected]> 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. -- 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
