[Freeipa-users] Certificate system unavailable

[Rob Crittenden]

Sigbjorn Lie wrote:
>
>
>
> On Mon, February 17, 2014 16:34, Rob Crittenden wrote:
>> Sigbjorn Lie wrote:
>>
>>>
>>>
>>>
>>> On Fri, February 14, 2014 17:18, Rob Crittenden wrote:
>>>
>>>> Sigbjorn Lie wrote:
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, February 14, 2014 15:29, Rob Crittenden wrote:
>>>>>
>>>>>
>>>>>> Sigbjorn Lie wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> It would seem like we're still encountering some issues. The date has now passed for
>>>>>>> when the old certificate expired, and the "ipa" cli command no longer works. The webui
>>>>>>> is still working just fine.
>>>>>>>
>>>>>>> These are the errors I receive.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> $ ipa user-find
>>>>>>> ipa: ERROR: cert validation failed for "CN=serveripa03.example.com,O=EXAMPLE.COM"
>>>>>>> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted
>>>>>>> by the user.) ipa: ERROR: cert validation failed for
>>>>>>> "CN=serveripa01.example.com,O=EXAMPLE.COM"
>>>>>>> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted
>>>>>>> by the user.) ipa: ERROR: cert validation failed for
>>>>>>> "CN=serveripa02.example.com,O=EXAMPLE.COM"
>>>>>>> ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted
>>>>>>> by the user.) ipa: ERROR: cannot connect to Gettext('any of the configured servers',
>>>>>>> domain='ipa', localedir=None): https://serveripa03.example.com/ipa/xml,
>>>>>>> https://serveripa01.example.com/ipa/xml,
>>>>>>> https://serveripa02.example.com/ipa/xml
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> This seems more like a client-side issue. Can you confirm that
>>>>>> /etc/ipa/ca.crt is correct and that the NSS database in /etc/pki/nssdb
>>>>>> contains the CA?
>>>>>>
>>>>>> certutil -L -d /etc/pki/nssdb -n 'IPA CA'
>>>>>>
>>>>>
>>>>>
>>>>> The CA seem to be available. I ran the command on ipa01. See below for the output.
>>>>>
>>>>>
>>>>>
>>>>> The issue happens when I'm logged on to any of the ipa servers, and if I'm running the ipa
>>>>> command from a remote machine.
>>>>>
>>>>>
>>>>> ]$ sudo certutil -L -d /etc/pki/nssdb -n 'IPA CA'
>>>>> Certificate:
>>>>> Data:
>>>>> Version: 3 (0x2)
>>>>> Serial Number: 1 (0x1)
>>>>> Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
>>>>> Issuer: "CN=Certificate Authority,O=EXAMPLE.COM"
>>>>> Validity:
>>>>> Not Before: Thu Jan 19 19:44:21 2012
>>>>> Not After : Sun Jan 19 19:44:21 2020
>>>>> Subject: "CN=Certificate Authority,O=EXAMPLE.COM"
>>>>> Subject Public Key Info:
>>>>> Public Key Algorithm: PKCS #1 RSA Encryption
>>>>> RSA Public Key:
>>>>> Modulus:
>>>>>
>>>>>
>>>>
>>>> Perhaps we can brute force things to see what is going on. We can pass
>>>> some extra options to the ipa tool to get ultra verbose output:
>>>>
>>>> $ ipa -vv -e debug=True user-show admin
>>>>
>>>>
>>>>
>>>> The thing to do is to check the server that it is communicating with and
>>>> check /var/log/httpd/errors to see if there is an equivalent error logged there.
>>>>
>>>
>>> I've sent you the full output in private.  Could this be the reason for why it fails?
>>>
>>>
>>> ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False
>>>
>>>
>>> Name:     Certificate Key Usage
>>> Critical: True
>>> Usages:
>>> Digital Signature
>>> Non-Repudiation
>>> Key Encipherment
>>> Data Encipherment
>>>
>>>
>>
>> No, that is normal for a server cert.
>>
>>
>> This pretty clearly looks like an SSL trust issue. Is this happening on
>> every client machine you run the ipa tool or just one?
>>
>> You might want to compare the cert in /etc/pki/nssdb with the one on the
>> Apache server.
>>
>>
>> # certutil -L -d /etc/httpd/alias -n 'EXAMPLE.COM IPA CA'
>>
>>
>> # certutil -L -d /etc/pki/nssdb -n 'IPA CA'
>>
>
> Looks like the same certificate, just with different flags?
>
> $ sudo  certutil -L -d /etc/httpd/alias -n 'EXAMPLE.COM IPA CA' > /tmp/ca1
> $ sudo certutil -L -d /etc/pki/nssdb -n 'IPA CA' > /tmp/ca2
> $ diff /tmp/ca1 /tmp/ca2
> 90a91,92
>>              Valid CA
>>              Trusted CA

A diff with context would confirm it but I'm assuming this is just the 
code-signing trust which won't affect anything in this case. You'll 
notice that some trust is CT,C,C and some just CT,C,. The order is SSL, 
S/MIME, code signing.

On what machine are you trying to use the ipa tool? Is it one of the 
masters, all of them, enrolled clients?

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?

NSS is smart enough to handle multiple certificates, it should pick the 
newest one on startup.

rob