I'm quite sure that the certificate should be trusted. I forgot to write it, but i actually found it using certutil in the CERT DB provided by "roots cert" module:
certutil -L -d DB_dir -h all | grep 'root_cn' Returns the certificate with trusted flags C,C,C. So i think it means it's already trusted (i don't find stronger flags to set). Hence i cannot figure out why i'm getting an untrusted issuer error, since the certificate should be trusted. The DB loaded from root certs module should be the Mozilla's CA root certificates, so it should be secure relying on these certificates. Thank you, Nicholas Il 11/feb/2016 01:31, "Julien Pierre" <julien.pie...@oracle.com> ha scritto: > Nicholas, > > Your root certificate needs to be trusted. Self-signed is fine, but you > still need to trust it. > > It would either need to be present in your cert DB, with the proper trust > flag, or you would need to dynamically set the trust on that root > certificate using the API . > You can use CERT_ChangeCertTrust or CERT_ChangeCertTrustByUsage to do so. > > Your root CA needs to be trusted prior to attempting any chain > build/verification, otherwise your verification will always fail. > If you have no trusted CAs, then all verifications will always fail. > > The same will be true whether you are using the legacy chain verification > code in NSS, or libpkix. > > Julien > > On 2/10/2016 05:26, Nicholas Mainardi wrote: > >> 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 <mainardinicho...@gmail.com >> >: >> >> 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 > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
