Please, could someone give me a hint about this issue? Deadline for my testing program is getting closer and I need to get it works. Otherwise I should use the Cert_VerifyCertNow function even if it's deprecated. I would like to add that I try to call also CERT_VerifyCertNow on the same input chain used in PKIXVerifyCert, and it's properly working. It should mean that the root self-signed certificate should be marked as trusted my softoken DB.
Thank You, Nicholas 2016-02-11 1:42 GMT+01:00 Nicholas Mainardi <mainardinicho...@gmail.com>: > 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
