On 01/11/2018 05:16 PM, lejeczek via FreeIPA-users wrote:
On 11/01/18 15:02, Rob Crittenden wrote:
> lejeczek via FreeIPA-users wrote:
>> hi
>>
>> not an python nor ipa expert here, looking at certmonger.py
>>
>> what does such an error indicate? :
>>
>> ipa : DEBUG certmonger request is in state
>> dbus.String(u'NEWLY_ADDED_READING_KEYINFO', variant_level=1)
>> ipa : DEBUG certmonger request is in state
>> dbus.String(u'CA_UNREACHABLE', variant_level=1)
>> ipa : DEBUG Traceback (most recent call last):
>> File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
>> line 504, in start_creation
>> run_step(full_msg, method)
>> File
"/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
>> line 494, in run_step
>> method()
>> File
>> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py",
line
>> 824, in __enable_ssl
>> post_command=cmd)
>> File
"/usr/lib/python2.7/site-packages/ipalib/install/certmonger.py",
>> line 317, in request_and_wait_for_cert
>> raise RuntimeError("Certificate issuance failed
>> ({})".format(state))
>> RuntimeError: Certificate issuance failed (CA_UNREACHABLE)
>>
>> ipa : DEBUG [error] RuntimeError: Certificate issuance
>> failed (CA_UNREACHABLE)
>> [error] RuntimeError: Certificate issuance failed (CA_UNREACHABLE)
>> -- end
>> Is this about local replica candidate or remote ipa server?
> getcert list may provide the host it was trying to contact.
>
> rob
When replica candidate installation fails I get the above on that
candidate.
When after a failure, on that would-be replica I do:
$ getcert list
Number of certificates and requests being tracked: 1.
Request ID '20180111154743':
status: CA_UNREACHABLE
ca-error: Server at
It points at itself, own FQDN.
Should I be rather watching server's end?
How to troubleshoot it?
thanks,L.
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
Hi,
certmonger tries first to connect to the IPA server defined
/etc/ipa/default.conf, but if this one fails then it will try to locate
another IPA master (see the man page for ipa-submit(8), especially the
section about -h option).
During a replica installation, certmonger will send a cert_request call
to the IPA master. You should be able to find a trace in
/var/log/httpd/error_log on the master, with a line containing the
string cert_request and the call parameters.
In turn, IPA master contacts Dogtag in order to generate the certificate
for the replica. The logs are in /var/log/pki/pi-tomcat/ca/debug.
Can you see any cert_request log in the master? If not, then certmonger
(from the would-be replica) was not able to contact the master. In this
case I would check the output of:
$ dig -t srv _ldap._tcp.<ipa domain>
to make sure which servers certmonger tried to contact.
HTH,
Flo