On Wed, February 19, 2014 13:45, Sigbjorn Lie wrote:
>

>
> 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?
>
>

*ping* :)


Regards,
Siggi


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

Reply via email to