About error -8101 with Facebook CA certificate, I found it should be related with this bug <https://bugzilla.mozilla.org/show_bug.cgi?id=1049176>, so it's a certificate issue. However, with Apple's certificate chain, I got error -8102 when I try to validate only the CA certificate, while error -8172 trying to validate the whole chain. It's likely I got the issue related to error -8102 by looking at the source code. After a while, I got to this <http://mxr.mozilla.org/security/source/security/nss/lib/certdb/certdb.c#1219> function. Here, the key Encipherment Usage is setted as mandatory for every certificate using RSA as pk algorithm. However, while this setting could make sense in end entity certificates (even if it's not correct because there is no mandatory constraint about it in RFC), it's quite silly with CA certificates. Of course RSA can be used to encrypt a key also by CA, but it's not that common, hence it's a really strong requirement. I have still to figure out where does error -8172 come from (I suppose that the issuer is untrusted because the CA certificate has -1802 error), and why I got invalid_args error by set as parameter of CERT_PKIXVerifyCert some usages. If someone can point me out why this happens, and confirm the possible issues I have found, it would save me a lot of time.
Thank You, Nicholas 2016-02-09 13:57 GMT+01:00 Nicholas Mainardi <mainardinicho...@gmail.com>: > Anyone up for a possible solution? > > 2016-02-06 14:51 GMT+01:00 Nicholas Mainardi <mainardinicho...@gmail.com>: > >> If I remove cert_pi_certList from the array, invalid_args error turns >> into untrusted_issuer error (-8172). So, it seems that even if I don't add >> the intermediate CA certificate in certList, the lookup in cert DB is fine, >> but it doesn't manage to validate the CA certificate. Indeed, if I give >> only the CA certificate as input, I got inadequate_cert_type error (-8101). >> Same result by removing also cert_pi_useAIACertFetch. I try to change the >> certificate usages parameter, but the error varies from invalid_args to >> inadeauqte_key_usage(-8102). >> >> I know that the certificate chain is correct, I have already used it as a >> testing input for other libraries, and I know I have a trust anchor for the >> CA certificate in my system root certificates. I think that the issue is >> the error inadequate_cert_type on the CA certificate, but I have no idea >> about what can cause this error. Moreover, I got invalid_args error even >> passing trustAnchors instead of cert_pi_certList. So, I suppose there are >> some issues with the processing made by Cert_PKIXVerifyCert function. >> >> Thank You, >> >> Nicholas >> >> 2016-02-06 2:42 GMT+01:00 Julien Pierre <julien.pie...@oracle.com>: >> >>> Nicholas, >>> >>> It looks like >>> >>> cert_pi_certList >>> >>> is indeed never processed. So that seems to be unimplemented. I'm not >>> quite sure why that is. It's been a long type since I worked on NSS/libpkix. >>> What happens if you remove that parameter from your list ? >>> >>> Once the certs are decoded, presumably in your parse_cert function, they >>> will be available in the NSS softoken as temp certs, and will be searchable >>> and findable by CERT_PKIXVerifyCert . >>> The chain building should rebuild the chain (or possibly another chain). >>> If you are using AIA fetch with cert_pi_useAIACertFetch, then presumably, >>> your chain is possibly incomplete. >>> Thus, you don't really want to use cert_pi_certList anyway, as that >>> would imply no more building. >>> >>> I think if you remove the cert_pi_certList, and if you have a trust >>> anchor in your softoken cert DB, then the rebuilding+validation should work. >>> >>> Julien >>> >>> On 2/5/2016 06:03, Nicholas Mainardi wrote: >>> >>>> Hello, >>>> >>>> Thank you for your reply. I looked for the function you mentioned and I >>>> looked at the usage examples. I edit <http://pastebin.com/4BQsinXM> my >>>> previous code to use the function, but I'm getting error invalid_args >>>> (-8187). After some trials, I figure out it's caused by the >>>> cert_pi_certList type in input parameter. Looking at how these >>>> parameters >>>> are processed, I got to this function >>>> < >>>> http://mxr.mozilla.org/security/source/security/nss/lib/certhigh/certvfypkix.c#1509 >>>> >, >>>> which contains a switch on the param type. However, it doesn't exist a >>>> case >>>> for every types listed here >>>> < >>>> http://mxr.mozilla.org/security/source/security/nss/lib/certdb/certt.h#898 >>>> >, >>>> >>>> and the default case raise invalid_args. Isn't this a bug of this >>>> function? >>>> >>>> However, I tried also with cert_pi_trustAnchors type (which has a case >>>> in >>>> the function), but I got the same error. And also if I change the >>>> certificate usage parameter, I got this error. So, is there something >>>> wrong >>>> in the code I have written? >>>> >>>> Thanks, >>>> >>>> Nicholas >>>> >>>> 2016-02-04 1:14 GMT+01:00 Julien Pierre <julien.pie...@oracle.com>: >>>> >>>> CERT_VerifyCertNow is a legacy API that does not support the full set of >>>>> RFC 3280/5280 features. >>>>> To support things like policy checks, you can use libpkix . >>>>> Look for CERT_PKIXVerifyCert . There are examples of usage in the NSS >>>>> test >>>>> programs vfychain and tstclnt . >>>>> The library supports many more options than may be tested, though. >>>>> >>>>> Julien >>>>> >>>>> On 2/3/2016 08:37, Nicholas Mainardi wrote: >>>>> >>>>> Hello, >>>>>> >>>>>> I'm comparing different libraries to verify X509 certificate chains. >>>>>> I had >>>>>> some issues to find how to use NSS to perform this task. At the end, I >>>>>> managed to get a working code with one certificate chain. You can >>>>>> find the >>>>>> code in this question >>>>>> < >>>>>> >>>>>> http://stackoverflow.com/questions/34982796/how-to-parse-and-validate-certificates-with-nss >>>>>> I asked on stack overflow. I would like to know if the code I wrote >>>>>> is the >>>>>> correct way to verify a certificate chain using NSS, and if there are >>>>>> other >>>>>> parameters to customize the verify algorithm which can be set (i.e. a >>>>>> flag >>>>>> to enable policy check etc.). If the code is correct, I suggest it >>>>>> could >>>>>> be >>>>>> added to NSS examples on the documentation. >>>>>> >>>>>> Thank You, >>>>>> >>>>>> Nicholas >>>>>> >>>>>> -- >>>>> dev-tech-crypto mailing list >>>>> dev-tech-crypto@lists.mozilla.org >>>>> https://lists.mozilla.org/listinfo/dev-tech-crypto >>>>> >>>>> >>> -- >>> dev-tech-crypto mailing list >>> dev-tech-crypto@lists.mozilla.org >>> https://lists.mozilla.org/listinfo/dev-tech-crypto >>> >> >> > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
