I go on with my investigation, and I find that error -8172 should be related to the fact that the root certificate is self-signed, even if it's in the trust store contained in Root Certs module. Indeed, I search through the reference SEC_ERROR_UNTRUSTED_ISSUER, and I find this error seems to be set only in this function <http://mxr.mozilla.org/nss/source/lib/certhigh/certvfy.c#404> in two cases:
1. The issuer cert is explicitly distrusted (code <http://mxr.mozilla.org/nss/source/lib/certhigh/certvfy.c#710>). However, CERTDB_TERMINAL_RECORD is never set in the certificates I parse; 2. The issuer cert is self-signed (code <http://mxr.mozilla.org/nss/source/lib/certhigh/certvfy.c#750>), as it can be seen by the comment. The root certificate of the Apple chain is self-signed, so I'm afraid that this is the check which fails. It seems pretty weird since usually root certificates are self-signed. Another test I perform seems to confirm that error -8172 is relative to the root certificate. Indeed, if I pass as a chain the server certificate and an intermediate CA certificate, without loading Root Certs module, I get error -8179, issuer not found. However, with the same input but with the module loaded, the error turns into -8172. Hence, either the aforementioned checks are done after the chain has been built, or the the error is raised when the root cert found in the module is being added to the built chain. Thank You, Nicholas 2016-02-09 18:24 GMT+01:00 Nicholas Mainardi <[email protected]>: > 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 <[email protected]>: > >> Anyone up for a possible solution? >> >> 2016-02-06 14:51 GMT+01:00 Nicholas Mainardi <[email protected]> >> : >> >>> 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 <[email protected]>: >>> >>>> 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 <[email protected]>: >>>>> >>>>> 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 >>>>>> [email protected] >>>>>> https://lists.mozilla.org/listinfo/dev-tech-crypto >>>>>> >>>>>> >>>> -- >>>> dev-tech-crypto mailing list >>>> [email protected] >>>> https://lists.mozilla.org/listinfo/dev-tech-crypto >>>> >>> >>> >> > -- dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
