Thomson, Ryan wrote:
-----Original Message-----
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Thursday, October 24, 2013 11:41 AM
To: Thomson, Ryan; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Failure decoding Certificate Signing Request
Thomson, Ryan wrote:
-----Original Message-----
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Wednesday, October 23, 2013 6:58 PM
To: Thomson, Ryan; freeipa-users@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
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
