As an aside, I would strongly advise you to use the first method - put
the root CA in your cert DB, ahead of time, prior to starting your
applications.
Dynamically and blindly trusting a root CA, especially one received over
a network, is asking for trouble and a big security no-no.
You should never do so unless you have some other trusted proof that you
should do so - say, a signed message from a CA you already trust.
If you start your app without any trusted CA in your DB, you will not
have any real security.
Julien
On 2/10/2016 16:30, Julien Pierre wrote:
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
