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? -- John _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users