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
>>> cert to request some information about itself from the CA in this case.
>> You're right, I thought that the script use a temporary db to create the
>> final database, but it's only to connect with sslget.
>>> I think there is an issue with one of the CA certs but I've yet to
>>> duplicate it or identify what is wrong. I'm still waiting on word back
>>> from one of the NSS devs.
>> 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 same steps that uses the installation script.
> The problem has to do with the encoding of the subject and issuer fields.
> 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
Good information! But this sounds like a bug to me if NSS is comparing
binary data for equality, one should decode the binary encoding to
arrive at a canonical form and then compare the canonical form, right?
Freeipa-users mailing list