Update on the situation... So, we pursued further the idea that the new ca.crt should be in these two LDAP entries:
# ldapsearch -D "cn=Directory Manager" -W -b 'cn=CAcert,cn=ipa,cn=etc,dc=EXAMPLE,dc=com' # ldapsearch -x -D 'cn=Directory manager' -W -b 'cn=EXAMPLE.COM IPA CA,cn=certificates,cn=ipa,cn=etc,dc=EXAMPLE,dc=com' (Both listed there: https://www.freeipa.org/page/V4/CA_certificate_renewal as a place to go and check.) And decided to give it a try. Now "ipa-client-install" works on a new host! We are not out of the wood yet, as the "ipa-getcert resubmit -i 20180228054512" command still fail to renew certificate. We checked every certificates in this great list: https://www.freeipa.org/page/V3/Certificate_renewal So back to debug. # sudo journalctl -xe -t certmonger | more does not give us any entry. We run again: #SSL_DIR=/etc/httpd/alias/ curl -v -o /dev/null --cacert /etc/ipa/ca.crt https://ds01.EXAMPLE.com:8443/ca/agent/ca/profileReview And get same error again: # NSS error -8172 (SEC_ERROR_UNTRUSTED_ISSUER) # * Peer's certificate issuer has been marked as not trusted by the user. Back to the Trouble shooting post: https://floblanc.wordpress.com/2016/12/19/troubleshooting-certmonger-issues-with-freeipa/ and having hard time to find error_logs that would help. Steph -----Original Message----- From: Stéphane Mehat Sent: Monday, March 12, 2018 4:03 PM To: 'Florence Blanc-Renaud' <f...@redhat.com>; FreeIPA users list <freeipa-users@lists.fedorahosted.org> Cc: Bhavin Vaidya <bhavin.vai...@arteris.com> Subject: RE: [Freeipa-users] Untrusted Peer certificate after CA renewal Thank you Flo. I confirmed that ldapsearch -LLL -D 'cn=directory manager' -W -b 'uid=ipara,ou=people,o=ipaca' and serial number are the same than the ra-agent.pem. [root@ds01 ~]# ldapsearch -LLL -D 'cn=directory manager' -W -b 'uid=ipara,ou=people,o=ipaca' Enter LDAP Password: dn: uid=ipara,ou=people,o=ipaca objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: cmsuser uid: ipara sn: ipara cn: ipara usertype: agentType userstate: 1 userCertificate:: MIIDbz[...]Aq+3Ah9Hw== description: 2;1342111857;CN=Certificate Authority,O=ARTERIS.COM;CN=IPA RA,O=ARTERIS.COM When we did ipa-certupdate, at the beginning of all of this, we got this: ############### [root@ds01 ~]# ipa-certupdate trying https://ds01.EXAMPLE.com/ipa/session/json [try 1]: Forwarding 'schema' to json server 'https://ds01.EXAMPLE.com/ipa/session/json' trying https://ds01.EXAMPLE.com/ipa/json [try 1]: Forwarding 'ca_is_enabled' to json server 'https://ds01.EXAMPLE.com/ipa/json' [try 1]: Forwarding 'ca_find/1' to json server 'https://ds01.EXAMPLE.com/ipa/json' failed to update EXAMPLE.COM IPA CA in /etc/dirsrv/slapd-EXAMPLE-COM: Command '/usr/bin/certutil -d /etc/dirsrv/slapd-EXAMPLE-COM -A -n EXAMPLE.COM IPA CA -t CT,C,C -f /etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt' returned non-zero exit status 255 failed to update EXAMPLE.COM IPA CA in /etc/httpd/alias: Command '/usr/bin/certutil -d /etc/httpd/alias -A -n EXAMPLE.COM IPA CA -t CT,C,C -f /etc/httpd/alias/pwdfile.txt' returned non-zero exit status 255 failed to update EXAMPLE.COM IPA CA in /etc/ipa/nssdb: Command '/usr/bin/certutil -d /etc/ipa/nssdb -A -n EXAMPLE.COM IPA CA -t CT,C,C -f /etc/ipa/nssdb/pwdfile.txt' returned non-zero exit status 255 Systemwide CA database updated. Systemwide CA database updated. The ipa-certupdate command was successful ################## And ended up updating the entries manually so IPA can start, otherwise it was failing to start Checking my notes, there is one certificate in LDAP that is different and seems to be the old CA certificate and could be the culprit: ################# [root@ds01 ~]# ldapsearch -x -D 'cn=Directory manager' -W -b 'cn=EXAMPLE.COM IPA CA,cn=certificates,cn=ipa,cn=etc,dc=EXAMPLE,dc=com' Enter LDAP Password: # extended LDIF # # LDAPv3 # base <cn=EXAMPLE.COM IPA CA,cn=certificates,cn=ipa,cn=etc,dc=EXAMPLE,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # EXAMPLE.COM IPA CA, certificates, ipa, etc, EXAMPLE.com dn: cn=EXAMPLE.COM IPA CA,cn=certificates,cn=ipa,cn=etc,dc=EXAMPLE,dc=com ipaConfigString: ipaCa ipaCertSubject: CN=Certificate Authority,O=EXAMPLE.COM ipaKeyTrust: trusted cACertificate;binary:: MIID[..]1eAMZu0AaUw== ipaPublicKey:: MIIBIj[..]wIDAQAB ipaCertIssuerSerial: CN=Certificate Authority,O=EXAMPLE.COM;1 objectClass: ipaCertificate objectClass: pkiCA objectClass: ipaKeyPolicy objectClass: top cn: EXAMPLE.COM IPA CA ipaKeyExtUsage: 1.3.6.1.5.5.7.3.1 ipaKeyExtUsage: 1.3.6.1.5.5.7.3.2 ipaKeyExtUsage: 1.3.6.1.5.5.7.3.3 ipaKeyExtUsage: 1.3.6.1.5.5.7.3.4 ipaKeyExtUsage: 1.3.6.1.5.2.3.5 ipaKeyExtUsage: 1.3.6.1.5.2.3.4 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ########################## Looks like this one should be the new ca.crt. How do I get the public key that goes with new certificate? In the meantime, we are searching the log to see if we can find issues with IPA RA. Steph -----Original Message----- From: Florence Blanc-Renaud [mailto:f...@redhat.com] Sent: Monday, March 12, 2018 12:08 PM To: Stéphane Mehat <stephane.me...@arteris.com>; FreeIPA users list <freeipa-users@lists.fedorahosted.org> Cc: Bhavin Vaidya <bhavin.vai...@arteris.com> Subject: Re: [Freeipa-users] Untrusted Peer certificate after CA renewal On 03/12/2018 06:52 PM, Stéphane Mehat wrote: > Thank you Flo! > > Yes I checked all certificates with "openssl x509 -noout -text" as suggested > in one of your post. We have most recent one. > > We did not check curl as we ran an rpm update to make sure we have all same > version of IPA across the board. > > [root@ds01 ~]# curl -V > curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.28.4 > zlib/1.2.7 libidn/1.28 libssh2/1.4.3 > Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps > pop3 pop3s rtsp scp sftp smtp smtps telnet tftp > Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL > libz unix-sockets > > Looks like they have 7.58 now... we are going to give it a try. > > How do I know if connected to NSS? That is more likely connect to OpenSSL. Hi, the output of curl -V shows "NSS/3.28.4" meaning that is was compiled with NSS support, so you're good from this point of view. > > Thank you for confirming regarding ipaCert? We have both key and PEM. I am > removing that entry then. > Are we still supposed to have IPA CA agent certificates or those have been > removed? Certificate published at uid=admin,ou=people,o=ipaca are expired, > but I don't know how to renew these (assuming that would be the culprit, but > could be as this is the user we are using for the install). The entry uid=ipara,ou=people,o=ipaca must contain the most up-to-date certificate ipaCert (the one in /var/lib/ipa/ra-agent.pem). If it is not the case, you can perform ldapmodify directly to update the entry. You will need to note the certificate serial number: $ openssl x509 -noout -text -in /var/lib/ipa/ra-agent.pem | grep Serial And you will also need the Issuer, usually CN=Certificate Authority,O=DOMAIN.COM (replace DOMAIN.COM with your domain), and Subject, usually CN=IPA RA,O=DOMAIN.COM (replace DOMAIN.COM with your domain). Then create a ldif file for the modification: $ cat updatecert.ldif dn: uid=ipara,ou=people,o=ipaca changetype: modify add: userCertificate usercertificate:: MII... - replace: description description: 2;Serial;Issuer;Subject where: - you replace MII... with the new ipaCert certificate (obtained from /var/lib/ipa/ra-agent.pem without the header and footer, and pasted in a single line - you replace "Serial" with the Serial number obtained previously, and the Issuer and Subject with the values for your domain. Then call ldapmodify: ldapmodify -D "cn=Directory Manager" -W -f updatecert.ldif Note that the ldap entry should have been updated when the cert was renewed, and you may find information about the failure in the journal. There were issues in previous releases with SElinux enabled. HTH, Flo > > Steph > > -----Original Message----- > From: Florence Blanc-Renaud [mailto:f...@redhat.com] > Sent: Monday, March 12, 2018 10:22 AM > To: FreeIPA users list <freeipa-users@lists.fedorahosted.org> > Cc: Bhavin Vaidya <bhavin.vai...@arteris.com>; Stéphane Mehat > <stephane.me...@arteris.com> > Subject: Re: [Freeipa-users] Untrusted Peer certificate after CA > renewal > > On 03/12/2018 01:54 PM, Stéphane Mehat via FreeIPA-users wrote: >> This is my first post, so I hope I don’t add too much details to my >> questions, but we spent so much time on that issue that I feel like I >> need to provide as much detail as possible 😉 >> >> We need your help !!! >> >> After weeks of reading and attempt to fix our certificates, we can't >> find what is wrong. >> >> Not sure if that is a freeIPA issue or just conflict between >> ipa-tomcat and openssl on same server. After CA and other certificate >> renewal, we are having bunch of issues. >> >> We used to be able to install client and create replica, but in our >> attempt to create a new CA replica, and after upgrading to most >> recent versions and renewing certificates, including CA certificates, >> >> we still truggle to get certificates to be trusted. >> >> Both LDAP and HTTPd certificates don't renew with same error in >> certmonger: "ipa-getcert resubmit -i 20180228054516" >> >> status: CA_UNREACHABLE >> >> ca-error: Server at https://ds01.EXAMPLE.com/ipa/xml failed >> request, will retry: 907 (RPC failed at server. cannot connect to >> 'https://ds01.EXAMPLE.com:443/ca/rest/account/login': [SSL: >> SSL_HANDSHAKE_FAILURE] ssl handshake failure (_ssl.c:1783)). >> >> We went through the great tutorial from Flo, trying to debug this. >> >> https://floblanc.wordpress.com/2016/12/19/troubleshooting-certmonger- >> i >> ssues-with-freeipa/ >> >> All certificates looks fine and current, even both Ldapd and HTTPd. >> We added the ipaCert in the NSS DB as it was gone after upgrade to >> IPAv4.5, but that did not fix the issue. >> >> [root@ds01 ~]# certutil -K -d /etc/httpd/alias/ -f >> /etc/httpd/alias/pwdfile.txt >> >> certutil: Checking token "NSS Certificate DB" in slot "NSS User >> Private Key and Certificate Services" >> >> < 0> rsa ##key1## ipaCert >> >> < 1> rsa ##key2## NSS Certificate DB:Server-Cert >> >> Certificate in "certutil -L -d /etc/httpd/alias/ -n ipaCert -a" is >> different than ca.crt, but same as >> >> dn: uid=ipara,ou=people,o=ipaca >> >> ca.crt is registered in the LDAP at: >> >> dn: cn=caSigningCert >> cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=EXAMPLE,dc=com >> >> Only thing that we can found with expired certificates is entry: >> >> [root@ds01 ~]# ldapsearch -LLL -D 'cn=directory manager' -W -b >> uid=admin,ou=people,o=ipaca >> >> That shows one userPassword, and 2 different userCertificate that are >> expired several year ago with description: >> >> description: 2;6;CN=Certificate >> Authority,O=EXAMPLE.COM;CN=ipa-ca-agent,O=EXAMPLE.COM >> >> description: 2;268304414;CN=Certificate >> Authority,O=EXAMPLE.COM;E=ad...@example.com,CN=CS >> Administrator,UID=admin,OU=ca,O=EXAMPLE.COM,C=US >> >> Not sure if this is an old V3 LDAP entry, not used in V4 or if that >> is the culprit and how to fix it?? >> >> We tried 'SSL_DIR=/etc/httpd/alias/ curl -v -o /dev/null --cacert >> /etc/ipa/ca.crt https://`hostname`:8443/ca/agent/ca/profileReview >> <https://%60hostname%60:8443/ca/agent/ca/profileReview>' >> >> recommended by https://rcritten.wordpress.com/ >> >> But still same trust issue. >> >> Our issue seems similar than the one discribed in: >> >> https://lists.fedorahosted.org/archives/list/freeipa-us...@lists.fedo >> r ahosted.org/thread/XSMWWPJU2VRUIGE6SRAHYAJF7BYBCNOE/ >> >> So we tried to reset the trust flag, but that did not fix the issue for us. >> >> Looking at the error_log we have: >> >> [:error] [pid 14205] ipa: INFO: [jsonserver_session] >> ad...@example.com >> <mailto:ad...@example.com>: ca_find(None, version=u'2.228'): SUCCESS >> >> [:error] [pid 14205] ipa: DEBUG: Destroyed connection >> context.ldap2_94559091634256 >> >> [:warn] [pid 14208] [client 192.168.10.217:63438] failed to set perms >> (3140) on file (/var/run/ipa/ccaches/ad...@example.com >> <mailto:/var/run/ipa/ccaches/ad...@example.com>)!, referer: >> https://ds01.EXAMPLE.com/ipa/ui/ >> >> We have both openldap and pki-tomecat on that master, not sure if >> that is what is creating issue since renewal of CA or if CRL used to >> be another server. >> >> Any Idea of what could be wrong here? >> >> Answer is probably as easy as adding one of the certificate to the >> NSS trust database, but not sure which one. :-( >> >> ################### >> >> Here is what we get when installing client: >> >> [root@ds12 ~]# ipa-client-install >> >> Skip ds12.EXAMPLE.com: LDAP server is not responding, unable to >> verify if this is an IPA server >> >> Discovery was successful! >> >> Client hostname: ds12.EXAMPLE.com >> >> Realm: EXAMPLE.COM >> >> DNS Domain: EXAMPLE.com >> >> IPA Server: ds01.EXAMPLE.com >> >> BaseDN: dc=EXAMPLE,dc=com >> >> Continue to configure the system with these values? [no]: yes >> >> Synchronizing time with KDC... >> >> Attempting to sync time using ntpd. Will timeout after 15 seconds >> >> User authorized to enroll computers: admin >> >> Password for ad...@example.com <mailto:ad...@example.com>: >> >> Successfully retrieved CA cert >> >> Subject: CN=Certificate Authority,O=EXAMPLE.COM >> >> Issuer: CN=Certificate Authority,O=EXAMPLE.COM >> >> Valid From: 2014-08-03 19:28:18 >> >> Valid Until: 2034-08-03 19:28:18 >> >> Joining realm failed: libcurl failed to execute the HTTP POST >> transaction, explaining: Peer's certificate issuer has been marked >> as not trusted by the user. >> >> [root@ds01 alias]# ipa config-show >> >> Certificate Subject base: O=EXAMPLE.COM >> >> IPA masters: ds01.EXAMPLE.com, ds02.EXAMPLE.com, ds03.EXAMPLE.com >> >> IPA CA servers: ds01.EXAMPLE.com, ds03.EXAMPLE.com >> >> IPA NTP servers: ds01.EXAMPLE.com, ds02.EXAMPLE.com >> >> IPA CA renewal master: ds01.EXAMPLE.com >> >> [root@ds01 ~]# ipa server-role-find --role "AD trust controller" >> >> ---------------------- >> >> 3 server roles matched >> >> ---------------------- >> >> Server name: ds01.EXAMPLE.com >> >> Role name: AD trust controller >> >> Role status: absent >> >> Server name: ds02.EXAMPLE.com >> >> Role name: AD trust controller >> >> Role status: absent >> >> Server name: ds03.EXAMPLE.com >> >> Role name: AD trust controller >> >> Role status: absent >> >> ---------------------------- >> >> Number of entries returned 3 >> >> ---------------------------- >> >> [root@ds01 ~]# getcert list >> >> Number of certificates and requests being tracked: 9. >> >> Request ID '20180228053337': >> >> status: MONITORING >> >> stuck: no >> >> key pair storage: >> type=FILE,location='/var/kerberos/krb5kdc/kdc.key' >> >> certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt' >> >> CA: SelfSign >> >> issuer: CN=ds01.EXAMPLE.com,O=EXAMPLE.COM >> >> subject: CN=ds01.EXAMPLE.com,O=EXAMPLE.COM >> >> expires: 2019-03-07 06:24:12 UTC >> >> principal name: krbtgt/example....@example.com >> <mailto:krbtgt/example....@example.com> >> >> certificate template/profile: KDCs_PKINIT_Certs >> >> pre-save command: >> >> post-save command: >> /usr/libexec/ipa/certmonger/renew_kdc_cert >> >> track: yes >> >> auto-renew: yes >> >> Request ID '20180228054506': >> >> status: MONITORING >> >> stuck: no >> >> key pair storage: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSignin >> g Cert cert-pki-ca',token='NSS Certificate DB',pin set >> >> certificate: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSignin >> g Cert cert-pki-ca',token='NSS Certificate DB' >> >> CA: dogtag-ipa-ca-renew-agent >> >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> >> subject: CN=CA Audit,O=EXAMPLE.COM >> >> expires: 2020-02-25 04:27:49 UTC >> >> key usage: digitalSignature,nonRepudiation >> >> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad >> >> post-save command: >> /usr/libexec/ipa/certmonger/renew_ca_cert >> "auditSigningCert cert-pki-ca" >> >> track: yes >> >> auto-renew: yes >> >> Request ID '20180228054507': >> >> status: MONITORING >> >> stuck: no >> >> key pair storage: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigning >> C ert cert-pki-ca',token='NSS Certificate DB',pin set >> >> certificate: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigning >> C ert cert-pki-ca',token='NSS Certificate DB' >> >> CA: dogtag-ipa-ca-renew-agent >> >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> >> subject: CN=OCSP Subsystem,O=EXAMPLE.COM >> >> expires: 2020-02-25 04:28:38 UTC >> >> eku: id-kp-OCSPSigning >> >> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad >> >> post-save command: >> /usr/libexec/ipa/certmonger/renew_ca_cert >> "ocspSigningCert cert-pki-ca" >> >> track: yes >> >> auto-renew: yes >> >> Request ID '20180228054508': >> >> status: MONITORING >> >> stuck: no >> >> key pair storage: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCe >> r t cert-pki-ca',token='NSS Certificate DB',pin set >> >> certificate: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCe >> r t cert-pki-ca',token='NSS Certificate DB' >> >> CA: dogtag-ipa-ca-renew-agent >> >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> >> subject: CN=CA Subsystem,O=EXAMPLE.COM >> >> expires: 2020-02-25 04:31:47 UTC >> >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> >> eku: id-kp-serverAuth,id-kp-clientAuth >> >> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad >> >> post-save command: >> /usr/libexec/ipa/certmonger/renew_ca_cert >> "subsystemCert cert-pki-ca" >> >> track: yes >> >> auto-renew: yes >> >> Request ID '20180228054509': >> >> status: MONITORING >> >> stuck: no >> >> key pair storage: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCe >> r t cert-pki-ca',token='NSS Certificate DB',pin set >> >> certificate: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCe >> r t cert-pki-ca',token='NSS Certificate DB' >> >> CA: dogtag-ipa-ca-renew-agent >> >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> >> subject: CN=Certificate Authority,O=EXAMPLE.COM >> >> expires: 2038-03-07 03:47:46 UTC >> >> key usage: >> digitalSignature,nonRepudiation,keyCertSign,cRLSign >> >> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad >> >> post-save command: >> /usr/libexec/ipa/certmonger/renew_ca_cert >> "caSigningCert cert-pki-ca" >> >> track: yes >> >> auto-renew: yes >> >> Request ID '20180228054510': >> >> status: MONITORING >> >> stuck: no >> >> key pair storage: type=FILE,location='/var/lib/ipa/ra-agent.key' >> >> certificate: type=FILE,location='/var/lib/ipa/ra-agent.pem' >> >> CA: dogtag-ipa-ca-renew-agent >> >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> >> subject: CN=IPA RA,O=EXAMPLE.COM >> >> expires: 2018-06-15 23:15:23 UTC >> >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> >> eku: id-kp-serverAuth,id-kp-clientAuth >> >> pre-save command: >> /usr/libexec/ipa/certmonger/renew_ra_cert_pre >> >> post-save command: >> /usr/libexec/ipa/certmonger/renew_ra_cert >> >> track: yes >> >> auto-renew: yes >> >> Request ID '20180228054511': >> >> status: MONITORING >> >> stuck: no >> >> key pair storage: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert >> cert-pki-ca',token='NSS Certificate DB',pin set >> >> certificate: >> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert >> cert-pki-ca',token='NSS Certificate DB' >> >> CA: dogtag-ipa-ca-renew-agent >> >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> >> subject: CN=ds01.EXAMPLE.com,O=EXAMPLE.COM >> >> expires: 2018-12-16 21:02:44 UTC >> >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> >> eku: >> id-kp-serverAuth,id-kp-clientAuth,id-kp-emailProtection >> >> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad >> >> post-save command: >> /usr/libexec/ipa/certmonger/renew_ca_cert >> "Server-Cert cert-pki-ca" >> >> track: yes >> >> auto-renew: yes >> >> Request ID '20180228054512': >> >> status: CA_UNREACHABLE >> >> ca-error: Server at https://ds01.EXAMPLE.com/ipa/xml failed >> request, will retry: 907 (RPC failed at server. cannot connect to >> 'https://ds01.EXAMPLE.com:443/ca/rest/account/login': [SSL: >> SSL_HANDSHAKE_FAILURE] ssl handshake failure (_ssl.c:1783)). >> >> stuck: no >> >> key pair storage: >> type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server- >> C >> ert',token='NSS Certificate >> DB',pinfile='/etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt' >> >> certificate: >> type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server- >> C >> ert',token='NSS >> Certificate DB' >> >> CA: IPA >> >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> >> subject: CN=ds01.EXAMPLE.com,O=EXAMPLE.COM >> >> expires: 2020-03-07 08:49:36 UTC >> >> principal name: ldap/ds01.example....@example.com >> <mailto:ldap/ds01.example....@example.com> >> >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> >> eku: id-kp-serverAuth,id-kp-clientAuth >> >> pre-save command: >> >> post-save command: >> /usr/libexec/ipa/certmonger/restart_dirsrv >> EXAMPLE-COM >> >> track: yes >> >> auto-renew: yes >> >> Request ID '20180228054516': >> >> status: CA_UNREACHABLE >> >> ca-error: Server at https://ds01.EXAMPLE.com/ipa/xml failed >> request, will retry: 907 (RPC failed at server. cannot connect to >> 'https://ds01.EXAMPLE.com:443/ca/rest/account/login': [SSL: >> SSL_HANDSHAKE_FAILURE] ssl handshake failure (_ssl.c:1783)). >> >> stuck: no >> >> key pair storage: >> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token=' >> N SS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> >> certificate: >> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token=' >> N >> SS >> Certificate DB' >> >> CA: IPA >> >> issuer: CN=Certificate Authority,O=EXAMPLE.COM >> >> subject: CN=ds01.EXAMPLE.com,O=EXAMPLE.COM >> >> expires: 2020-03-07 08:49:51 UTC >> >> principal name: HTTP/ds01.example....@example.com >> <mailto:HTTP/ds01.example....@example.com> >> >> key usage: >> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment >> >> eku: id-kp-serverAuth,id-kp-clientAuth >> >> pre-save command: >> >> post-save command: >> /usr/libexec/ipa/certmonger/restart_httpd >> >> track: yes >> >> auto-renew: yes >> >> [root@ds01 ~]# certutil -L -d /etc/httpd/alias/ -n ipaCert >> >> Certificate: >> >> Data: >> >> Version: 3 (0x2) >> >> Serial Number: 1342111857 (0x4fff0071) >> >> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption >> >> Issuer: "CN=Certificate Authority,O=EXAMPLE.COM" >> >> Validity: >> >> Not Before: Sat Jun 25 23:15:23 2016 >> >> Not After : Fri Jun 15 23:15:23 2018 >> >> Subject: "CN=IPA RA,O=EXAMPLE.COM" >> >> [..] >> >> Location: >> >> URI: "http://ds01.EXAMPLE.com:80/ca/ocsp"; >> >> [..] >> >> Mozilla-CA-Policy: false (attribute missing) >> >> Certificate Trust Flags: >> >> SSL Flags: >> >> Valid CA >> >> Trusted CA >> >> User >> >> Trusted Client CA >> >> Email Flags: >> >> Valid CA >> >> Trusted CA >> >> User >> >> Object Signing Flags: >> >> Valid CA >> >> Trusted CA >> >> User >> >> ################################### >> >> [root@ds01 ~]# SSL_DIR=/etc/httpd/alias/ curl -v -o /dev/null >> --cacert /etc/ipa/ca.crt >> https://`hostname`:8443/ca/agent/ca/profileReview >> <https://%60hostname%60:8443/ca/agent/ca/profileReview> >> >> % Total % Received % Xferd Average Speed Time Time Time >> Current >> >> Dload Upload Total Spent Left >> Speed >> >> 0 0 0 0 0 0 0 0 --:--:-- --:--:-- >> --:--:-- 0* About to connect() to ds01.EXAMPLE.com port 8443 (#0) >> >> * Trying 192.168.10.146... >> >> * Connected to ds01.EXAMPLE.com (192.168.10.146) port 8443 (#0) >> >> * Initializing NSS with certpath: sql:/etc/httpd/alias/ >> >> * CAfile: /etc/ipa/ca.crt >> >> CApath: none >> >> 0 0 0 0 0 0 0 0 --:--:-- --:--:-- >> --:--:-- 0* Server certificate: >> >> * subject: CN=ds01.EXAMPLE.com,O=EXAMPLE.COM >> >> * start date: Dec 26 21:02:44 2016 GMT >> >> * expire date: Dec 16 21:02:44 2018 GMT >> >> * common name: ds01.EXAMPLE.com >> >> * issuer: CN=Certificate Authority,O=EXAMPLE.COM >> >> * NSS error -8172 (SEC_ERROR_UNTRUSTED_ISSUER) >> >> * Peer's certificate issuer has been marked as not trusted by the user. >> >> 0 0 0 0 0 0 0 0 --:--:-- --:--:-- >> --:--:-- 0 >> >> * Closing connection 0 >> >> curl: (60) Peer's certificate issuer has been marked as not trusted >> by the user. >> >> More details here: http://curl.haxx.se/docs/sslcerts.html >> >> curl performs SSL certificate verification by default, using a "bundle" >> >> of Certificate Authority (CA) public keys (CA certs). If the default >> >> bundle file isn't adequate, you can specify an alternate file >> >> using the --cacert option. >> >> If this HTTPS server uses a certificate signed by a CA represented in >> >> the bundle, the certificate verification probably failed due to a >> >> problem with the certificate (it might be expired, or the name might >> >> not match the domain name in the URL). >> >> If you'd like to turn off curl's verification of the certificate, use >> >> the -k (or --insecure) option. >> >> Steph >> >> >> >> _______________________________________________ >> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org >> To unsubscribe send an email to >> freeipa-users-le...@lists.fedorahosted.org >> > > Hi, > > based on the output of the curl command, I would first check if > /etc/ipa/ca.crt contains the most recent certificate for IPA CA (since you > mentioned that IPA CA has been renewed). The file can contain multiple > certificates (delimited by -----BEGIN CERTIFICATE----- and -----END > CERTIFICATE-----) corresponding to the original and renewed IPA CA + external > CA if applicable. > You can use "openssl x509 -noout -text" on each of these certs to see their > details, especially the Validity. > > If the file does not contain the most recent IPA CA, then use ipa-certupdate > in order to put the latest cert in all the relevant NSS DBs and files. > > The second thing to check is the version of libcurl that you are using: > curl -V > libcurl can either be linked with NSS or with OpenSSL. With FreeIPA 4.5, > libcurl should be linked with NSS. > > And finally you mentioned that you had to put ipaCert back into > /etc/httpd/alias because it disappeared with the upgrade to 4.5, but this is > expected as it is now stored in /var/lib/ipa/ra-agent.key and > /var/lib/ipa/ra-agent.pem. > > Flo > _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
