On Tue, February 18, 2014 20:45, Rob Crittenden wrote:
> Sigbjorn Lie wrote:
>
>>> On what machine are you trying to use the ipa tool? Is it one of the
>>> masters, all of them, enrolled clients?
>>>
>>
>> It's the same error message when the "ipa" command is run directly on any of 
>> the masters.
>>
>>
>> And it's the same error message if I run the "ipa" command on any of the 
>> clients.
>>
>>
>> I do not have a working "ipa" command anywhere anymore.
>>
>
> Ok, let's test out the cert that ipa is using. Try this on any one of
> the masters:
>
> $ curl https://`hostname`/ipa/xml
> Should fail with Peer certificate cannot be authenticated with known CA
> certificates

Yes, this did not work:

curl: (60) Peer certificate cannot be authenticated with known CA certificates
More details here: http://curl.haxx.se/docs/sslcerts.html


>
> $ curl --cacert /etc/ipa/ca.crt https://`hostname`/ipa/xml
> Should succeed in that you get the "you are not logged in" HTML page
>

Indeed - this works.

>
> Ok, now unfortunately curl only handles the sql-style NSS databases so
> we can't fully reproduce it the same way that the IPA client is doing things, 
> but here is an
> approximation:
>
>
> # certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i
> /etc/ipa/ca.crt
> $ curl https://`hostname`/ipa/xml
> You should see the login page HTML
>

Yes, I can now see the login page HTML.


>
> If you stick a -v in there it'll give you more verbose output which
> would be useful if any of these fail in an unexpected way.
>
>>> Whatever is going on isn't likely related to the web server Apache
>>> database as you get the same error out of each one. The client log you sent 
>>> confirmed that it
>>> tried to contact each master. The SSL error we're getting is that the 
>>> client doesn't trust the
>>> CA that
>>> signed the server certificate so this appears to be a problem on the 
>>> client, which begs the
>>> question: all clients or just this one?
>>>
>>>
>>
>> All clients.
>>
>>
>>
>>>
>>> NSS is smart enough to handle multiple certificates, it should pick the
>>> newest one on startup.
>>>
>>
>> Ok.
>>
>>
>> Where do you suggest I continue troubleshooting this issue?
>>
>
> We can also tackle this on the server side. Let's verify the server cert:
>
>
> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias
>
This produces the same output for all 3 servers:

certutil: certificate is valid

>
> This is verified on server startup so I expect it to be valid, but
> doesn't hurt to try.
>
> Restarting the Apache process might be something to try as changes to
> the NSS database aren't picked up until a restart.
>

I ran "# certutil -A -d sql:/etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i 
/etc/ipa/ca.crt" on ipa03,
and restarted httpd.

The "ipa" command is now *working* on ipa03. :)

However it's *not working* a client who's /etc/ipa/default.conf points at ipa03.

Do I have to refresh the PKI CA in /etc/pki/nssdb on every client?


Regards,
Siggi






_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to