On Sun, Jan 12, 2014 at 11:01 PM, Dmitri Pal <d...@redhat.com> wrote:
> On 01/11/2014 09:20 AM, Charlie Derwent wrote:
> I'm experiencing an issue trying to use ipa-getcert on my IPA clients.
> When I run a command similar to this
> ipa-getcert request -K principal/`hostname` -D `hostname` \
> -k /var/lib/ssl/private_keys/`hostname`.pem \
> -f /var/lib/ssl/certs/`hostname`.pem
> 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.
> 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.
> 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?
> 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
> Bug 905064 - ipa install error Unable to find preop.pin
> 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).
> 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.
> Freeipa-users mailing
> Even if the replica does not have CA it has code to turn around and proxy
> request to the corresponding replica that has CA.
> 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.
> At least this is where I would dig.
> 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.
> Do you hit every time you try?
> Thank you,
> Dmitri Pal
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
> Looking to carve out IT costs?www.redhat.com/carveoutcosts/
> Freeipa-users mailing list
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.
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.
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
https://bugzilla.redhat.com/show_bug.cgi?id=953488 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.
In the end dropping the --setup-ca option and reinstalling got me back to
where I had left off.
Was there a file/service I missed? I appreciate the help.
Freeipa-users mailing list