<div dir="ltr"><div class="gmail_quote">On Sun, Jan 12, 2014 at 11:01 PM, Dmitri Pal <span dir="ltr"><<a href="mailto:dpal@redhat.com" target="_blank">dpal@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div text="#000000" bgcolor="#FFFFFF"><div><div class="h5">
On 01/11/2014 09:20 AM, Charlie Derwent wrote:
</div></div><blockquote type="cite"><div><div class="h5">
<div dir="ltr">
<div>Hi </div>
<div><br>
</div>
<div>I'm experiencing an issue trying to use ipa-getcert on my
IPA clients. </div>
<div><br>
</div>
<div>When I run a command similar to this</div>
<div><font face="courier new,monospace">ipa-getcert request -K
principal/`hostname` -D `hostname` \</font>
<div>
<font face="courier new,monospace"><code> </code><code>-k
/var/lib/ssl/private_keys/`hostname`.pem \</code></font></div>
<div><font face="courier new,monospace"><code> </code><code>-f
/var/lib/ssl/certs/`hostname`.pem</code></font></div>
</div>
<div><br>
</div>
<div>Sometimes it will work, but 9 times out of 10 an
"ipa-getcert list" will show the request failed with a status
of CA_UNREACHABLE. I'm fairly certain it's not a time
related issue as I tend to run the command just after
enrolment and our NTP servers are rock solid. </div>
<div><br>
</div>
<div>Now please correct me if I'm wrong (because it feels like I
am wrong) but I think this is happening because not all of my
replicas are Certificate Authorities but the clients are
still trying to validate their certificate signing
requests with them. </div>
<div><br>
</div>
<div>Am I mistaken? Have I misconfigured something? If my theory
is correct is there a way to force the client to only talk to
the replica(s) running the CA service for these types
of tasks?</div>
<div><br>
</div>
<div>Anyway to try and get round the issue I decided to try and
make all my IPA replicas Certificate Authorities and ran into
the issue linked below</div>
<div><br>
</div>
<div><font color="#000000"><span>Bug
905064 - <span>ipa
install error Unable to find preop.pin</span></span></font></div>
<div><a href="https://bugzilla.redhat.com/show_bug.cgi?id=905064" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=905064</a></div>
<div><br>
</div>
<div>This has stopped me from rolling out the CA functionality
across all of my replicas (and I almost trashed a replica in
the process of trying to work around it). </div>
<div><br>
</div>
<div>I'm not really bothered which way I go about solving the
problem but would really appreciate some assistance as it
feels like I'm stuck between a rock and a hard place.</div>
<div><br>
</div>
<div>
Thanks,</div>
<div>Charlie</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>_______________________________________________
Freeipa-users mailing list
<a href="mailto:Freeipa-users@redhat.com" target="_blank">Freeipa-users@redhat.com</a>
<a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a></pre>
</blockquote>
<br>
Even if the replica does not have CA it has code to turn around and
proxy request to the corresponding replica that has CA.<br>
The first thing to check is the logs on the certmonger side that
does the certificate request to see which replica it is trying to
connect and httpd logs from the replica it tries to hit. If the
requests do not hit (which I suspect the case since the client
returned CA_UNREACHABLE) then it might be a firewall issue between
the client and the replica. If it hits the server but server fails
to proxy and returns CA_UNREACHABLE to the client then it is
probably a FW issue between replicas.<br>
<br>
At least this is where I would dig.<br>
<br>
Also the bug you mentioned is a race condition and seems like a rare
one so there is a chance it would not happen all the time if you try
more than once or may be choose a different system.<br>
Do you hit every time you try?<span><font color="#888888"><br>
<br>
<pre cols="72">--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
<a href="http://www.redhat.com/carveoutcosts/" target="_blank">www.redhat.com/carveoutcosts/</a>
</pre>
</font></span></div>
<br>_______________________________________________<br>
Freeipa-users mailing list<br>
<a href="mailto:Freeipa-users@redhat.com">Freeipa-users@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a><br></blockquote><div><br></div><div>Thanks for the tips regarding the CA authorization chain I'll try to take a closer log at the logs now I know what I'm looking for. </div>
<div><br></div><div>Regarding the replica CA setup, once the installation failed the first time I didn't get another chance. No matter what I did the replica was convinced there was another CA already installed. I even resorted to uninstalling the replica completely by running "ipa-setup-install --uninstall" a few times consecutively to make sure everything was gone but whenever I tried to re-install adding the --setup-ca option it didn't work. </div>
<div><br></div><div>I assumed there was a file or a service I had to stop or remove to get it going again so when I found this bug here <a href="https://bugzilla.redhat.com/show_bug.cgi?id=953488"><font color="#0066cc">https://bugzilla.redhat.com/show_bug.cgi?id=953488</font></a> I followed Tomas' steps in comment 4, not all the paths were the same (differences between IPA 3.0.0 and 3.2.0 I assume) but still no success. </div>
<div><br></div><div>In the end dropping the --setup-ca option and reinstalling got me back to where I had left off. </div></div><p>Was there a file/service I missed? I appreciate the help.</p><div>Thanks</div><div>Charlie</div>
<div class="gmail_extra"><br></div></div>