[Freeipa-users] Failure decoding Certificate Signing Request

[Rob Crittenden]

Thomson, Ryan wrote:
>> -----Original Message-----
>> From: Rob Crittenden [mailto:rcritten at redhat.com]
>> Sent: Thursday, October 24, 2013 11:41 AM
>> To: Thomson, Ryan; freeipa-users at redhat.com
>> Subject: Re: [Freeipa-users] Failure decoding Certificate Signing Request
>>
>> Thomson, Ryan wrote:
>>>> -----Original Message-----
>>>> From: Rob Crittenden [mailto:rcritten at redhat.com]
>>>> Sent: Wednesday, October 23, 2013 6:58 PM
>>>> To: Thomson, Ryan; freeipa-users at redhat.com
>>>> Subject: Re: [Freeipa-users] Failure decoding Certificate Signing
>>>> Request
>>>>
>>>> I think this still points to NSS not being initialized. The way we
>>>> currently use NSS in the server is Apache fires things up using
>>>> mod_nss, then because we are a child of Apache via mod_wsgi, we
>>>> inherit the open NSS database in /etc/httpd/alias. This gives us the
>>>> CA cert and the client cert we need in order to talk to dogtag.
>>>>
>>>> What I thought, and the excellent debugging above confirms, is that
>>>> at some point the NSS database is being shut down. At some point we
>>>> need to do some crypto and try to initialize it ourselves to no
>>>> avail. We shouldn't ever need to do it in the server and thus don't
>>>> have access to PINs and such because we don't need them. We do
>>>> initialize things from time to time on the client side but we tend to
>>>> do a database-less initialization (nss_init_nodb()).
>>>>
>>>> I'm not really sure what this tells us though. It would appear that
>>>> SSL is working in Apache, because you are able to get far enough to
>>>> make a request and have it fail. So the NSS database is still
>>>> initialized in Apache, but for some reason the wsgi code doesn't seem to
>> agree.
>>>>
>>>> Would it be possible for you to stop and restart Apache and run some
>>>> simple IPA command like ipa user-show admin (and let me know if it
>> succeeds)?
>>>> Then send me the error_log?
>>>>
>>>> If you are in SELinux enforcing mode it would also be helpful to
>>>> check for any AVCs. Maybe we simply can't access the database.
>>>>
>>>> thanks
>>>>
>>>> rob
>>>
>>> I am able to stop/wait/start apache and then execute "ipa user-show
>> admin" successfully.
>>>
>>
>> Ok, let's try a couple more things.
>>
>> Can you set LogLevel debug in /etc/httpd/conf.d/nss.conf and restart
>> Apache again? This may give us more information on what mod_nss is doing.
>>
>> Next, lets try a different cert command that should also invoke the NSS client
>> within IPA:
>>
>> $ ipa cert-show 22
>>
>> Can you describe your environment? Do you have multiple IPA masters? Was
>> this a new install at 3.0 or is it an upgrade from 2.2?
>>
>> rob
>
> The environment is simple: Single master, upgraded from 2.2.
>
> Output in /var/log/httpd/error_log after setting LogLevel to debug in /etc/httpd/conf.d/nss.conf and restarting apache:

[ snip ]

>
> I'm not sure what to make of this.

This is just more confirmation that the IPA framework is trying to 
initialize NSS for some reason. It should never do this which is why it 
is failing so spectacularly.

Can you provide nss.conf and ipa.conf from /etc/httpd/conf.d?

Who owns and what are the permissions of /etc/httpd/alias/*.db?

thanks

rob