Is there a tool in NSS to validate a website certificate set?

[Jonathan Wilson]

OpenSSL has a s_client command that allows you to pull the certificates a 
web page sends and verify the chain of trust against whatever root CA store 
OpenSSL is using. Is there a way to do something similar for NSS? i.e. pull 
the certificates a web page sends and validate them against the current set 
of Mozilla root certificates?


And if there is, where do I get it from and how do I compile it? (if its 
one of the standard utilities in NSS, how do I compile those?)

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [NSS] X509 Certificate Chain Verification Example

[Julien Pierre]

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
 in two cases:

1. The issuer cert is explicitly distrusted (code
). However,
CERTDB_TERMINAL_RECORD is never set in the certificates I parse;
2. The issuer cert is self-signed (code
), 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 :


About error -8101 with Facebook CA certificate, I found it should be
related with this bug
, 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
 
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 :


Anyone up for a possible solution?

2016-02-06 14:51 GMT+01:00 Nicholas Mainardi 
:


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 :


Nicholas,

It looks like

cert_pi_certList

is indeed never processed. So 

Re: [NSS] X509 Certificate Chain Verification Example

[Julien Pierre]

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
 in two 
cases:


1. The issuer cert is explicitly distrusted (code
). 
However,

CERTDB_TERMINAL_RECORD is never set in the certificates I parse;
2. The issuer cert is self-signed (code
), 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 
:



About error -8101 with Facebook CA certificate, I found it should be
related with this bug
, 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
 
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 
:



Anyone up for a possible solution?

2016-02-06 14:51 GMT+01:00 Nicholas Mainardi 


:


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 

Re: [NSS] X509 Certificate Chain Verification Example

[Nicholas Mainardi]

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"  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
>>  in two
>> cases:
>>
>> 1. The issuer cert is explicitly distrusted (code
>> ). However,
>> CERTDB_TERMINAL_RECORD is never set in the certificates I parse;
>> 2. The issuer cert is self-signed (code
>> ), 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 > >:
>>
>> About error -8101 with Facebook CA certificate, I found it should be
>>> related with this bug
>>> , 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 >> >:
>>>
>>> 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,