Trying to make a few more progress... but just getting more questions

 

Checking /etc/httpd/conf.d/nss.conf, we don't see anything unusual.

 

Httpd is correctly listening on port 443.

 

It does point to Server-cert as TLS certificate, which is the one client gets when connecting to the ipa WebGUI.

TLS session cache is valid 24hours, so maybe we have to wait for the issue to clear out.

 

We could turn off NSSRequireSafeNegotiation to facilitate handshakes but we did not try that for now, should we?

 

So far we are still getting the following error:

##############

NetworkError: cannot connect to 'https://ds01.EXAMPLE.com:443/ca/agent/ca/displayBySerial': [SSL: SSL_HANDSHAKE_FAILURE] ssl handshake failure (_ssl.c:1783)

ipa: INFO: [jsonserver_session] admin@EXAMPLE.COM: cert_show(u'1', cacn=u'ipa', all=True, version=u'2.228'): NetworkError

ipa: DEBUG: Destroyed connection context.ldap2_94839866312144

Re-negotiation handshake failed: Not accepted by client!?           

SSL Library Error: -12285 Unable to find the certificate or key necessary for authentication

##############

 

File password.conf is present: /etc/httpd/conf/password.conf

and includes: internal:aa6[..]6857

and is same password as /etc/httpd/alias/pwdfile.txt used to import certificate in /etc/httpd/alias (minus 'internal')

and same as  /etc/httpd/alias/pin.txt

 

We checked again that pem and key are same pair:

echo "--Certificate:" && openssl x509 -noout -modulus -in /var/lib/ipa/ra-agent.pem && echo "--Key:" && openssl rsa -noout -modulus -in /var/lib/ipa/ra-agent.key

 

Also we used to have ipa.keytab file in this directory /etc/httpd/conf. Is it removed in V4.5 or is it missing?

 

/etc/dirsrv/slapd-EXAMPLE-COM/pin.txt

/etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt

 

We don't see any specific mapping in /etc/dirsrv/config/certmap.conf. Not sure if we should have some.

 

Looking further at the error, it really looks similar to this:

https://www.redhat.com/archives/freeipa-users/2017-April/msg00028.html

Except we have a selfsign certificate. Could it be that it is acting like it is not selfsign?

 

Current CA certificate is in /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

Current Server-Cert is in /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt as trusted certificate, but we added that one here. Should it be an other one?

 

This thing is killing us. I am sure this is simple thing we did not do somewhere as always!!

 

Stephane

 

-----Original Message-----
From: Stéphane Mehat via FreeIPA-users [mailto:freeipa-users@lists.fedorahosted.org]
Sent: Thursday, March 15, 2018 9:42 AM
To: Florence Blanc-Renaud <flo@redhat.com>; FreeIPA users list <freeipa-users@lists.fedorahosted.org>
Cc: Bhavin Vaidya <bhavin.vaidya@arteris.com>; Stéphane Mehat <stephane.mehat@arteris.com>
Subject: [Freeipa-users] Re: Untrusted Peer certificate after CA renewal

 

Making progress...

 

Alright, so we checked the files permissions and owner:

 

-r--r--r-- 1 root root 1313 Mar  9 00:24 /etc/ipa/ca.crt

-r--r----- 1 root ipaapi 1854 Mar  7 19:11 /var/lib/ipa/ra-agent.key

-r--r----- 1 root ipaapi 1451 Mar  7 19:11 /var/lib/ipa/ra-agent.pem

 

CA was not correct, so we fixed it.

-rw-r--r-- 1 root ipaapi 1313 Mar  9 00:24 /etc/ipa/ca.crt

 

But that did not fix our issue. (Still good to clean things up)

 

We got the cert_request error in the log file, as described by Flo but does not seems to be an issue anymore (see here after)

 

###################################

Then, reading an other bug report, we checked /var/log/ipaupgrade.log and identified that upgrade had errors.

 

So we ran it again! which added quite a bunch of certificates to certmonger and also fixed the error flag. Now it says 'MONITORING'.

Not sure if we want to resubmit again to see if it fails...

 

See bellow what has been done by the upgrade.

 

But no need to resubmit the certificate to see we still have an issue. We still get same IPA Error 907:NetworkError when we try to show a certificate in the Authentication tab (GUI):

#An error has occurred (IPA Error 907: NetworkError) #cannot connect to 'https://ds01.EXAMPLE.com:443/ca/agent/ca/displayBySerial': [SSL: SSL_HANDSHAKE_FAILURE] ssl handshake failure (_ssl.c:1783)

 

back to the /var/log/httpd/error_log we still have same:

 

#ipa: DEBUG: WSGI wsgi_dispatch.__call__:

#ipa: DEBUG: WSGI jsonserver_session.__call__:

#ipa: DEBUG: Created connection context.ldap2_94728002512656

#ipa: DEBUG: WSGI jsonserver.__call__:

#ipa: DEBUG: WSGI WSGIExecutioner.__call__:

#ipa: DEBUG: raw: cert_show(u'1', cacn=u'ipa', all=True, version=u'2.228')

