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#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
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
