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
#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
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
. How can I check what TLS
certificate is ipa-ca using? Looks like it is redirecting on
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
;. 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(a)lists.fedorahosted.org>
Cc: Bhavin Vaidya <bhavin.vaidya(a)arteris.com>; Stéphane Mehat
<stephane.mehat(a)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(a)redhat.com>; 'FreeIPA users list'
<freeipa-users(a)lists.fedorahosted.org>
Cc: Bhavin Vaidya <bhavin.vaidya(a)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(a)redhat.com>; FreeIPA users list
<freeipa-users(a)lists.fedorahosted.org>
Cc: Bhavin Vaidya <bhavin.vaidya(a)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(a)arteris.com>; FreeIPA users list
<freeipa-users(a)lists.fedorahosted.org>
Cc: Bhavin Vaidya <bhavin.vaidya(a)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(a)lists.fedorahosted.org>
> Cc: Bhavin Vaidya <bhavin.vaidya(a)arteris.com>; Stéphane Mehat
> <stephane.mehat(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)lists.fedorahosted.org
>> To unsubscribe send an email to
>> freeipa-users-leave(a)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(a)lists.fedorahosted.org
To unsubscribe send an email to
freeipa-users-leave(a)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