#ipa: DEBUG: cert_show(1, cacn=u'ipa', chain=False, all=True, raw=False, version=u'2.228', no_members=False)

#ipa: DEBUG: raw: ca_is_enabled(version=u'2.228')

#ipa: DEBUG: ca_is_enabled(version=u'2.228')

#ipa: DEBUG: ra.get_certificate()

#ipa: DEBUG: request POST https://ds01.EXAMPLE.com:443/ca/agent/ca/displayBySerial

#ipa: DEBUG: request body 'xml=true&serialNumber=1'

# Bad remote server certificate: -8179

# SSL Library Error: -8179 Certificate is signed by an unknown issuer # Re-negotiation handshake failed: Not accepted by client!?

# ipa: DEBUG: httplib request failed:

 

Checked the TLS certificate from WebGUI of ds01.EXAMPLE.COM in Firefox. As expected, it is most recent certificate that is also in  #/usr/bin/certutil -L -d /etc/httpd/alias -n 'Server-Cert' -a and certificate shows up in the certificate list of the WebGUI with correct serial number 4F:FF:02:25 (1342112293)

 

#openssl s_client -connect ds01.EXAMPLE.com:443 -showcerts # gives us the correct certificate chain with Server-Cert and CA certificates.

 

I still don't get why we get that SSL Library Error. And I can get the browser to show the certificate that the WebGUI is using connect and show the requested certificate. I feel like the issue is client cannot validate the certificate with the Authority Certificate, going to osc:ipa-ca.EXAMPLE.com as I get same error going to  https://ds01.EXAMPLE.com:443/ca/agent/ca/displayBySerial. How can I check what TLS certificate is ipa-ca using? Looks like it is redirecting on ds01.EXAMPLE.com so I would guess Server-Cert, but can't confirm. Could it be that Server-Cert subject is for ds01, not ipa-ca?

 

cert_request  was also failing doing "request GET https://ds01.EXAMPLE.com:443/ca/rest/account/login". So probably same issue.

 

 

###################################

[root@ds01 certs]# ipa-server-upgrade manually Upgrading IPA:. Estimated time: 1 minute 30 seconds

  [1/10]: stopping directory server

  [2/10]: saving configuration

  [3/10]: disabling listeners

  [4/10]: enabling DS global lock

  [5/10]: starting directory server

  [6/10]: updating schema

  [7/10]: upgrading server

  [8/10]: stopping directory server

  [9/10]: restoring configuration

  [10/10]: starting directory server

Done.

Update complete

Upgrading IPA services

Upgrading the configuration of the IPA services [Verifying that root certificate is published] [Migrate CRL publish directory] CRL tree already moved [Verifying that CA proxy configuration is correct] [Verifying that KDC configuration is using ipa-kdb backend] [Fix DS schema file syntax] Syntax already fixed [Removing RA cert from DS NSS database] RA cert already removed [Enable sidgen and extdom plugins by default] [Updating HTTPD service IPA configuration] [Updating mod_nss protocol versions] Protocol versions already updated [Updating mod_nss cipher suite] [Updating mod_nss enabling OCSP] [Fixing trust flags in /etc/httpd/alias] Trust flags already processed [Moving HTTPD service keytab to gssproxy] [Removing self-signed CA] [Removing Dogtag 9 CA] [Checking for deprecated KDC configuration files] [Checking for deprecated backups of Samba configuration files] [Add missing CA DNS records] IPA CA DNS records already processed [Removing deprecated DNS configuration options] [Ensuring minimal number of connections] [Updating GSSAPI configuration in DNS] [Updating pid-file configuration in DNS] [Checking global forwarding policy in named.conf to avoid conflicts with automatic empty zones] Changes to named.conf have been made, restart named [Upgrading CA schema] CA schema update complete (no changes) [Verifying that CA audit signing cert has 2 year validity] [Update certmonger certificate renewal configuration] Configuring certmonger to stop tracking system certificates for CA Certmonger certificate renewal configuration updated [Enable PKIX certificate path discovery and validation] PKIX already enabled [Authorizing RA Agent to modify profiles] [Authorizing RA Agent to manage lightweight CAs] [Ensuring Lightweight CAs container exists in Dogtag database] [Adding default OCSP URI configuration] pki-tomcat configuration changed, restart pki-tomcat [Ensuring CA is using LDAPProfileSubsystem] [Migrating certificate profiles to LDAP] [Ensuring presence of included profiles] [Add default CA ACL] Default CA ACL already added [Set up lightweight CA key retrieval] Creating principal Retrieving keytab Creating Custodia keys Configuring key retriever [Setup PKINIT] The IPA services were upgraded The ipa-server-upgrade command was successful

 

 

-----Original Message-----

From: Florence Blanc-Renaud [mailto:flo@redhat.com]

Sent: Wednesday, March 14, 2018 3:46 AM

To: FreeIPA users list <freeipa-users@lists.fedorahosted.org>

Cc: Bhavin Vaidya <bhavin.vaidya@arteris.com>; Stéphane Mehat <stephane.mehat@arteris.com>

