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(a)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(a)redhat.com>; 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: [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<mailto:freeipa-users@lists.fedorahosted.org>
Cc: Bhavin Vaidya
<bhavin.vaidya@arteris.com<mailto:bhavin.vaidya@arteris.com>>; Stéphane Mehat
<stephane.mehat@arteris.com<mailto: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.
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<mailto:flo@redhat.com>>; 'FreeIPA users list'
>
<freeipa-users@lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>
> Cc: Bhavin Vaidya
<bhavin.vaidya@arteris.com<mailto: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:
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:
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:
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<mailto:flo@redhat.com>>; FreeIPA users list
>
<freeipa-users@lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>
> Cc: Bhavin Vaidya
<bhavin.vaidya@arteris.com<mailto: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
[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
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
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
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<mailto:stephane.mehat@arteris.com>>; FreeIPA users
list
>
<freeipa-users@lists.fedorahosted.org<mailto:freeipa-users@lists.fedorahosted.org>
> Cc: Bhavin Vaidya
<bhavin.vaidya@arteris.com<mailto: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<mailto:freeipa-users@lists.fedorahosted.org>
> Cc: Bhavin Vaidya
<bhavin.vaidya@arteris.com<mailto:bhavin.vaidya@arteris.com>>; Stéphane Mehat
>> <stephane.mehat@arteris.com<mailto: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
>>
>> 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.
>>
>>
-
>> 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
>>
>> 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
>>
<https://%60hostname%60:8443/ca/agent/ca/profileReview>'
>>
>>
>> But still same trust issue.
>>
>> Our issue seems similar than the one discribed in:
>>
>>
>> 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
>> <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
>> <mailto:/var/run/ipa/ccaches/admin@EXAMPLE.COM>)!,
referer:
>>
>> 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
>>
>>
>> DNS Domain:
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> <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 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
>>
>>
>>
>> expires: 2019-03-07 06:24:12 UTC
>>
>>> principal name:
krbtgt/EXAMPLE.COM@EXAMPLE.COM<mailto: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
>>
>>
>> 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
>>
>>
>> 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
>>
>>
>> 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
>>
>>
>> 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
>>
>> 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
>>
>>
>> expires: 2020-03-07 08:49:36 UTC
>>
>>> principal name:
ldap/ds01.EXAMPLE.com@EXAMPLE.COM<mailto: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
>>
>> 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
>>
>>
>> expires: 2020-03-07 08:49:51 UTC
>>
>>> principal name:
HTTP/ds01.EXAMPLE.com@EXAMPLE.COM<mailto: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
>>> <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:
>>
>>
>> * 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.
>>
>>
>> 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<mailto:freeipa-users@lists.fedorahosted.org
>> To unsubscribe send an email to
>>>
freeipa-users-leave@lists.fedorahosted.org<mailto: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<mailto:freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to
>
freeipa-users-leave@lists.fedorahosted.org<mailto: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<mailto:freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to
freeipa-users-leave@lists.fedorahosted.org<mailto:freeipa-users-leave@lists.fedorahosted.org