Hello,
We had two ipa replicas ipa1 with CA and ipa2. Those servers were on Ubuntu 16.
I successfully installed ipa3 replica with CA that is running on newer version of IPA and Centos 7. After that I stopped old ipa2 and successfully installed new ipa2 with CA on Centos 7. Lastly I setup CA master to be new ipa2 following https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Proc... and turned off old ipa1 server.
Problem occurred when I was installing replica with CA to new ipa1 server running at Centos 7. I can successfully install ipa client and create ticket under admin user but when trying to install replica it fails with "ERROR Certificate issuance failed (CA_UNREACHABLE)". Somehow it tries to get certificates during replica install from ipa1 server when it does not have yet httpd installed.
I thought it could be problem that certificate was primary created at old ipa1 and we have it signed by our own certificates as well so I created another ipa4 server on Centos 7. And again it crashed at the same point trying to get certificate from itself when it did not have httpd installed yet.
OS: CentOS Linux release 7.4.1708 IPA: VERSION: 4.5.0, API_VERSION: 2.228
Attached are logs from ipa client installation and ipa replica installation for ipa4 server. Please ask if you require any different logs. I tried also to follow debugging from https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... but in my case it end earlier because it try to get certificate from itself and does not get to master. This can be also seen in output of command getcert list(in attachement).
Thank you for checking.
With kind regards, *Ján Gardian* Administrator
Hello
I got this same error with replica installation on rhel 7.4 after the OS was hardened with openscap. Pure base OS install without any additional hardening did work without problems. I was doing replica immediately after setting up the new primary.
Also, with same scap policy the fresh primary ipa did not allow any login at webui. In my case I believe it was about some security setting but have not yet had time to debug which one. Dunno where to start the debug though.
br, risto
Sent from my iPad
On 19 Apr 2018, at 18.24, Jan Gardian via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Hello,
We had two ipa replicas ipa1 with CA and ipa2. Those servers were on Ubuntu 16.
I successfully installed ipa3 replica with CA that is running on newer version of IPA and Centos 7. After that I stopped old ipa2 and successfully installed new ipa2 with CA on Centos 7. Lastly I setup CA master to be new ipa2 following https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Proc... and turned off old ipa1 server.
Problem occurred when I was installing replica with CA to new ipa1 server running at Centos 7. I can successfully install ipa client and create ticket under admin user but when trying to install replica it fails with "ERROR Certificate issuance failed (CA_UNREACHABLE)". Somehow it tries to get certificates during replica install from ipa1 server when it does not have yet httpd installed.
I thought it could be problem that certificate was primary created at old ipa1 and we have it signed by our own certificates as well so I created another ipa4 server on Centos 7. And again it crashed at the same point trying to get certificate from itself when it did not have httpd installed yet.
OS: CentOS Linux release 7.4.1708 IPA: VERSION: 4.5.0, API_VERSION: 2.228
Attached are logs from ipa client installation and ipa replica installation for ipa4 server. Please ask if you require any different logs. I tried also to follow debugging from https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... but in my case it end earlier because it try to get certificate from itself and does not get to master. This can be also seen in output of command getcert list(in attachement).
Thank you for checking.
With kind regards, Ján Gardian Administrator
<ipa4_debug> _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
On to, 19 huhti 2018, r hartikainen via FreeIPA-users wrote:
Hello
I got this same error with replica installation on rhel 7.4 after the OS was hardened with openscap. Pure base OS install without any additional hardening did work without problems. I was doing replica immediately after setting up the new primary.
Also, with same scap policy the fresh primary ipa did not allow any login at webui. In my case I believe it was about some security setting but have not yet had time to debug which one. Dunno where to start the debug though.
Please file bugs and attach the logs (audit.log most likely). We definitely want to play well with openscap.
br, risto
Sent from my iPad
On 19 Apr 2018, at 18.24, Jan Gardian via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Hello,
We had two ipa replicas ipa1 with CA and ipa2. Those servers were on Ubuntu 16.
I successfully installed ipa3 replica with CA that is running on newer version of IPA and Centos 7. After that I stopped old ipa2 and successfully installed new ipa2 with CA on Centos 7. Lastly I setup CA master to be new ipa2 following https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Proc... and turned off old ipa1 server.
Problem occurred when I was installing replica with CA to new ipa1 server running at Centos 7. I can successfully install ipa client and create ticket under admin user but when trying to install replica it fails with "ERROR Certificate issuance failed (CA_UNREACHABLE)". Somehow it tries to get certificates during replica install from ipa1 server when it does not have yet httpd installed.
I thought it could be problem that certificate was primary created at old ipa1 and we have it signed by our own certificates as well so I created another ipa4 server on Centos 7. And again it crashed at the same point trying to get certificate from itself when it did not have httpd installed yet.
OS: CentOS Linux release 7.4.1708 IPA: VERSION: 4.5.0, API_VERSION: 2.228
Attached are logs from ipa client installation and ipa replica installation for ipa4 server. Please ask if you require any different logs. I tried also to follow debugging from https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... but in my case it end earlier because it try to get certificate from itself and does not get to master. This can be also seen in output of command getcert list(in attachement).
Thank you for checking.
With kind regards, Ján Gardian Administrator
<ipa4_debug> _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Hello,
In my case this error message was directly related to security hardening with openscap using disa stig for rhel 7 policy.
First clue of problems was with the webui on freshly installed primary, with admin account always got every time error ”login failed for unknown reason”. Replica installation failed with ca_unreachable.
After playing around with oscap and many tests I found that when section ”Secure Session Configuration for Login Access” was left out from remediation, both webui and replica installation worked without problems.
I have ticket open to redhat support so that exact setting causing trouble will be identified.
br, risto
Sent from my iPad
On 19 Apr 2018, at 22.06, Alexander Bokovoy abokovoy@redhat.com wrote:
On to, 19 huhti 2018, r hartikainen via FreeIPA-users wrote: Hello
I got this same error with replica installation on rhel 7.4 after the OS was hardened with openscap. Pure base OS install without any additional hardening did work without problems. I was doing replica immediately after setting up the new primary.
Also, with same scap policy the fresh primary ipa did not allow any login at webui. In my case I believe it was about some security setting but have not yet had time to debug which one. Dunno where to start the debug though.
Please file bugs and attach the logs (audit.log most likely). We definitely want to play well with openscap.
br, risto
Sent from my iPad
On 19 Apr 2018, at 18.24, Jan Gardian via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Hello,
We had two ipa replicas ipa1 with CA and ipa2. Those servers were on Ubuntu 16.
I successfully installed ipa3 replica with CA that is running on newer version of IPA and Centos 7. After that I stopped old ipa2 and successfully installed new ipa2 with CA on Centos 7. Lastly I setup CA master to be new ipa2 following https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Proc... and turned off old ipa1 server.
Problem occurred when I was installing replica with CA to new ipa1 server running at Centos 7. I can successfully install ipa client and create ticket under admin user but when trying to install replica it fails with "ERROR Certificate issuance failed (CA_UNREACHABLE)". Somehow it tries to get certificates during replica install from ipa1 server when it does not have yet httpd installed.
I thought it could be problem that certificate was primary created at old ipa1 and we have it signed by our own certificates as well so I created another ipa4 server on Centos 7. And again it crashed at the same point trying to get certificate from itself when it did not have httpd installed yet.
OS: CentOS Linux release 7.4.1708 IPA: VERSION: 4.5.0, API_VERSION: 2.228
Attached are logs from ipa client installation and ipa replica installation for ipa4 server. Please ask if you require any different logs. I tried also to follow debugging from https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... but in my case it end earlier because it try to get certificate from itself and does not get to master. This can be also seen in output of command getcert list(in attachement).
Thank you for checking.
With kind regards, Ján Gardian Administrator
<ipa4_debug> _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
On 04/19/2018 06:34 PM, r hartikainen via FreeIPA-users wrote:
Hello
I got this same error with replica installation on rhel 7.4 after the OS was hardened with openscap. Pure base OS install without any additional hardening did work without problems. I was doing replica immediately after setting up the new primary.
Also, with same scap policy the fresh primary ipa did not allow any login at webui. In my case I believe it was about some security setting but have not yet had time to debug which one. Dunno where to start the debug though.
br, risto
Sent from my iPad
On 19 Apr 2018, at 18.24, Jan Gardian via FreeIPA-users <freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org> wrote:
Hello,
We had two ipa replicas ipa1 with CA and ipa2. Those servers were on Ubuntu 16.
I successfully installed ipa3 replica with CA that is running on newer version of IPA and Centos 7. After that I stopped old ipa2 and successfully installed new ipa2 with CA on Centos 7. Lastly I setup CA master to be new ipa2 following https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Proc... and turned off old ipa1 server.
Problem occurred when I was installing replica with CA to new ipa1 server running at Centos 7. I can successfully install ipa client and create ticket under admin user but when trying to install replica it fails with "ERROR Certificate issuance failed (CA_UNREACHABLE)". Somehow it tries to get certificates during replica install from ipa1 server when it does not have yet httpd installed.
I thought it could be problem that certificate was primary created at old ipa1 and we have it signed by our own certificates as well so I created another ipa4 server on Centos 7. And again it crashed at the same point trying to get certificate from itself when it did not have httpd installed yet.
OS: CentOS Linux release 7.4.1708 IPA: VERSION: 4.5.0, API_VERSION: 2.228
Attached are logs from ipa client installation and ipa replica installation for ipa4 server. Please ask if you require any different logs. I tried also to follow debugging from https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... but in my case it end earlier because it try to get certificate from itself and does not get to master. This can be also seen in output of command getcert list(in attachement).
Thank you for checking.
With kind regards, *Ján Gardian* Administrator
<ipa4_debug> _______________________________________________ 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>
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Hi,
the issue is probably linked to the root's umask setting on the master. When umask is too restrictive, the httpd server is not able to read the CA file and establish a secure connection with Dogtag. This is a known issue [1], the workaround is to modify the cert file permissions: chmod 644 /etc/ipa/ca.crt chmod 440 /var/lib/ipa/ra-agent.{key|pem}
HTH, Flo
Hello,
I checked and we already have correct permission for mentioned cert files:
[root@ipa2 ~]# ls -la /etc/ipa/ca.crt -rw-r--r--. 1 root root 5201 Apr 18 09:43 /etc/ipa/ca.crt [root@ipa2 ~]# ls -la /var/lib/ipa/ra-agent.* -r--r-----. 1 root ipaapi 1854 Apr 18 09:50 /var/lib/ipa/ra-agent.key -r--r-----. 1 root ipaapi 1423 Apr 18 09:50 /var/lib/ipa/ra-agent.pem
And when doing replica install at ipa4 it still tries to get certificate from itself and not from master ipa2: [root@ipa4 ~]# getcert list Number of certificates and requests being tracked: 1. Request ID '20180424101635': status: CA_REJECTED ca-error: Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection refused). stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv EXAMPLE-COM track: yes auto-renew: yes
With kind regards, Jan Gardian
On 04/24/2018 10:41 AM, Florence Blanc-Renaud wrote:
On 04/19/2018 06:34 PM, r hartikainen via FreeIPA-users wrote:
Hello
I got this same error with replica installation on rhel 7.4 after the OS was hardened with openscap. Pure base OS install without any additional hardening did work without problems. I was doing replica immediately after setting up the new primary.
Also, with same scap policy the fresh primary ipa did not allow any login at webui. In my case I believe it was about some security setting but have not yet had time to debug which one. Dunno where to start the debug though.
br, risto
Sent from my iPad
On 19 Apr 2018, at 18.24, Jan Gardian via FreeIPA-users <freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org> wrote:
Hello,
We had two ipa replicas ipa1 with CA and ipa2. Those servers were on Ubuntu 16.
I successfully installed ipa3 replica with CA that is running on newer version of IPA and Centos 7. After that I stopped old ipa2 and successfully installed new ipa2 with CA on Centos 7. Lastly I setup CA master to be new ipa2 following https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Proc... and turned off old ipa1 server.
Problem occurred when I was installing replica with CA to new ipa1 server running at Centos 7. I can successfully install ipa client and create ticket under admin user but when trying to install replica it fails with "ERROR Certificate issuance failed (CA_UNREACHABLE)". Somehow it tries to get certificates during replica install from ipa1 server when it does not have yet httpd installed.
I thought it could be problem that certificate was primary created at old ipa1 and we have it signed by our own certificates as well so I created another ipa4 server on Centos 7. And again it crashed at the same point trying to get certificate from itself when it did not have httpd installed yet.
OS: CentOS Linux release 7.4.1708 IPA: VERSION: 4.5.0, API_VERSION: 2.228
Attached are logs from ipa client installation and ipa replica installation for ipa4 server. Please ask if you require any different logs. I tried also to follow debugging from https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... but in my case it end earlier because it try to get certificate from itself and does not get to master. This can be also seen in output of command getcert list(in attachement).
Thank you for checking.
With kind regards, *Ján Gardian* Administrator
<ipa4_debug> _______________________________________________ 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>
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Hi,
the issue is probably linked to the root's umask setting on the master. When umask is too restrictive, the httpd server is not able to read the CA file and establish a secure connection with Dogtag. This is a known issue [1], the workaround is to modify the cert file permissions: chmod 644 /etc/ipa/ca.crt chmod 440 /var/lib/ipa/ra-agent.{key|pem}
HTH, Flo
Hello,
I setup more verbose output for certmonger and tested to install ipa replica at ipa4. What credentials does certmonger use? Installing replica is run with admin credentials. Servers ipa2 and ipa3 are up. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Certificate submission still ongoing. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Will revisit Request1('20180424112419') on traffic from 15. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Certificate submission attempt complete. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Child status = 2. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Child output: Apr 24 13:24:19 ipa4.example.com certmonger[1755]: "Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection refused). Apr 24 13:24:19 ipa4.example.com certmonger[1755]: Server at https://ipa3.example.com/ipa/xml denied our request, giving up: 2100 (RPC failed at server. Insufficient access: Invalid credentials). Apr 24 13:24:19 ipa4.example.com certmonger[1755]: " Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Certificate not (yet?) issued. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Request1('20180424112419') moved to state 'NEED_TO_NOTIFY_REJECTION'
Only ipa2 is up Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Certificate submission still ongoing. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Will revisit Request1('20180424115242') on traffic from 15. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Certificate submission attempt complete. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Child status = 3. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Child output: Apr 24 13:52:46 ipa4.example.com certmonger[1715]: "Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection refused). Apr 24 13:52:46 ipa4.example.com certmonger[1715]: Server at https://ipa3.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa3.example.com:443; No route to host). Apr 24 13:52:46 ipa4.example.com certmonger[1715]: Server at https://ipa2.example.com/ipa/xml failed request, will retry: 4001 (RPC failed at server. ipa: Certificate Authority not found). Apr 24 13:52:46 ipa4.example.com certmonger[1715]: " Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Certificate not (yet?) issued. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Request1('20180424115242') moved to state 'CA_UNREACHABLE'
With kind regards, Jan Gardian
On 04/24/2018 12:24 PM, Jan Gardian via FreeIPA-users wrote:
Hello,
I checked and we already have correct permission for mentioned cert files:
[root@ipa2 ~]# ls -la /etc/ipa/ca.crt -rw-r--r--. 1 root root 5201 Apr 18 09:43 /etc/ipa/ca.crt [root@ipa2 ~]# ls -la /var/lib/ipa/ra-agent.* -r--r-----. 1 root ipaapi 1854 Apr 18 09:50 /var/lib/ipa/ra-agent.key -r--r-----. 1 root ipaapi 1423 Apr 18 09:50 /var/lib/ipa/ra-agent.pem
And when doing replica install at ipa4 it still tries to get certificate from itself and not from master ipa2: [root@ipa4 ~]# getcert list Number of certificates and requests being tracked: 1. Request ID '20180424101635': status: CA_REJECTED ca-error: Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection refused). stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv EXAMPLE-COM track: yes auto-renew: yes
With kind regards, Jan Gardian
On 04/24/2018 10:41 AM, Florence Blanc-Renaud wrote:
On 04/19/2018 06:34 PM, r hartikainen via FreeIPA-users wrote:
Hello
I got this same error with replica installation on rhel 7.4 after the OS was hardened with openscap. Pure base OS install without any additional hardening did work without problems. I was doing replica immediately after setting up the new primary.
Also, with same scap policy the fresh primary ipa did not allow any login at webui. In my case I believe it was about some security setting but have not yet had time to debug which one. Dunno where to start the debug though.
br, risto
Sent from my iPad
On 19 Apr 2018, at 18.24, Jan Gardian via FreeIPA-users <freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org> wrote:
Hello,
We had two ipa replicas ipa1 with CA and ipa2. Those servers were on Ubuntu 16.
I successfully installed ipa3 replica with CA that is running on newer version of IPA and Centos 7. After that I stopped old ipa2 and successfully installed new ipa2 with CA on Centos 7. Lastly I setup CA master to be new ipa2 following https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Proc... and turned off old ipa1 server.
Problem occurred when I was installing replica with CA to new ipa1 server running at Centos 7. I can successfully install ipa client and create ticket under admin user but when trying to install replica it fails with "ERROR Certificate issuance failed (CA_UNREACHABLE)". Somehow it tries to get certificates during replica install from ipa1 server when it does not have yet httpd installed.
I thought it could be problem that certificate was primary created at old ipa1 and we have it signed by our own certificates as well so I created another ipa4 server on Centos 7. And again it crashed at the same point trying to get certificate from itself when it did not have httpd installed yet.
OS: CentOS Linux release 7.4.1708 IPA: VERSION: 4.5.0, API_VERSION: 2.228
Attached are logs from ipa client installation and ipa replica installation for ipa4 server. Please ask if you require any different logs. I tried also to follow debugging from https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... but in my case it end earlier because it try to get certificate from itself and does not get to master. This can be also seen in output of command getcert list(in attachement).
Thank you for checking.
With kind regards, *Ján Gardian* Administrator
<ipa4_debug> _______________________________________________ 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>
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Hi,
the issue is probably linked to the root's umask setting on the master. When umask is too restrictive, the httpd server is not able to read the CA file and establish a secure connection with Dogtag. This is a known issue [1], the workaround is to modify the cert file permissions: chmod 644 /etc/ipa/ca.crt chmod 440 /var/lib/ipa/ra-agent.{key|pem}
HTH, Flo
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Jan Gardian via FreeIPA-users wrote:
Hello,
I setup more verbose output for certmonger and tested to install ipa replica at ipa4. What credentials does certmonger use? Installing replica is run with admin credentials.
certmonger uses the host principal in /etc/krb5.keytab
I'd check on the remote servers /var/log/httpd/error_log to see if anything was logged for the cert requests. Invalid credentials seems like an odd error.
You can also check on the validity of the keytab with:
# klist -kt /etc/krb5.keytab # kvno host/`hostname`
The kvno should match.
IIRC you are promoting a client to a replica which means there shouldn't be any issues with replication of the host principal.
rob
Servers ipa2 and ipa3 are up. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Certificate submission still ongoing. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Will revisit Request1('20180424112419') on traffic from 15. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Certificate submission attempt complete. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Child status = 2. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Child output: Apr 24 13:24:19 ipa4.example.com certmonger[1755]: "Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection refused). Apr 24 13:24:19 ipa4.example.com certmonger[1755]: Server at https://ipa3.example.com/ipa/xml denied our request, giving up: 2100 (RPC failed at server. Insufficient access: Invalid credentials). Apr 24 13:24:19 ipa4.example.com certmonger[1755]: " Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Certificate not (yet?) issued. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Request1('20180424112419') moved to state 'NEED_TO_NOTIFY_REJECTION'
Only ipa2 is up Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Certificate submission still ongoing. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Will revisit Request1('20180424115242') on traffic from 15. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Certificate submission attempt complete. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Child status = 3. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Child output: Apr 24 13:52:46 ipa4.example.com certmonger[1715]: "Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection refused). Apr 24 13:52:46 ipa4.example.com certmonger[1715]: Server at https://ipa3.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa3.example.com:443; No route to host). Apr 24 13:52:46 ipa4.example.com certmonger[1715]: Server at https://ipa2.example.com/ipa/xml failed request, will retry: 4001 (RPC failed at server. ipa: Certificate Authority not found). Apr 24 13:52:46 ipa4.example.com certmonger[1715]: " Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Certificate not (yet?) issued. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Request1('20180424115242') moved to state 'CA_UNREACHABLE'
With kind regards, Jan Gardian
On 04/24/2018 12:24 PM, Jan Gardian via FreeIPA-users wrote:
Hello,
I checked and we already have correct permission for mentioned cert files:
[root@ipa2 ~]# ls -la /etc/ipa/ca.crt -rw-r--r--. 1 root root 5201 Apr 18 09:43 /etc/ipa/ca.crt [root@ipa2 ~]# ls -la /var/lib/ipa/ra-agent.* -r--r-----. 1 root ipaapi 1854 Apr 18 09:50 /var/lib/ipa/ra-agent.key -r--r-----. 1 root ipaapi 1423 Apr 18 09:50 /var/lib/ipa/ra-agent.pem
And when doing replica install at ipa4 it still tries to get certificate from itself and not from master ipa2: [root@ipa4 ~]# getcert list Number of certificates and requests being tracked: 1. Request ID '20180424101635': status: CA_REJECTED ca-error: Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection refused). stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert'
CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv EXAMPLE-COM track: yes auto-renew: yes
With kind regards, Jan Gardian
On 04/24/2018 10:41 AM, Florence Blanc-Renaud wrote:
On 04/19/2018 06:34 PM, r hartikainen via FreeIPA-users wrote:
Hello
I got this same error with replica installation on rhel 7.4 after the OS was hardened with openscap. Pure base OS install without any additional hardening did work without problems. I was doing replica immediately after setting up the new primary.
Also, with same scap policy the fresh primary ipa did not allow any login at webui. In my case I believe it was about some security setting but have not yet had time to debug which one. Dunno where to start the debug though.
br, risto
Sent from my iPad
On 19 Apr 2018, at 18.24, Jan Gardian via FreeIPA-users <freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org> wrote:
Hello,
We had two ipa replicas ipa1 with CA and ipa2. Those servers were on Ubuntu 16.
I successfully installed ipa3 replica with CA that is running on newer version of IPA and Centos 7. After that I stopped old ipa2 and successfully installed new ipa2 with CA on Centos 7. Lastly I setup CA master to be new ipa2 following https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Proc... and turned off old ipa1 server.
Problem occurred when I was installing replica with CA to new ipa1 server running at Centos 7. I can successfully install ipa client and create ticket under admin user but when trying to install replica it fails with "ERROR Certificate issuance failed (CA_UNREACHABLE)". Somehow it tries to get certificates during replica install from ipa1 server when it does not have yet httpd installed.
I thought it could be problem that certificate was primary created at old ipa1 and we have it signed by our own certificates as well so I created another ipa4 server on Centos 7. And again it crashed at the same point trying to get certificate from itself when it did not have httpd installed yet.
OS: CentOS Linux release 7.4.1708 IPA: VERSION: 4.5.0, API_VERSION: 2.228
Attached are logs from ipa client installation and ipa replica installation for ipa4 server. Please ask if you require any different logs. I tried also to follow debugging from https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... but in my case it end earlier because it try to get certificate from itself and does not get to master. This can be also seen in output of command getcert list(in attachement).
Thank you for checking.
With kind regards, *Ján Gardian* Administrator
<ipa4_debug> _______________________________________________ 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>
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Hi,
the issue is probably linked to the root's umask setting on the master. When umask is too restrictive, the httpd server is not able to read the CA file and establish a secure connection with Dogtag. This is a known issue [1], the workaround is to modify the cert file permissions: chmod 644 /etc/ipa/ca.crt chmod 440 /var/lib/ipa/ra-agent.{key|pem}
HTH, Flo
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Hello,
Permission of cert files at ipa2 and ipa3 are ok. I was installing replica under admin user. Master CA should be setup but it still crash with CA not found. I was still able to create ipa2 and ipa3 replica with old ipa1(ubuntu 16) server without problem. Bellow are also error_logs from httpd and certmonger. Any idea what else I can check? Our ipa CA is signed by our own CA, could this cause some problems?
[root@ipa4 ~]# klist -kt /etc/krb5.keytab Keytab name: FILE:/etc/krb5.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM [root@ipa4 ~]# kvno host/`hostname` host/ipa4.example.com@EXAMPLE.COM: kvno = 1
ipa-replica-install --setup-ca fails at the same point: Configuring directory server (dirsrv) [1/3]: configuring TLS for DS instance [error] RuntimeError: Certificate issuance failed (CA_UNREACHABLE) Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up.
ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall): ERROR Certificate issuance failed (CA_UNREACHABLE) ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall): ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information
Master CA setup to be ipa2: [root@ipa2 ~]# grep ca.crl.MasterCRL.enableCRLUpdates /etc/pki/pki-tomcat/ca/CS.cfg ca.crl.MasterCRL.enableCRLUpdates=true
[root@ipa3 ~]# grep ca.crl.MasterCRL.enableCRLUpdates /etc/pki/pki-tomcat/ca/CS.cfg ca.crl.MasterCRL.enableCRLUpdates=false
ipa4 certmonger logs: Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Certificate submission still ongoing. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Will revisit Request1('20180426082737') on traffic from 15. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Certificate submission attempt complete. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Child status = 3. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Child output: Apr 26 10:27:38 ipa4.example.com certmonger[1713]: "Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection ref Apr 26 10:27:38 ipa4.example.com certmonger[1713]: Server at https://ipa3.example.com/ipa/xml failed request, will retry: 4001 (RPC failed at server. ipa: Certificate Authority not found). Apr 26 10:27:38 ipa4.example.com certmonger[1713]: Server at https://ipa2.example.com/ipa/xml failed request, will retry: 4001 (RPC failed at server. ipa: Certificate Authority not found). Apr 26 10:27:38 ipa4.example.com certmonger[1713]: " Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Certificate not (yet?) issued. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Request1('20180426082737') moved to state 'CA_UNREACHABLE'
ipa3 httpd/error_log: [Thu Apr 26 10:27:38.375982 2018] [auth_gssapi:error] [pid 1724] [client 1.1.1.4:35234] NO AUTH DATA Client did not send any authentication headers, referer: https://ipa3.example.com/ipa/xml [Thu Apr 26 10:27:38.422274 2018] [:error] [pid 1720] ipa: INFO: [xmlserver] host/ipa4.example.com@EXAMPLE.COM: cert_request(u'XYZ...==', profile_id=u'caIPAserviceCert', principal=u'ldap/ipa4.example.com@EXAMPLE.COM', add=True, version=u'2.51'): NotFound
[root@ipa3 ~]# ipa ca-show ipa ipa: ERROR: ipa: Certificate Authority not found
ipa2 httpd/error_log: [Thu Apr 26 10:27:14.476884 2018] [:error] [pid 7564] ipa: INFO: [jsonserver_kerb] admin@EXAMPLE.COM: server_conncheck(u'ipa2.example.com', u'ipa4.example.com', version=u'2.162'): SUCCESS [Thu Apr 26 10:27:38.443093 2018] [auth_gssapi:error] [pid 8336] [client 1.1.1.4:59674] NO AUTH DATA Client did not send any authentication headers, referer: https://ipa2.example.com/ipa/xml [Thu Apr 26 10:27:38.503320 2018] [:error] [pid 7565] ipa: INFO: [xmlserver] host/ipa4.example.com@EXAMPLE.COM: cert_request(u'XYZ...==', profile_id=u'caIPAserviceCert', principal=u'ldap/ipa4.example.com@EXAMPLE.COM', add=True, version=u'2.51'): NotFound
[root@ipa2 ~]# ipa ca-show ipa ipa: ERROR: ipa: Certificate Authority not found
With kind regards, Jan Gardian
On 04/24/2018 02:52 PM, Rob Crittenden wrote:
Jan Gardian via FreeIPA-users wrote:
Hello,
I setup more verbose output for certmonger and tested to install ipa replica at ipa4. What credentials does certmonger use? Installing replica is run with admin credentials.
certmonger uses the host principal in /etc/krb5.keytab
I'd check on the remote servers /var/log/httpd/error_log to see if anything was logged for the cert requests. Invalid credentials seems like an odd error.
You can also check on the validity of the keytab with:
# klist -kt /etc/krb5.keytab # kvno host/`hostname`
The kvno should match.
IIRC you are promoting a client to a replica which means there shouldn't be any issues with replication of the host principal.
rob
Servers ipa2 and ipa3 are up. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Certificate submission still ongoing. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Will revisit Request1('20180424112419') on traffic from 15. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Certificate submission attempt complete. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Child status = 2. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Child output: Apr 24 13:24:19 ipa4.example.com certmonger[1755]: "Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection refused). Apr 24 13:24:19 ipa4.example.com certmonger[1755]: Server at https://ipa3.example.com/ipa/xml denied our request, giving up: 2100 (RPC failed at server. Insufficient access: Invalid credentials). Apr 24 13:24:19 ipa4.example.com certmonger[1755]: " Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Certificate not (yet?) issued. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Request1('20180424112419') moved to state 'NEED_TO_NOTIFY_REJECTION'
Only ipa2 is up Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Certificate submission still ongoing. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Will revisit Request1('20180424115242') on traffic from 15. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Certificate submission attempt complete. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Child status = 3. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Child output: Apr 24 13:52:46 ipa4.example.com certmonger[1715]: "Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection refused). Apr 24 13:52:46 ipa4.example.com certmonger[1715]: Server at https://ipa3.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa3.example.com:443; No route to host). Apr 24 13:52:46 ipa4.example.com certmonger[1715]: Server at https://ipa2.example.com/ipa/xml failed request, will retry: 4001 (RPC failed at server. ipa: Certificate Authority not found). Apr 24 13:52:46 ipa4.example.com certmonger[1715]: " Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Certificate not (yet?) issued. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Request1('20180424115242') moved to state 'CA_UNREACHABLE'
With kind regards, Jan Gardian
On 04/24/2018 12:24 PM, Jan Gardian via FreeIPA-users wrote:
Hello,
I checked and we already have correct permission for mentioned cert files:
[root@ipa2 ~]# ls -la /etc/ipa/ca.crt -rw-r--r--. 1 root root 5201 Apr 18 09:43 /etc/ipa/ca.crt [root@ipa2 ~]# ls -la /var/lib/ipa/ra-agent.* -r--r-----. 1 root ipaapi 1854 Apr 18 09:50 /var/lib/ipa/ra-agent.key -r--r-----. 1 root ipaapi 1423 Apr 18 09:50 /var/lib/ipa/ra-agent.pem
And when doing replica install at ipa4 it still tries to get certificate from itself and not from master ipa2: [root@ipa4 ~]# getcert list Number of certificates and requests being tracked: 1. Request ID '20180424101635': status: CA_REJECTED ca-error: Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection refused). stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert'
CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv EXAMPLE-COM track: yes auto-renew: yes
With kind regards, Jan Gardian
On 04/24/2018 10:41 AM, Florence Blanc-Renaud wrote:
On 04/19/2018 06:34 PM, r hartikainen via FreeIPA-users wrote:
Hello
I got this same error with replica installation on rhel 7.4 after the OS was hardened with openscap. Pure base OS install without any additional hardening did work without problems. I was doing replica immediately after setting up the new primary.
Also, with same scap policy the fresh primary ipa did not allow any login at webui. In my case I believe it was about some security setting but have not yet had time to debug which one. Dunno where to start the debug though.
br, risto
Sent from my iPad
On 19 Apr 2018, at 18.24, Jan Gardian via FreeIPA-users <freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org> wrote:
Hello,
We had two ipa replicas ipa1 with CA and ipa2. Those servers were on Ubuntu 16.
I successfully installed ipa3 replica with CA that is running on newer version of IPA and Centos 7. After that I stopped old ipa2 and successfully installed new ipa2 with CA on Centos 7. Lastly I setup CA master to be new ipa2 following https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Proc... and turned off old ipa1 server.
Problem occurred when I was installing replica with CA to new ipa1 server running at Centos 7. I can successfully install ipa client and create ticket under admin user but when trying to install replica it fails with "ERROR Certificate issuance failed (CA_UNREACHABLE)". Somehow it tries to get certificates during replica install from ipa1 server when it does not have yet httpd installed.
I thought it could be problem that certificate was primary created at old ipa1 and we have it signed by our own certificates as well so I created another ipa4 server on Centos 7. And again it crashed at the same point trying to get certificate from itself when it did not have httpd installed yet.
OS: CentOS Linux release 7.4.1708 IPA: VERSION: 4.5.0, API_VERSION: 2.228
Attached are logs from ipa client installation and ipa replica installation for ipa4 server. Please ask if you require any different logs. I tried also to follow debugging from https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... but in my case it end earlier because it try to get certificate from itself and does not get to master. This can be also seen in output of command getcert list(in attachement).
Thank you for checking.
With kind regards, *Ján Gardian* Administrator
<ipa4_debug> _______________________________________________ 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>
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Hi,
the issue is probably linked to the root's umask setting on the master. When umask is too restrictive, the httpd server is not able to read the CA file and establish a secure connection with Dogtag. This is a known issue [1], the workaround is to modify the cert file permissions: chmod 644 /etc/ipa/ca.crt chmod 440 /var/lib/ipa/ra-agent.{key|pem}
HTH, Flo
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Hello,
Do you have some idea why we get "Certificate Authority not found" ?
Thanks.
With kind regards. Jan Gardian
On 04/26/2018 10:57 AM, Jan Gardian via FreeIPA-users wrote:
Hello,
Permission of cert files at ipa2 and ipa3 are ok. I was installing replica under admin user. Master CA should be setup but it still crash with CA not found. I was still able to create ipa2 and ipa3 replica with old ipa1(ubuntu 16) server without problem. Bellow are also error_logs from httpd and certmonger. Any idea what else I can check? Our ipa CA is signed by our own CA, could this cause some problems?
[root@ipa4 ~]# klist -kt /etc/krb5.keytab Keytab name: FILE:/etc/krb5.keytab KVNO Timestamp Principal
1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM [root@ipa4 ~]# kvno host/`hostname` host/ipa4.example.com@EXAMPLE.COM: kvno = 1
ipa-replica-install --setup-ca fails at the same point: Configuring directory server (dirsrv) [1/3]: configuring TLS for DS instance [error] RuntimeError: Certificate issuance failed (CA_UNREACHABLE) Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up.
ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall): ERROR Certificate issuance failed (CA_UNREACHABLE) ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall): ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information
Master CA setup to be ipa2: [root@ipa2 ~]# grep ca.crl.MasterCRL.enableCRLUpdates /etc/pki/pki-tomcat/ca/CS.cfg ca.crl.MasterCRL.enableCRLUpdates=true
[root@ipa3 ~]# grep ca.crl.MasterCRL.enableCRLUpdates /etc/pki/pki-tomcat/ca/CS.cfg ca.crl.MasterCRL.enableCRLUpdates=false
ipa4 certmonger logs: Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Certificate submission still ongoing. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Will revisit Request1('20180426082737') on traffic from 15. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Certificate submission attempt complete. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Child status = 3. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Child output: Apr 26 10:27:38 ipa4.example.com certmonger[1713]: "Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection ref Apr 26 10:27:38 ipa4.example.com certmonger[1713]: Server at https://ipa3.example.com/ipa/xml failed request, will retry: 4001 (RPC failed at server. ipa: Certificate Authority not found). Apr 26 10:27:38 ipa4.example.com certmonger[1713]: Server at https://ipa2.example.com/ipa/xml failed request, will retry: 4001 (RPC failed at server. ipa: Certificate Authority not found). Apr 26 10:27:38 ipa4.example.com certmonger[1713]: " Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Certificate not (yet?) issued. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Request1('20180426082737') moved to state 'CA_UNREACHABLE'
ipa3 httpd/error_log: [Thu Apr 26 10:27:38.375982 2018] [auth_gssapi:error] [pid 1724] [client 1.1.1.4:35234] NO AUTH DATA Client did not send any authentication headers, referer: https://ipa3.example.com/ipa/xml [Thu Apr 26 10:27:38.422274 2018] [:error] [pid 1720] ipa: INFO: [xmlserver] host/ipa4.example.com@EXAMPLE.COM: cert_request(u'XYZ...==', profile_id=u'caIPAserviceCert', principal=u'ldap/ipa4.example.com@EXAMPLE.COM', add=True, version=u'2.51'): NotFound
[root@ipa3 ~]# ipa ca-show ipa ipa: ERROR: ipa: Certificate Authority not found
ipa2 httpd/error_log: [Thu Apr 26 10:27:14.476884 2018] [:error] [pid 7564] ipa: INFO: [jsonserver_kerb] admin@EXAMPLE.COM: server_conncheck(u'ipa2.example.com', u'ipa4.example.com', version=u'2.162'): SUCCESS [Thu Apr 26 10:27:38.443093 2018] [auth_gssapi:error] [pid 8336] [client 1.1.1.4:59674] NO AUTH DATA Client did not send any authentication headers, referer: https://ipa2.example.com/ipa/xml [Thu Apr 26 10:27:38.503320 2018] [:error] [pid 7565] ipa: INFO: [xmlserver] host/ipa4.example.com@EXAMPLE.COM: cert_request(u'XYZ...==', profile_id=u'caIPAserviceCert', principal=u'ldap/ipa4.example.com@EXAMPLE.COM', add=True, version=u'2.51'): NotFound
[root@ipa2 ~]# ipa ca-show ipa ipa: ERROR: ipa: Certificate Authority not found
With kind regards, Jan Gardian
On 04/24/2018 02:52 PM, Rob Crittenden wrote:
Jan Gardian via FreeIPA-users wrote:
Hello,
I setup more verbose output for certmonger and tested to install ipa replica at ipa4. What credentials does certmonger use? Installing replica is run with admin credentials.
certmonger uses the host principal in /etc/krb5.keytab
I'd check on the remote servers /var/log/httpd/error_log to see if anything was logged for the cert requests. Invalid credentials seems like an odd error.
You can also check on the validity of the keytab with:
# klist -kt /etc/krb5.keytab # kvno host/`hostname`
The kvno should match.
IIRC you are promoting a client to a replica which means there shouldn't be any issues with replication of the host principal.
rob
Servers ipa2 and ipa3 are up. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Certificate submission still ongoing. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Will revisit Request1('20180424112419') on traffic from 15. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Certificate submission attempt complete. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Child status = 2. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Child output: Apr 24 13:24:19 ipa4.example.com certmonger[1755]: "Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection refused). Apr 24 13:24:19 ipa4.example.com certmonger[1755]: Server at https://ipa3.example.com/ipa/xml denied our request, giving up: 2100 (RPC failed at server. Insufficient access: Invalid credentials). Apr 24 13:24:19 ipa4.example.com certmonger[1755]: " Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Certificate not (yet?) issued. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Request1('20180424112419') moved to state 'NEED_TO_NOTIFY_REJECTION'
Only ipa2 is up Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Certificate submission still ongoing. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Will revisit Request1('20180424115242') on traffic from 15. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Certificate submission attempt complete. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Child status = 3. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Child output: Apr 24 13:52:46 ipa4.example.com certmonger[1715]: "Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection refused). Apr 24 13:52:46 ipa4.example.com certmonger[1715]: Server at https://ipa3.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa3.example.com:443; No route to host). Apr 24 13:52:46 ipa4.example.com certmonger[1715]: Server at https://ipa2.example.com/ipa/xml failed request, will retry: 4001 (RPC failed at server. ipa: Certificate Authority not found). Apr 24 13:52:46 ipa4.example.com certmonger[1715]: " Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Certificate not (yet?) issued. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Request1('20180424115242') moved to state 'CA_UNREACHABLE'
With kind regards, Jan Gardian
On 04/24/2018 12:24 PM, Jan Gardian via FreeIPA-users wrote:
Hello,
I checked and we already have correct permission for mentioned cert files:
[root@ipa2 ~]# ls -la /etc/ipa/ca.crt -rw-r--r--. 1 root root 5201 Apr 18 09:43 /etc/ipa/ca.crt [root@ipa2 ~]# ls -la /var/lib/ipa/ra-agent.* -r--r-----. 1 root ipaapi 1854 Apr 18 09:50 /var/lib/ipa/ra-agent.key -r--r-----. 1 root ipaapi 1423 Apr 18 09:50 /var/lib/ipa/ra-agent.pem
And when doing replica install at ipa4 it still tries to get certificate from itself and not from master ipa2: [root@ipa4 ~]# getcert list Number of certificates and requests being tracked: 1. Request ID '20180424101635': status: CA_REJECTED ca-error: Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection refused). stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert'
CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv EXAMPLE-COM track: yes auto-renew: yes
With kind regards, Jan Gardian
On 04/24/2018 10:41 AM, Florence Blanc-Renaud wrote:
On 04/19/2018 06:34 PM, r hartikainen via FreeIPA-users wrote:
Hello
I got this same error with replica installation on rhel 7.4 after the OS was hardened with openscap. Pure base OS install without any additional hardening did work without problems. I was doing replica immediately after setting up the new primary.
Also, with same scap policy the fresh primary ipa did not allow any login at webui. In my case I believe it was about some security setting but have not yet had time to debug which one. Dunno where to start the debug though.
br, risto
Sent from my iPad
On 19 Apr 2018, at 18.24, Jan Gardian via FreeIPA-users <freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org> wrote:
> Hello, > > We had two ipa replicas ipa1 with CA and ipa2. Those servers were > on Ubuntu 16. > > I successfully installed ipa3 replica with CA that is running on > newer version of IPA and Centos 7. After that I stopped old ipa2 > and successfully installed new ipa2 with CA on Centos 7. Lastly I > setup CA master to be new ipa2 following > https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Proc... > > and turned off old ipa1 server. > > Problem occurred when I was installing replica with CA to new ipa1 > server running at Centos 7. > I can successfully install ipa client and create ticket under admin > user but when trying to install replica it fails with "ERROR > Certificate issuance failed (CA_UNREACHABLE)". Somehow it tries to > get certificates during replica install from ipa1 server when it > does not have yet httpd installed. > > I thought it could be problem that certificate was primary created > at old ipa1 and we have it signed by our own certificates as well > so I created another ipa4 server on Centos 7. And again it crashed > at the same point trying to get certificate from itself when it did > not have httpd installed yet. > > OS: CentOS Linux release 7.4.1708 > IPA: VERSION: 4.5.0, API_VERSION: 2.228 > > Attached are logs from ipa client installation and ipa replica > installation for ipa4 server. > Please ask if you require any different logs. I tried also to > follow debugging from > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... > > but in my case it end earlier because it try to get certificate > from itself and does not get to master. This can be also seen in > output of command getcert list(in attachement). > > > Thank you for checking. > > > With kind regards, > *Ján Gardian* > Administrator > <ipa4_debug> > _______________________________________________ > 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
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Hi,
the issue is probably linked to the root's umask setting on the master. When umask is too restrictive, the httpd server is not able to read the CA file and establish a secure connection with Dogtag. This is a known issue [1], the workaround is to modify the cert file permissions: chmod 644 /etc/ipa/ca.crt chmod 440 /var/lib/ipa/ra-agent.{key|pem}
HTH, Flo
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Jan Gardian via FreeIPA-users wrote:
Hello,
Do you have some idea why we get "Certificate Authority not found" ?
IPA proxies requests to the CA through tomcat. Not Found means that the CA webapp wasn't running in tomcat. You can try restarting pki-tomcatd and seeing what errors are reported in the logs.
rob
Thanks.
With kind regards. Jan Gardian
On 04/26/2018 10:57 AM, Jan Gardian via FreeIPA-users wrote:
Hello,
Permission of cert files at ipa2 and ipa3 are ok. I was installing replica under admin user. Master CA should be setup but it still crash with CA not found. I was still able to create ipa2 and ipa3 replica with old ipa1(ubuntu 16) server without problem. Bellow are also error_logs from httpd and certmonger. Any idea what else I can check? Our ipa CA is signed by our own CA, could this cause some problems?
[root@ipa4 ~]# klist -kt /etc/krb5.keytab Keytab name: FILE:/etc/krb5.keytab KVNO Timestamp Principal
1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM [root@ipa4 ~]# kvno host/`hostname` host/ipa4.example.com@EXAMPLE.COM: kvno = 1
ipa-replica-install --setup-ca fails at the same point: Configuring directory server (dirsrv) [1/3]: configuring TLS for DS instance [error] RuntimeError: Certificate issuance failed (CA_UNREACHABLE) Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up.
ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall): ERROR Certificate issuance failed (CA_UNREACHABLE) ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall): ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information
Master CA setup to be ipa2: [root@ipa2 ~]# grep ca.crl.MasterCRL.enableCRLUpdates /etc/pki/pki-tomcat/ca/CS.cfg ca.crl.MasterCRL.enableCRLUpdates=true
[root@ipa3 ~]# grep ca.crl.MasterCRL.enableCRLUpdates /etc/pki/pki-tomcat/ca/CS.cfg ca.crl.MasterCRL.enableCRLUpdates=false
ipa4 certmonger logs: Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Certificate submission still ongoing. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Will revisit Request1('20180426082737') on traffic from 15. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Certificate submission attempt complete. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Child status = 3. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Child output: Apr 26 10:27:38 ipa4.example.com certmonger[1713]: "Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection ref Apr 26 10:27:38 ipa4.example.com certmonger[1713]: Server at https://ipa3.example.com/ipa/xml failed request, will retry: 4001 (RPC failed at server. ipa: Certificate Authority not found). Apr 26 10:27:38 ipa4.example.com certmonger[1713]: Server at https://ipa2.example.com/ipa/xml failed request, will retry: 4001 (RPC failed at server. ipa: Certificate Authority not found). Apr 26 10:27:38 ipa4.example.com certmonger[1713]: " Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Certificate not (yet?) issued. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Request1('20180426082737') moved to state 'CA_UNREACHABLE'
ipa3 httpd/error_log: [Thu Apr 26 10:27:38.375982 2018] [auth_gssapi:error] [pid 1724] [client 1.1.1.4:35234] NO AUTH DATA Client did not send any authentication headers, referer: https://ipa3.example.com/ipa/xml [Thu Apr 26 10:27:38.422274 2018] [:error] [pid 1720] ipa: INFO: [xmlserver] host/ipa4.example.com@EXAMPLE.COM: cert_request(u'XYZ...==', profile_id=u'caIPAserviceCert', principal=u'ldap/ipa4.example.com@EXAMPLE.COM', add=True, version=u'2.51'): NotFound
[root@ipa3 ~]# ipa ca-show ipa ipa: ERROR: ipa: Certificate Authority not found
ipa2 httpd/error_log: [Thu Apr 26 10:27:14.476884 2018] [:error] [pid 7564] ipa: INFO: [jsonserver_kerb] admin@EXAMPLE.COM: server_conncheck(u'ipa2.example.com', u'ipa4.example.com', version=u'2.162'): SUCCESS [Thu Apr 26 10:27:38.443093 2018] [auth_gssapi:error] [pid 8336] [client 1.1.1.4:59674] NO AUTH DATA Client did not send any authentication headers, referer: https://ipa2.example.com/ipa/xml [Thu Apr 26 10:27:38.503320 2018] [:error] [pid 7565] ipa: INFO: [xmlserver] host/ipa4.example.com@EXAMPLE.COM: cert_request(u'XYZ...==', profile_id=u'caIPAserviceCert', principal=u'ldap/ipa4.example.com@EXAMPLE.COM', add=True, version=u'2.51'): NotFound
[root@ipa2 ~]# ipa ca-show ipa ipa: ERROR: ipa: Certificate Authority not found
With kind regards, Jan Gardian
On 04/24/2018 02:52 PM, Rob Crittenden wrote:
Jan Gardian via FreeIPA-users wrote:
Hello,
I setup more verbose output for certmonger and tested to install ipa replica at ipa4. What credentials does certmonger use? Installing replica is run with admin credentials.
certmonger uses the host principal in /etc/krb5.keytab
I'd check on the remote servers /var/log/httpd/error_log to see if anything was logged for the cert requests. Invalid credentials seems like an odd error.
You can also check on the validity of the keytab with:
# klist -kt /etc/krb5.keytab # kvno host/`hostname`
The kvno should match.
IIRC you are promoting a client to a replica which means there shouldn't be any issues with replication of the host principal.
rob
Servers ipa2 and ipa3 are up. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Certificate submission still ongoing. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Will revisit Request1('20180424112419') on traffic from 15. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Certificate submission attempt complete. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Child status = 2. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Child output: Apr 24 13:24:19 ipa4.example.com certmonger[1755]: "Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection refused). Apr 24 13:24:19 ipa4.example.com certmonger[1755]: Server at https://ipa3.example.com/ipa/xml denied our request, giving up: 2100 (RPC failed at server. Insufficient access: Invalid credentials). Apr 24 13:24:19 ipa4.example.com certmonger[1755]: " Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Certificate not (yet?) issued. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Request1('20180424112419') moved to state 'NEED_TO_NOTIFY_REJECTION'
Only ipa2 is up Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Certificate submission still ongoing. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Will revisit Request1('20180424115242') on traffic from 15. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Certificate submission attempt complete. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Child status = 3. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Child output: Apr 24 13:52:46 ipa4.example.com certmonger[1715]: "Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection refused). Apr 24 13:52:46 ipa4.example.com certmonger[1715]: Server at https://ipa3.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa3.example.com:443; No route to host). Apr 24 13:52:46 ipa4.example.com certmonger[1715]: Server at https://ipa2.example.com/ipa/xml failed request, will retry: 4001 (RPC failed at server. ipa: Certificate Authority not found). Apr 24 13:52:46 ipa4.example.com certmonger[1715]: " Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Certificate not (yet?) issued. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Request1('20180424115242') moved to state 'CA_UNREACHABLE'
With kind regards, Jan Gardian
On 04/24/2018 12:24 PM, Jan Gardian via FreeIPA-users wrote:
Hello,
I checked and we already have correct permission for mentioned cert files:
[root@ipa2 ~]# ls -la /etc/ipa/ca.crt -rw-r--r--. 1 root root 5201 Apr 18 09:43 /etc/ipa/ca.crt [root@ipa2 ~]# ls -la /var/lib/ipa/ra-agent.* -r--r-----. 1 root ipaapi 1854 Apr 18 09:50 /var/lib/ipa/ra-agent.key -r--r-----. 1 root ipaapi 1423 Apr 18 09:50 /var/lib/ipa/ra-agent.pem
And when doing replica install at ipa4 it still tries to get certificate from itself and not from master ipa2: [root@ipa4 ~]# getcert list Number of certificates and requests being tracked: 1. Request ID '20180424101635': status: CA_REJECTED ca-error: Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection refused). stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert'
CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv EXAMPLE-COM track: yes auto-renew: yes
With kind regards, Jan Gardian
On 04/24/2018 10:41 AM, Florence Blanc-Renaud wrote:
On 04/19/2018 06:34 PM, r hartikainen via FreeIPA-users wrote: > Hello > > I got this same error with replica installation on rhel 7.4 after > the OS was hardened with openscap. Pure base OS install without any > additional hardening did work without problems. I was doing replica > immediately after setting up the new primary. > > Also, with same scap policy the fresh primary ipa did not allow any > login at webui. In my case I believe it was about some security > setting but have not yet had time to debug which one. Dunno where to > start the debug though. > > br, > risto > > Sent from my iPad > > On 19 Apr 2018, at 18.24, Jan Gardian via FreeIPA-users > <freeipa-users@lists.fedorahosted.org > mailto:freeipa-users@lists.fedorahosted.org> wrote: > >> Hello, >> >> We had two ipa replicas ipa1 with CA and ipa2. Those servers were >> on Ubuntu 16. >> >> I successfully installed ipa3 replica with CA that is running on >> newer version of IPA and Centos 7. After that I stopped old ipa2 >> and successfully installed new ipa2 with CA on Centos 7. Lastly I >> setup CA master to be new ipa2 following >> https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Proc... >> >> and turned off old ipa1 server. >> >> Problem occurred when I was installing replica with CA to new ipa1 >> server running at Centos 7. >> I can successfully install ipa client and create ticket under admin >> user but when trying to install replica it fails with "ERROR >> Certificate issuance failed (CA_UNREACHABLE)". Somehow it tries to >> get certificates during replica install from ipa1 server when it >> does not have yet httpd installed. >> >> I thought it could be problem that certificate was primary created >> at old ipa1 and we have it signed by our own certificates as well >> so I created another ipa4 server on Centos 7. And again it crashed >> at the same point trying to get certificate from itself when it did >> not have httpd installed yet. >> >> OS: CentOS Linux release 7.4.1708 >> IPA: VERSION: 4.5.0, API_VERSION: 2.228 >> >> Attached are logs from ipa client installation and ipa replica >> installation for ipa4 server. >> Please ask if you require any different logs. I tried also to >> follow debugging from >> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... >> >> but in my case it end earlier because it try to get certificate >> from itself and does not get to master. This can be also seen in >> output of command getcert list(in attachement). >> >> >> Thank you for checking. >> >> >> With kind regards, >> *Ján Gardian* >> Administrator >> <ipa4_debug> >> _______________________________________________ >> 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 > > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to > freeipa-users-leave@lists.fedorahosted.org > Hi,
the issue is probably linked to the root's umask setting on the master. When umask is too restrictive, the httpd server is not able to read the CA file and establish a secure connection with Dogtag. This is a known issue [1], the workaround is to modify the cert file permissions: chmod 644 /etc/ipa/ca.crt chmod 440 /var/lib/ipa/ra-agent.{key|pem}
HTH, Flo
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Hello,
I can see lot of warnings but for me most essentials are probably those: May 04 10:15:35 ipa2.example.com server[31620]: WARNING: Problem with JAR file [/usr/share/pki/server/common/lib/symkey.jar], exists: [false], canRead: [false] May 04 10:15:35 ipa2.example.com server[31620]: WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'enableOCSP' to 'false' did not find a matching property. May 04 10:15:35 ipa2.example.com server[31620]: WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspResponderURL' to 'http://ipa2.example.com:8080/ca/ocsp' did not find a matching property. May 04 10:15:35 ipa2.example.com server[31620]: WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspResponderCertNickname' to 'ocspSigningCert cert-pki-ca' did not find a matching property.
Were does pki get those properties? Is it some config?
Whole log file from restart attached.
Thanks.
With kind regards, Jan Gardian
On 05/03/2018 09:18 PM, Rob Crittenden wrote:
Jan Gardian via FreeIPA-users wrote:
Hello,
Do you have some idea why we get "Certificate Authority not found" ?
IPA proxies requests to the CA through tomcat. Not Found means that the CA webapp wasn't running in tomcat. You can try restarting pki-tomcatd and seeing what errors are reported in the logs.
rob
Thanks.
With kind regards. Jan Gardian
On 04/26/2018 10:57 AM, Jan Gardian via FreeIPA-users wrote:
Hello,
Permission of cert files at ipa2 and ipa3 are ok. I was installing replica under admin user. Master CA should be setup but it still crash with CA not found. I was still able to create ipa2 and ipa3 replica with old ipa1(ubuntu 16) server without problem. Bellow are also error_logs from httpd and certmonger. Any idea what else I can check? Our ipa CA is signed by our own CA, could this cause some problems?
[root@ipa4 ~]# klist -kt /etc/krb5.keytab Keytab name: FILE:/etc/krb5.keytab KVNO Timestamp Principal
1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM [root@ipa4 ~]# kvno host/`hostname` host/ipa4.example.com@EXAMPLE.COM: kvno = 1
ipa-replica-install --setup-ca fails at the same point: Configuring directory server (dirsrv) [1/3]: configuring TLS for DS instance [error] RuntimeError: Certificate issuance failed (CA_UNREACHABLE) Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up.
ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall): ERROR Certificate issuance failed (CA_UNREACHABLE) ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall): ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information
Master CA setup to be ipa2: [root@ipa2 ~]# grep ca.crl.MasterCRL.enableCRLUpdates /etc/pki/pki-tomcat/ca/CS.cfg ca.crl.MasterCRL.enableCRLUpdates=true
[root@ipa3 ~]# grep ca.crl.MasterCRL.enableCRLUpdates /etc/pki/pki-tomcat/ca/CS.cfg ca.crl.MasterCRL.enableCRLUpdates=false
ipa4 certmonger logs: Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Certificate submission still ongoing. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Will revisit Request1('20180426082737') on traffic from 15. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Certificate submission attempt complete. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Child status = 3. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Child output: Apr 26 10:27:38 ipa4.example.com certmonger[1713]: "Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection ref Apr 26 10:27:38 ipa4.example.com certmonger[1713]: Server at https://ipa3.example.com/ipa/xml failed request, will retry: 4001 (RPC failed at server. ipa: Certificate Authority not found). Apr 26 10:27:38 ipa4.example.com certmonger[1713]: Server at https://ipa2.example.com/ipa/xml failed request, will retry: 4001 (RPC failed at server. ipa: Certificate Authority not found). Apr 26 10:27:38 ipa4.example.com certmonger[1713]: " Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Certificate not (yet?) issued. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Request1('20180426082737') moved to state 'CA_UNREACHABLE'
ipa3 httpd/error_log: [Thu Apr 26 10:27:38.375982 2018] [auth_gssapi:error] [pid 1724] [client 1.1.1.4:35234] NO AUTH DATA Client did not send any authentication headers, referer: https://ipa3.example.com/ipa/xml [Thu Apr 26 10:27:38.422274 2018] [:error] [pid 1720] ipa: INFO: [xmlserver] host/ipa4.example.com@EXAMPLE.COM: cert_request(u'XYZ...==', profile_id=u'caIPAserviceCert', principal=u'ldap/ipa4.example.com@EXAMPLE.COM', add=True, version=u'2.51'): NotFound
[root@ipa3 ~]# ipa ca-show ipa ipa: ERROR: ipa: Certificate Authority not found
ipa2 httpd/error_log: [Thu Apr 26 10:27:14.476884 2018] [:error] [pid 7564] ipa: INFO: [jsonserver_kerb] admin@EXAMPLE.COM: server_conncheck(u'ipa2.example.com', u'ipa4.example.com', version=u'2.162'): SUCCESS [Thu Apr 26 10:27:38.443093 2018] [auth_gssapi:error] [pid 8336] [client 1.1.1.4:59674] NO AUTH DATA Client did not send any authentication headers, referer: https://ipa2.example.com/ipa/xml [Thu Apr 26 10:27:38.503320 2018] [:error] [pid 7565] ipa: INFO: [xmlserver] host/ipa4.example.com@EXAMPLE.COM: cert_request(u'XYZ...==', profile_id=u'caIPAserviceCert', principal=u'ldap/ipa4.example.com@EXAMPLE.COM', add=True, version=u'2.51'): NotFound
[root@ipa2 ~]# ipa ca-show ipa ipa: ERROR: ipa: Certificate Authority not found
With kind regards, Jan Gardian
On 04/24/2018 02:52 PM, Rob Crittenden wrote:
Jan Gardian via FreeIPA-users wrote:
Hello,
I setup more verbose output for certmonger and tested to install ipa replica at ipa4. What credentials does certmonger use? Installing replica is run with admin credentials.
certmonger uses the host principal in /etc/krb5.keytab
I'd check on the remote servers /var/log/httpd/error_log to see if anything was logged for the cert requests. Invalid credentials seems like an odd error.
You can also check on the validity of the keytab with:
# klist -kt /etc/krb5.keytab # kvno host/`hostname`
The kvno should match.
IIRC you are promoting a client to a replica which means there shouldn't be any issues with replication of the host principal.
rob
Servers ipa2 and ipa3 are up. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Certificate submission still ongoing. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Will revisit Request1('20180424112419') on traffic from 15. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Certificate submission attempt complete. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Child status = 2. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Child output: Apr 24 13:24:19 ipa4.example.com certmonger[1755]: "Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection refused). Apr 24 13:24:19 ipa4.example.com certmonger[1755]: Server at https://ipa3.example.com/ipa/xml denied our request, giving up: 2100 (RPC failed at server. Insufficient access: Invalid credentials). Apr 24 13:24:19 ipa4.example.com certmonger[1755]: " Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Certificate not (yet?) issued. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Request1('20180424112419') moved to state 'NEED_TO_NOTIFY_REJECTION'
Only ipa2 is up Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Certificate submission still ongoing. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Will revisit Request1('20180424115242') on traffic from 15. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Certificate submission attempt complete. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Child status = 3. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Child output: Apr 24 13:52:46 ipa4.example.com certmonger[1715]: "Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection refused). Apr 24 13:52:46 ipa4.example.com certmonger[1715]: Server at https://ipa3.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa3.example.com:443; No route to host). Apr 24 13:52:46 ipa4.example.com certmonger[1715]: Server at https://ipa2.example.com/ipa/xml failed request, will retry: 4001 (RPC failed at server. ipa: Certificate Authority not found). Apr 24 13:52:46 ipa4.example.com certmonger[1715]: " Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Certificate not (yet?) issued. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Request1('20180424115242') moved to state 'CA_UNREACHABLE'
With kind regards, Jan Gardian
On 04/24/2018 12:24 PM, Jan Gardian via FreeIPA-users wrote:
Hello,
I checked and we already have correct permission for mentioned cert files:
[root@ipa2 ~]# ls -la /etc/ipa/ca.crt -rw-r--r--. 1 root root 5201 Apr 18 09:43 /etc/ipa/ca.crt [root@ipa2 ~]# ls -la /var/lib/ipa/ra-agent.* -r--r-----. 1 root ipaapi 1854 Apr 18 09:50 /var/lib/ipa/ra-agent.key -r--r-----. 1 root ipaapi 1423 Apr 18 09:50 /var/lib/ipa/ra-agent.pem
And when doing replica install at ipa4 it still tries to get certificate from itself and not from master ipa2: [root@ipa4 ~]# getcert list Number of certificates and requests being tracked: 1. Request ID '20180424101635': status: CA_REJECTED ca-error: Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection refused). stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert'
CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv EXAMPLE-COM track: yes auto-renew: yes
With kind regards, Jan Gardian
On 04/24/2018 10:41 AM, Florence Blanc-Renaud wrote: > On 04/19/2018 06:34 PM, r hartikainen via FreeIPA-users wrote: >> Hello >> >> I got this same error with replica installation on rhel 7.4 after >> the OS was hardened with openscap. Pure base OS install without >> any >> additional hardening did work without problems. I was doing >> replica >> immediately after setting up the new primary. >> >> Also, with same scap policy the fresh primary ipa did not allow >> any >> login at webui. In my case I believe it was about some security >> setting but have not yet had time to debug which one. Dunno >> where to >> start the debug though. >> >> br, >> risto >> >> Sent from my iPad >> >> On 19 Apr 2018, at 18.24, Jan Gardian via FreeIPA-users >> <freeipa-users@lists.fedorahosted.org >> mailto:freeipa-users@lists.fedorahosted.org> wrote: >> >>> Hello, >>> >>> We had two ipa replicas ipa1 with CA and ipa2. Those servers were >>> on Ubuntu 16. >>> >>> I successfully installed ipa3 replica with CA that is running on >>> newer version of IPA and Centos 7. After that I stopped old ipa2 >>> and successfully installed new ipa2 with CA on Centos 7. Lastly I >>> setup CA master to be new ipa2 following >>> https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Proc... >>> >>> and turned off old ipa1 server. >>> >>> Problem occurred when I was installing replica with CA to new >>> ipa1 >>> server running at Centos 7. >>> I can successfully install ipa client and create ticket under >>> admin >>> user but when trying to install replica it fails with "ERROR >>> Certificate issuance failed (CA_UNREACHABLE)". Somehow it >>> tries to >>> get certificates during replica install from ipa1 server when it >>> does not have yet httpd installed. >>> >>> I thought it could be problem that certificate was primary >>> created >>> at old ipa1 and we have it signed by our own certificates as well >>> so I created another ipa4 server on Centos 7. And again it >>> crashed >>> at the same point trying to get certificate from itself when >>> it did >>> not have httpd installed yet. >>> >>> OS: CentOS Linux release 7.4.1708 >>> IPA: VERSION: 4.5.0, API_VERSION: 2.228 >>> >>> Attached are logs from ipa client installation and ipa replica >>> installation for ipa4 server. >>> Please ask if you require any different logs. I tried also to >>> follow debugging from >>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... >>> >>> but in my case it end earlier because it try to get certificate >>> from itself and does not get to master. This can be also seen in >>> output of command getcert list(in attachement). >>> >>> >>> Thank you for checking. >>> >>> >>> With kind regards, >>> *Ján Gardian* >>> Administrator >>> <ipa4_debug> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org >> To unsubscribe send an email to >> freeipa-users-leave@lists.fedorahosted.org >> > Hi, > > the issue is probably linked to the root's umask setting on the > master. When umask is too restrictive, the httpd server is not able > to read the CA file and establish a secure connection with Dogtag. > This is a known issue [1], the workaround is to modify the cert > file > permissions: > chmod 644 /etc/ipa/ca.crt > chmod 440 /var/lib/ipa/ra-agent.{key|pem} > > HTH, > Flo > > [1] https://pagure.io/freeipa/issue/7193 _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Hello,
Were you able to find some useful information from provided pki logs?
Thank you.
On 05/04/2018 10:25 AM, Jan Gardian via FreeIPA-users wrote:
Hello,
I can see lot of warnings but for me most essentials are probably those: May 04 10:15:35 ipa2.example.com server[31620]: WARNING: Problem with JAR file [/usr/share/pki/server/common/lib/symkey.jar], exists: [false], canRead: [false] May 04 10:15:35 ipa2.example.com server[31620]: WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'enableOCSP' to 'false' did not find a matching property. May 04 10:15:35 ipa2.example.com server[31620]: WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspResponderURL' to 'http://ipa2.example.com:8080/ca/ocsp' did not find a matching property. May 04 10:15:35 ipa2.example.com server[31620]: WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspResponderCertNickname' to 'ocspSigningCert cert-pki-ca' did not find a matching property.
Were does pki get those properties? Is it some config?
Whole log file from restart attached.
Thanks.
With kind regards, Jan Gardian
On 05/03/2018 09:18 PM, Rob Crittenden wrote:
Jan Gardian via FreeIPA-users wrote:
Hello,
Do you have some idea why we get "Certificate Authority not found" ?
IPA proxies requests to the CA through tomcat. Not Found means that the CA webapp wasn't running in tomcat. You can try restarting pki-tomcatd and seeing what errors are reported in the logs.
rob
Thanks.
With kind regards. Jan Gardian
On 04/26/2018 10:57 AM, Jan Gardian via FreeIPA-users wrote:
Hello,
Permission of cert files at ipa2 and ipa3 are ok. I was installing replica under admin user. Master CA should be setup but it still crash with CA not found. I was still able to create ipa2 and ipa3 replica with old ipa1(ubuntu 16) server without problem. Bellow are also error_logs from httpd and certmonger. Any idea what else I can check? Our ipa CA is signed by our own CA, could this cause some problems?
[root@ipa4 ~]# klist -kt /etc/krb5.keytab Keytab name: FILE:/etc/krb5.keytab KVNO Timestamp Principal
1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM [root@ipa4 ~]# kvno host/`hostname` host/ipa4.example.com@EXAMPLE.COM: kvno = 1
ipa-replica-install --setup-ca fails at the same point: Configuring directory server (dirsrv) [1/3]: configuring TLS for DS instance [error] RuntimeError: Certificate issuance failed (CA_UNREACHABLE) Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up.
ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall): ERROR Certificate issuance failed (CA_UNREACHABLE) ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall): ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information
Master CA setup to be ipa2: [root@ipa2 ~]# grep ca.crl.MasterCRL.enableCRLUpdates /etc/pki/pki-tomcat/ca/CS.cfg ca.crl.MasterCRL.enableCRLUpdates=true
[root@ipa3 ~]# grep ca.crl.MasterCRL.enableCRLUpdates /etc/pki/pki-tomcat/ca/CS.cfg ca.crl.MasterCRL.enableCRLUpdates=false
ipa4 certmonger logs: Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Certificate submission still ongoing. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Will revisit Request1('20180426082737') on traffic from 15. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Certificate submission attempt complete. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Child status = 3. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Child output: Apr 26 10:27:38 ipa4.example.com certmonger[1713]: "Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection ref Apr 26 10:27:38 ipa4.example.com certmonger[1713]: Server at https://ipa3.example.com/ipa/xml failed request, will retry: 4001 (RPC failed at server. ipa: Certificate Authority not found). Apr 26 10:27:38 ipa4.example.com certmonger[1713]: Server at https://ipa2.example.com/ipa/xml failed request, will retry: 4001 (RPC failed at server. ipa: Certificate Authority not found). Apr 26 10:27:38 ipa4.example.com certmonger[1713]: " Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Certificate not (yet?) issued. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Request1('20180426082737') moved to state 'CA_UNREACHABLE'
ipa3 httpd/error_log: [Thu Apr 26 10:27:38.375982 2018] [auth_gssapi:error] [pid 1724] [client 1.1.1.4:35234] NO AUTH DATA Client did not send any authentication headers, referer: https://ipa3.example.com/ipa/xml [Thu Apr 26 10:27:38.422274 2018] [:error] [pid 1720] ipa: INFO: [xmlserver] host/ipa4.example.com@EXAMPLE.COM: cert_request(u'XYZ...==', profile_id=u'caIPAserviceCert', principal=u'ldap/ipa4.example.com@EXAMPLE.COM', add=True, version=u'2.51'): NotFound
[root@ipa3 ~]# ipa ca-show ipa ipa: ERROR: ipa: Certificate Authority not found
ipa2 httpd/error_log: [Thu Apr 26 10:27:14.476884 2018] [:error] [pid 7564] ipa: INFO: [jsonserver_kerb] admin@EXAMPLE.COM: server_conncheck(u'ipa2.example.com', u'ipa4.example.com', version=u'2.162'): SUCCESS [Thu Apr 26 10:27:38.443093 2018] [auth_gssapi:error] [pid 8336] [client 1.1.1.4:59674] NO AUTH DATA Client did not send any authentication headers, referer: https://ipa2.example.com/ipa/xml [Thu Apr 26 10:27:38.503320 2018] [:error] [pid 7565] ipa: INFO: [xmlserver] host/ipa4.example.com@EXAMPLE.COM: cert_request(u'XYZ...==', profile_id=u'caIPAserviceCert', principal=u'ldap/ipa4.example.com@EXAMPLE.COM', add=True, version=u'2.51'): NotFound
[root@ipa2 ~]# ipa ca-show ipa ipa: ERROR: ipa: Certificate Authority not found
With kind regards, Jan Gardian
On 04/24/2018 02:52 PM, Rob Crittenden wrote:
Jan Gardian via FreeIPA-users wrote:
Hello,
I setup more verbose output for certmonger and tested to install ipa replica at ipa4. What credentials does certmonger use? Installing replica is run with admin credentials.
certmonger uses the host principal in /etc/krb5.keytab
I'd check on the remote servers /var/log/httpd/error_log to see if anything was logged for the cert requests. Invalid credentials seems like an odd error.
You can also check on the validity of the keytab with:
# klist -kt /etc/krb5.keytab # kvno host/`hostname`
The kvno should match.
IIRC you are promoting a client to a replica which means there shouldn't be any issues with replication of the host principal.
rob
Servers ipa2 and ipa3 are up. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Certificate submission still ongoing. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Will revisit Request1('20180424112419') on traffic from 15. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Certificate submission attempt complete. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Child status = 2. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Child output: Apr 24 13:24:19 ipa4.example.com certmonger[1755]: "Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection refused). Apr 24 13:24:19 ipa4.example.com certmonger[1755]: Server at https://ipa3.example.com/ipa/xml denied our request, giving up: 2100 (RPC failed at server. Insufficient access: Invalid credentials). Apr 24 13:24:19 ipa4.example.com certmonger[1755]: " Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Certificate not (yet?) issued. Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 13:24:19 [1755] Request1('20180424112419') moved to state 'NEED_TO_NOTIFY_REJECTION'
Only ipa2 is up Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Certificate submission still ongoing. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Will revisit Request1('20180424115242') on traffic from 15. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Certificate submission attempt complete. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Child status = 3. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Child output: Apr 24 13:52:46 ipa4.example.com certmonger[1715]: "Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection refused). Apr 24 13:52:46 ipa4.example.com certmonger[1715]: Server at https://ipa3.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa3.example.com:443; No route to host). Apr 24 13:52:46 ipa4.example.com certmonger[1715]: Server at https://ipa2.example.com/ipa/xml failed request, will retry: 4001 (RPC failed at server. ipa: Certificate Authority not found). Apr 24 13:52:46 ipa4.example.com certmonger[1715]: " Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Certificate not (yet?) issued. Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 13:52:46 [1715] Request1('20180424115242') moved to state 'CA_UNREACHABLE'
With kind regards, Jan Gardian
On 04/24/2018 12:24 PM, Jan Gardian via FreeIPA-users wrote: > Hello, > > I checked and we already have correct permission for mentioned cert > files: > > [root@ipa2 ~]# ls -la /etc/ipa/ca.crt > -rw-r--r--. 1 root root 5201 Apr 18 09:43 /etc/ipa/ca.crt > [root@ipa2 ~]# ls -la /var/lib/ipa/ra-agent.* > -r--r-----. 1 root ipaapi 1854 Apr 18 09:50 > /var/lib/ipa/ra-agent.key > -r--r-----. 1 root ipaapi 1423 Apr 18 09:50 > /var/lib/ipa/ra-agent.pem > > And when doing replica install at ipa4 it still tries to get > certificate from itself and not from master ipa2: > [root@ipa4 ~]# getcert list > Number of certificates and requests being tracked: 1. > Request ID '20180424101635': > status: CA_REJECTED > ca-error: Server at https://ipa4.example.com/ipa/xml failed > request, will retry: -504 (libcurl failed to execute the HTTP POST > transaction, explaining: Failed connect to ipa4.example.com:443; > Connection refused). > stuck: yes > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS > > Certificate DB',pinfile='/etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert' > > > CA: IPA > issuer: > subject: > expires: unknown > pre-save command: > post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv > EXAMPLE-COM > track: yes > auto-renew: yes > > > > With kind regards, > Jan Gardian > > > On 04/24/2018 10:41 AM, Florence Blanc-Renaud wrote: >> On 04/19/2018 06:34 PM, r hartikainen via FreeIPA-users wrote: >>> Hello >>> >>> I got this same error with replica installation on rhel 7.4 after >>> the OS was hardened with openscap. Pure base OS install >>> without any >>> additional hardening did work without problems. I was doing >>> replica >>> immediately after setting up the new primary. >>> >>> Also, with same scap policy the fresh primary ipa did not >>> allow any >>> login at webui. In my case I believe it was about some security >>> setting but have not yet had time to debug which one. Dunno >>> where to >>> start the debug though. >>> >>> br, >>> risto >>> >>> Sent from my iPad >>> >>> On 19 Apr 2018, at 18.24, Jan Gardian via FreeIPA-users >>> <freeipa-users@lists.fedorahosted.org >>> mailto:freeipa-users@lists.fedorahosted.org> wrote: >>> >>>> Hello, >>>> >>>> We had two ipa replicas ipa1 with CA and ipa2. Those servers >>>> were >>>> on Ubuntu 16. >>>> >>>> I successfully installed ipa3 replica with CA that is running on >>>> newer version of IPA and Centos 7. After that I stopped old ipa2 >>>> and successfully installed new ipa2 with CA on Centos 7. >>>> Lastly I >>>> setup CA master to be new ipa2 following >>>> https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Proc... >>>> >>>> and turned off old ipa1 server. >>>> >>>> Problem occurred when I was installing replica with CA to new >>>> ipa1 >>>> server running at Centos 7. >>>> I can successfully install ipa client and create ticket under >>>> admin >>>> user but when trying to install replica it fails with "ERROR >>>> Certificate issuance failed (CA_UNREACHABLE)". Somehow it >>>> tries to >>>> get certificates during replica install from ipa1 server when it >>>> does not have yet httpd installed. >>>> >>>> I thought it could be problem that certificate was primary >>>> created >>>> at old ipa1 and we have it signed by our own certificates as >>>> well >>>> so I created another ipa4 server on Centos 7. And again it >>>> crashed >>>> at the same point trying to get certificate from itself when >>>> it did >>>> not have httpd installed yet. >>>> >>>> OS: CentOS Linux release 7.4.1708 >>>> IPA: VERSION: 4.5.0, API_VERSION: 2.228 >>>> >>>> Attached are logs from ipa client installation and ipa replica >>>> installation for ipa4 server. >>>> Please ask if you require any different logs. I tried also to >>>> follow debugging from >>>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... >>>> >>>> but in my case it end earlier because it try to get certificate >>>> from itself and does not get to master. This can be also seen in >>>> output of command getcert list(in attachement). >>>> >>>> >>>> Thank you for checking. >>>> >>>> >>>> With kind regards, >>>> *Ján Gardian* >>>> Administrator >>>> <ipa4_debug> >>>> _______________________________________________ >>>> 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 >>> >>> _______________________________________________ >>> FreeIPA-users mailing list -- >>> freeipa-users@lists.fedorahosted.org >>> To unsubscribe send an email to >>> freeipa-users-leave@lists.fedorahosted.org >>> >> Hi, >> >> the issue is probably linked to the root's umask setting on the >> master. When umask is too restrictive, the httpd server is not >> able >> to read the CA file and establish a secure connection with Dogtag. >> This is a known issue [1], the workaround is to modify the cert >> file >> permissions: >> chmod 644 /etc/ipa/ca.crt >> chmod 440 /var/lib/ipa/ra-agent.{key|pem} >> >> HTH, >> Flo >> >> [1] https://pagure.io/freeipa/issue/7193 > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to > freeipa-users-leave@lists.fedorahosted.org _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Hello,
Update with new CentOS packages fixed this issue. CA is now found and replication finished. Thanks for help
With kind Regards, Jan Gardian
On 05/09/2018 10:32 AM, Jan Gardian via FreeIPA-users wrote:
Hello,
Were you able to find some useful information from provided pki logs?
Thank you.
On 05/04/2018 10:25 AM, Jan Gardian via FreeIPA-users wrote:
Hello,
I can see lot of warnings but for me most essentials are probably those: May 04 10:15:35 ipa2.example.com server[31620]: WARNING: Problem with JAR file [/usr/share/pki/server/common/lib/symkey.jar], exists: [false], canRead: [false] May 04 10:15:35 ipa2.example.com server[31620]: WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'enableOCSP' to 'false' did not find a matching property. May 04 10:15:35 ipa2.example.com server[31620]: WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspResponderURL' to 'http://ipa2.example.com:8080/ca/ocsp' did not find a matching property. May 04 10:15:35 ipa2.example.com server[31620]: WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspResponderCertNickname' to 'ocspSigningCert cert-pki-ca' did not find a matching property.
Were does pki get those properties? Is it some config?
Whole log file from restart attached.
Thanks.
With kind regards, Jan Gardian
On 05/03/2018 09:18 PM, Rob Crittenden wrote:
Jan Gardian via FreeIPA-users wrote:
Hello,
Do you have some idea why we get "Certificate Authority not found" ?
IPA proxies requests to the CA through tomcat. Not Found means that the CA webapp wasn't running in tomcat. You can try restarting pki-tomcatd and seeing what errors are reported in the logs.
rob
Thanks.
With kind regards. Jan Gardian
On 04/26/2018 10:57 AM, Jan Gardian via FreeIPA-users wrote:
Hello,
Permission of cert files at ipa2 and ipa3 are ok. I was installing replica under admin user. Master CA should be setup but it still crash with CA not found. I was still able to create ipa2 and ipa3 replica with old ipa1(ubuntu 16) server without problem. Bellow are also error_logs from httpd and certmonger. Any idea what else I can check? Our ipa CA is signed by our own CA, could this cause some problems?
[root@ipa4 ~]# klist -kt /etc/krb5.keytab Keytab name: FILE:/etc/krb5.keytab KVNO Timestamp Principal
1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM 1 04/26/2018 10:21:04 host/ipa4.example.com@EXAMPLE.COM [root@ipa4 ~]# kvno host/`hostname` host/ipa4.example.com@EXAMPLE.COM: kvno = 1
ipa-replica-install --setup-ca fails at the same point: Configuring directory server (dirsrv) [1/3]: configuring TLS for DS instance [error] RuntimeError: Certificate issuance failed (CA_UNREACHABLE) Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up.
ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall): ERROR Certificate issuance failed (CA_UNREACHABLE) ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall): ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information
Master CA setup to be ipa2: [root@ipa2 ~]# grep ca.crl.MasterCRL.enableCRLUpdates /etc/pki/pki-tomcat/ca/CS.cfg ca.crl.MasterCRL.enableCRLUpdates=true
[root@ipa3 ~]# grep ca.crl.MasterCRL.enableCRLUpdates /etc/pki/pki-tomcat/ca/CS.cfg ca.crl.MasterCRL.enableCRLUpdates=false
ipa4 certmonger logs: Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Certificate submission still ongoing. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Will revisit Request1('20180426082737') on traffic from 15. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Certificate submission attempt complete. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Child status = 3. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Child output: Apr 26 10:27:38 ipa4.example.com certmonger[1713]: "Server at https://ipa4.example.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa4.example.com:443; Connection ref Apr 26 10:27:38 ipa4.example.com certmonger[1713]: Server at https://ipa3.example.com/ipa/xml failed request, will retry: 4001 (RPC failed at server. ipa: Certificate Authority not found). Apr 26 10:27:38 ipa4.example.com certmonger[1713]: Server at https://ipa2.example.com/ipa/xml failed request, will retry: 4001 (RPC failed at server. ipa: Certificate Authority not found). Apr 26 10:27:38 ipa4.example.com certmonger[1713]: " Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Certificate not (yet?) issued. Apr 26 10:27:38 ipa4.example.com certmonger[1713]: 2018-04-26 10:27:38 [1713] Request1('20180426082737') moved to state 'CA_UNREACHABLE'
ipa3 httpd/error_log: [Thu Apr 26 10:27:38.375982 2018] [auth_gssapi:error] [pid 1724] [client 1.1.1.4:35234] NO AUTH DATA Client did not send any authentication headers, referer: https://ipa3.example.com/ipa/xml [Thu Apr 26 10:27:38.422274 2018] [:error] [pid 1720] ipa: INFO: [xmlserver] host/ipa4.example.com@EXAMPLE.COM: cert_request(u'XYZ...==', profile_id=u'caIPAserviceCert', principal=u'ldap/ipa4.example.com@EXAMPLE.COM', add=True, version=u'2.51'): NotFound
[root@ipa3 ~]# ipa ca-show ipa ipa: ERROR: ipa: Certificate Authority not found
ipa2 httpd/error_log: [Thu Apr 26 10:27:14.476884 2018] [:error] [pid 7564] ipa: INFO: [jsonserver_kerb] admin@EXAMPLE.COM: server_conncheck(u'ipa2.example.com', u'ipa4.example.com', version=u'2.162'): SUCCESS [Thu Apr 26 10:27:38.443093 2018] [auth_gssapi:error] [pid 8336] [client 1.1.1.4:59674] NO AUTH DATA Client did not send any authentication headers, referer: https://ipa2.example.com/ipa/xml [Thu Apr 26 10:27:38.503320 2018] [:error] [pid 7565] ipa: INFO: [xmlserver] host/ipa4.example.com@EXAMPLE.COM: cert_request(u'XYZ...==', profile_id=u'caIPAserviceCert', principal=u'ldap/ipa4.example.com@EXAMPLE.COM', add=True, version=u'2.51'): NotFound
[root@ipa2 ~]# ipa ca-show ipa ipa: ERROR: ipa: Certificate Authority not found
With kind regards, Jan Gardian
On 04/24/2018 02:52 PM, Rob Crittenden wrote:
Jan Gardian via FreeIPA-users wrote: > Hello, > > I setup more verbose output for certmonger and tested to install > ipa > replica at ipa4. What credentials does certmonger use? Installing > replica is run with admin credentials. certmonger uses the host principal in /etc/krb5.keytab
I'd check on the remote servers /var/log/httpd/error_log to see if anything was logged for the cert requests. Invalid credentials seems like an odd error.
You can also check on the validity of the keytab with:
# klist -kt /etc/krb5.keytab # kvno host/`hostname`
The kvno should match.
IIRC you are promoting a client to a replica which means there shouldn't be any issues with replication of the host principal.
rob
> Servers ipa2 and ipa3 are up. > Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 > 13:24:19 > [1755] Certificate submission still ongoing. > Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 > 13:24:19 > [1755] Will revisit Request1('20180424112419') on traffic from 15. > Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 > 13:24:19 > [1755] Certificate submission attempt complete. > Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 > 13:24:19 > [1755] Child status = 2. > Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 > 13:24:19 > [1755] Child output: > Apr 24 13:24:19 ipa4.example.com certmonger[1755]: "Server at > https://ipa4.example.com/ipa/xml failed request, will retry: -504 > (libcurl failed to execute the HTTP POST transaction, > explaining: Failed > connect to ipa4.example.com:443; Connection refused). > Apr 24 13:24:19 ipa4.example.com certmonger[1755]: Server at > https://ipa3.example.com/ipa/xml denied our request, giving up: > 2100 > (RPC failed at server. Insufficient access: Invalid credentials). > Apr 24 13:24:19 ipa4.example.com certmonger[1755]: " > Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 > 13:24:19 > [1755] Certificate not (yet?) issued. > Apr 24 13:24:19 ipa4.example.com certmonger[1755]: 2018-04-24 > 13:24:19 > [1755] Request1('20180424112419') moved to state > 'NEED_TO_NOTIFY_REJECTION' > > > Only ipa2 is up > Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 > 13:52:46 > [1715] Certificate submission still ongoing. > Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 > 13:52:46 > [1715] Will revisit Request1('20180424115242') on traffic from 15. > Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 > 13:52:46 > [1715] Certificate submission attempt complete. > Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 > 13:52:46 > [1715] Child status = 3. > Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 > 13:52:46 > [1715] Child output: > Apr 24 13:52:46 ipa4.example.com certmonger[1715]: "Server at > https://ipa4.example.com/ipa/xml failed request, will retry: -504 > (libcurl failed to execute the HTTP POST transaction, > explaining: Failed > connect to ipa4.example.com:443; Connection refused). > Apr 24 13:52:46 ipa4.example.com certmonger[1715]: Server at > https://ipa3.example.com/ipa/xml failed request, will retry: -504 > (libcurl failed to execute the HTTP POST transaction, > explaining: Failed > connect to ipa3.example.com:443; No route to host). > Apr 24 13:52:46 ipa4.example.com certmonger[1715]: Server at > https://ipa2.example.com/ipa/xml failed request, will retry: > 4001 (RPC > failed at server. ipa: Certificate Authority not found). > Apr 24 13:52:46 ipa4.example.com certmonger[1715]: " > Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 > 13:52:46 > [1715] Certificate not (yet?) issued. > Apr 24 13:52:46 ipa4.example.com certmonger[1715]: 2018-04-24 > 13:52:46 > [1715] Request1('20180424115242') moved to state 'CA_UNREACHABLE' > > > With kind regards, > Jan Gardian > > On 04/24/2018 12:24 PM, Jan Gardian via FreeIPA-users wrote: >> Hello, >> >> I checked and we already have correct permission for mentioned >> cert >> files: >> >> [root@ipa2 ~]# ls -la /etc/ipa/ca.crt >> -rw-r--r--. 1 root root 5201 Apr 18 09:43 /etc/ipa/ca.crt >> [root@ipa2 ~]# ls -la /var/lib/ipa/ra-agent.* >> -r--r-----. 1 root ipaapi 1854 Apr 18 09:50 >> /var/lib/ipa/ra-agent.key >> -r--r-----. 1 root ipaapi 1423 Apr 18 09:50 >> /var/lib/ipa/ra-agent.pem >> >> And when doing replica install at ipa4 it still tries to get >> certificate from itself and not from master ipa2: >> [root@ipa4 ~]# getcert list >> Number of certificates and requests being tracked: 1. >> Request ID '20180424101635': >> status: CA_REJECTED >> ca-error: Server at https://ipa4.example.com/ipa/xml failed >> request, will retry: -504 (libcurl failed to execute the HTTP POST >> transaction, explaining: Failed connect to ipa4.example.com:443; >> Connection refused). >> stuck: yes >> key pair storage: >> type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert',token='NSS >> >> Certificate >> DB',pinfile='/etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE-COM',nickname='Server-Cert' >> >> >> CA: IPA >> issuer: >> subject: >> expires: unknown >> pre-save command: >> post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv >> EXAMPLE-COM >> track: yes >> auto-renew: yes >> >> >> >> With kind regards, >> Jan Gardian >> >> >> On 04/24/2018 10:41 AM, Florence Blanc-Renaud wrote: >>> On 04/19/2018 06:34 PM, r hartikainen via FreeIPA-users wrote: >>>> Hello >>>> >>>> I got this same error with replica installation on rhel 7.4 >>>> after >>>> the OS was hardened with openscap. Pure base OS install >>>> without any >>>> additional hardening did work without problems. I was doing >>>> replica >>>> immediately after setting up the new primary. >>>> >>>> Also, with same scap policy the fresh primary ipa did not >>>> allow any >>>> login at webui. In my case I believe it was about some security >>>> setting but have not yet had time to debug which one. Dunno >>>> where to >>>> start the debug though. >>>> >>>> br, >>>> risto >>>> >>>> Sent from my iPad >>>> >>>> On 19 Apr 2018, at 18.24, Jan Gardian via FreeIPA-users >>>> <freeipa-users@lists.fedorahosted.org >>>> mailto:freeipa-users@lists.fedorahosted.org> wrote: >>>> >>>>> Hello, >>>>> >>>>> We had two ipa replicas ipa1 with CA and ipa2. Those servers >>>>> were >>>>> on Ubuntu 16. >>>>> >>>>> I successfully installed ipa3 replica with CA that is >>>>> running on >>>>> newer version of IPA and Centos 7. After that I stopped old >>>>> ipa2 >>>>> and successfully installed new ipa2 with CA on Centos 7. >>>>> Lastly I >>>>> setup CA master to be new ipa2 following >>>>> https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master#Proc... >>>>> >>>>> and turned off old ipa1 server. >>>>> >>>>> Problem occurred when I was installing replica with CA to >>>>> new ipa1 >>>>> server running at Centos 7. >>>>> I can successfully install ipa client and create ticket >>>>> under admin >>>>> user but when trying to install replica it fails with "ERROR >>>>> Certificate issuance failed (CA_UNREACHABLE)". Somehow it >>>>> tries to >>>>> get certificates during replica install from ipa1 server >>>>> when it >>>>> does not have yet httpd installed. >>>>> >>>>> I thought it could be problem that certificate was primary >>>>> created >>>>> at old ipa1 and we have it signed by our own certificates as >>>>> well >>>>> so I created another ipa4 server on Centos 7. And again it >>>>> crashed >>>>> at the same point trying to get certificate from itself when >>>>> it did >>>>> not have httpd installed yet. >>>>> >>>>> OS: CentOS Linux release 7.4.1708 >>>>> IPA: VERSION: 4.5.0, API_VERSION: 2.228 >>>>> >>>>> Attached are logs from ipa client installation and ipa replica >>>>> installation for ipa4 server. >>>>> Please ask if you require any different logs. I tried also to >>>>> follow debugging from >>>>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... >>>>> >>>>> but in my case it end earlier because it try to get certificate >>>>> from itself and does not get to master. This can be also >>>>> seen in >>>>> output of command getcert list(in attachement). >>>>> >>>>> >>>>> Thank you for checking. >>>>> >>>>> >>>>> With kind regards, >>>>> *Ján Gardian* >>>>> Administrator >>>>> <ipa4_debug> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> _______________________________________________ >>>> FreeIPA-users mailing list -- >>>> freeipa-users@lists.fedorahosted.org >>>> To unsubscribe send an email to >>>> freeipa-users-leave@lists.fedorahosted.org >>>> >>> Hi, >>> >>> the issue is probably linked to the root's umask setting on the >>> master. When umask is too restrictive, the httpd server is not >>> able >>> to read the CA file and establish a secure connection with >>> Dogtag. >>> This is a known issue [1], the workaround is to modify the >>> cert file >>> permissions: >>> chmod 644 /etc/ipa/ca.crt >>> chmod 440 /var/lib/ipa/ra-agent.{key|pem} >>> >>> HTH, >>> Flo >>> >>> [1] https://pagure.io/freeipa/issue/7193 >> _______________________________________________ >> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org >> To unsubscribe send an email to >> freeipa-users-leave@lists.fedorahosted.org > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to > freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list --freeipa-users@lists.fedorahosted.org To unsubscribe send an email tofreeipa-users-leave@lists.fedorahosted.org
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Florence Blanc-Renaud -
Jan Gardian -
r hartikainen -
Rob Crittenden