Subject: Re: [Freeipa-users] Re: Untrusted Peer certificate after CA renewal

 

On 03/13/2018 11:36 AM, Stéphane Mehat via FreeIPA-users wrote:

> So went back to the basics of that tutorial.

> https://floblanc.wordpress.com/2016/12/19/troubleshooting-certmonger-i

> ssues-with-freeipa/

>

>

> # getcert modify-ca -c dogtag-ipa-ca-renew-agent -e '/usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit -vv'

>

> Restarted ipa, but don't get any log error when submitting :

> certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB'

> certificate: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB'

>

> Still get:

> #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)).

>

> How do we know if certmonger is even doing anything now to renew certificate?

> Should we just stop following these 2 certificates and follow them again with certmonger?

>

> I got some errors in /var/log/dirsrv/slapd-EXAMPLE-COM/access, but only from one other server we probably did not update certificate yet.

>

>

> Stephane

>

>

> -----Original Message-----

> From: Stéphane Mehat

> Sent: Tuesday, March 13, 2018 12:26 AM

> To: 'Florence Blanc-Renaud' <flo@redhat.com>; 'FreeIPA users list'

> <freeipa-users@lists.fedorahosted.org>

> Cc: Bhavin Vaidya <bhavin.vaidya@arteris.com>

> Subject: RE: [Freeipa-users] Untrusted Peer certificate after CA

> renewal

>

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

> ssues-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' <flo@redhat.com>; FreeIPA users list

> <freeipa-users@lists.fedorahosted.org>

> Cc: Bhavin Vaidya <bhavin.vaidya@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=EXAMPLE.COM;CN=IPA RA,O=EXAMPLE.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:flo@redhat.com]

> Sent: Monday, March 12, 2018 12:08 PM

> To: Stéphane Mehat <stephane.mehat@arteris.com>; FreeIPA users list

> <freeipa-users@lists.fedorahosted.org>

> Cc: Bhavin Vaidya <bhavin.vaidya@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:flo@redhat.com]

>> Sent: Monday, March 12, 2018 10:22 AM

>> To: FreeIPA users list <freeipa-users@lists.fedorahosted.org>

>> Cc: Bhavin Vaidya <bhavin.vaidya@arteris.com>; Stéphane Mehat

>> <stephane.mehat@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=admin@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-users@lists.fed

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

>>> admin@EXAMPLE.COM

>>> <mailto:admin@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/admin@EXAMPLE.COM

>>> <mailto:/var/run/ipa/ccaches/admin@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 admin@EXAMPLE.COM <mailto:admin@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.COM@EXAMPLE.COM

>>> <mailto:krbtgt/EXAMPLE.COM@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='auditSigni

>>> n g Cert cert-pki-ca',token='NSS Certificate DB',pin set

>>> 

>>>            certificate:

>>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigni

>>> n 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='ocspSignin

>>> g C ert cert-pki-ca',token='NSS Certificate DB',pin set

>>> 

>>>            certificate:

>>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSignin

>>> g 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='subsystemC

>>> e r t cert-pki-ca',token='NSS Certificate DB',pin set

>>> 

>>>            certificate:

>>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemC

>>> e 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='caSigningC

>>> e r t cert-pki-ca',token='NSS Certificate DB',pin set

>>> 

>>>            certificate:

>>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningC

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

>>> t cert-pki-ca',token='NSS Certificate DB',pin set

>>> 

>>>            certificate:

>>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cer

>>> t 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.com@EXAMPLE.COM

>>> <mailto:ldap/ds01.EXAMPLE.com@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.com@EXAMPLE.COM

>>> <mailto:HTTP/ds01.EXAMPLE.com@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-leave@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-leave@lists.fedorahosted.org

>

Hi Stéphane,

 

the certificates for which renewal is failing (LDAP and HTTPd) are both handled by the "IPA" helper, which means that certmonger connects to an IPA master, and then the IPA master connects to Dogtag.

 

If you want more information about the operation processing, you can put IPA in debug mode by creating a server.conf file:

$ cat /etc/ipa/server.conf

[global]

debug=True

$ ipactl restart

 

Then retry to renew the cert for LDAP for instance:

$ CERTID=`getcert list -d /etc/dirsrv/slapd-EXAMPLE-COM | grep Request | cut -d"'" -f 2` $ getcert resubmit -i $CERTID

 

Now you should be able to see logs in /var/log/httpd/error_log corresponding to certmonger communication with IPA server. The interesting lines are between lines containing "cert_request".

 

According to your description, the failure happens after the IPA master has received this command, when it tries to connect to Dogtag. The IPA master (running inside httpd process) is using /etc/ipa/ca.crt to trust Dogtag's cert and is authenticating with the ipaCert.

Can you check the permissions on /etc/ipa/ca.crt and /var/lib/ipa/ra-agent.key /var/lib/ipa/ra-agent.pem? As the process is running as apache user, we need -rw-r--r-- for /etc/ipa/ca.crt and

-r--r----- for the ra-agent.

 

Flo

_______________________________________________

FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org

To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org