I found out that error -8172 is issued because of a cert duplicate found. Probably the self-signed root certificate is added twice to the trust chain because the building algorithm doesn't stop when it's found the first time, maybe because it's not considered a trust anchor. I recall that I check in DB of libnsspcki.so and the trust flags are C,C,C. Hence, which flags are needed in order to be considered trusted?
Thank You, Nicholas 2016-02-15 23:41 GMT+01:00 Nicholas Mainardi <[email protected]>: > 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 <[email protected]>: > >> 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" <[email protected]> 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 < >>>> [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 >>> >> > -- dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
