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#Procedure_in_FreeIPA_4.0_or_later
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.fedorahosted.org/thread/SZKAQDRCRGWV3ZIEJNAVRG2LHLDIS3MJ/
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-le...@lists.fedorahosted.org
<mailto:freeipa-users-le...@lists.fedorahosted.org>
_______________________________________________
FreeIPA-users mailing list --
freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to
freeipa-users-le...@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-le...@lists.fedorahosted.org
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to
freeipa-users-le...@lists.fedorahosted.org