> This is incorrect. To validate a certificate you only need the CA public
> keys, not the private ones. Only having the ipa-ca-agent key is right.
> This is a temporary database, not the CA database. We are using this
> cert to request some information about itself from the CA in this case.
Yo
On Wed, Nov 13, 2013 at 08:19:18PM +0100, Nicklas Björk wrote:
> On 2013-11-13 20:00, Simo Sorce wrote:
> > On Tue, 2013-11-12 at 21:50 +0100, Nicklas Björk wrote:
> >> On 2013-11-12 21:39, Simo Sorce wrote:
> >>> On Tue, 2013-11-12 at 21:11 +0100, Nicklas Björk wrote:
> In our evironment we h
Dear freeipa-users,
We are diving deeper in RHEL IdM and facing with new issues.
Several days ago we started to learn ACI following the advices of Martin Kosek
and Rob Crittenden. The attached Python script with variables stored in
"admins" file reconstruct the customized configuration of the AC
Thanks for the fast reply and great support.
The usage of 'entry_cache_sudo_timeout' parameter does the trick.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Andrea Bontempi wrote:
This is incorrect. To validate a certificate you only need the CA public
keys, not the private ones. Only having the ipa-ca-agent key is right.
This is a temporary database, not the CA database. We are using this
cert to request some information about itself from the CA in
On 11/14/2013 03:29 AM, Andrea Bontempi wrote:
> I did some tests: The error occurs when I use a CA managed by EJBCA,
> if I use a CA generated by openssl or nss everything works properly.
>
> The problem is that i can't reproduce the bug in an external nss
> db... but maybe I don't follow the sam
On 11/14/2013 08:56 AM, Rob Crittenden wrote:
> Andrea Bontempi wrote:
>>> This is incorrect. To validate a certificate you only need the CA public
>>> keys, not the private ones. Only having the ipa-ca-agent key is right.
>>> This is a temporary database, not the CA database. We are using this
>>>
> The issue is one is encoded as a UTF8 string and the other is
> encoded as a printable string. This makes the binary derSubject and
> derIssuer fields different. NSS does not like derSubject and derIssuer
> fields that are different
Wow, that was the problem! Now it works!
To fix must go to EJB
