307144 - Inconsistent verification behavior with Thawte Personal Freemail Issuing CA

Status: RESOLVED WORKSFORME

(Core :: Security: PSM, defect, P1)

Description

[Simon Fraser [no longer active]]

I'm seeing issues with the trust settings for the Thawte Personal Freemail
Issuing CA certificate, but I'm not sure if this reflects a limitation in the
Firefox UI, or a bug in NSS.

I obtained a free Thawte Freemail Member cert which is reported (in the FF UI)
to be valid for email signing. It is signed by the "Thawte Personal Freemail
Issuing CA", which I've trused for email signing. However, when viewing this
certificate, FF reports that it "could not be verified because the issuer is not
trusted." The issuer is the Thawte Personal Freemail CA, which is also trusted
for email signing, and is reported to be valid as an email signer and recipient.

So why is FF telling me that the intermediate CA cert has an untrusted issuer?
If I look at that cert in more detail, it has a "Key Usage" extension with a
usage of 0x06 (KU_KEY_CERT_SIGN | KU_CRL_SIGN).

I'm calling nsIX509Cert::GetUsagesArray() to check the cert, which calls via
nsUsageArrayHelper::GetUsagesArray() into CERT_KeyUsageAndTypeForCertUsage()
with 'ca' set to PR_FALSE. This requires that email signing certs have a key
usage of KU_DIGITAL_SIGNATURE (c.f. the ca==PR_TRUE code path, which sets
requiredKeyUsage to KU_KEY_CERT_SIGN). They cert's key usage does not match
KU_DIGITAL_SIGNATURE, so a SEC_ERROR_INADEQUATE_KEY_USAGE error is returned
(though this gets later masked by SEC_ERROR_UNTRUSTED_ISSUER errors).

So, I'm not sure who's at fault here, but it's odd that the leaf cert is
reported as verified for email signing, even when its issuer is unverified.

Comment 1

[Wan-Teh Chang]

This bug is either a duplicate of or related to bug 289988.

I found that if I trust the root CA "Thawte Personal Freemail CA"
with "This certificate can identify web sites", then the intermediate
CA "Thawte personal Freemail Issuing CA" will be shown as "This
certificate has been verified for the following uses:
SSL Certificate Authority".  So it seems that there is some
interaction between the root CA's trust settings and key usages.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

(In reply to comment #0)

> I obtained a free Thawte Freemail Member cert which is reported (in the FF UI)
> to be valid for email signing. It is signed by the "Thawte Personal Freemail
> Issuing CA", which I've trused for email signing. However, when viewing this
> certificate, FF reports that it "could not be verified because the issuer is 
> not trusted." 

I gather that "this certificate" is the/an intermediate CA.
Please describe the exact steps that you follow to reproduce this error message.

There is an ancient PSM bug (much older than bug 289988, dating back to before
2004) which I am unable to find today that reports a similar complaint.  The
problem, IIRC, is that there was a button that offered to "verify" a cert, 
but made no mention of the purpose for which the cert would be verified.  
So, regardless of the purpose for which the user wants it (e.g. SSL client 
auth, or S/MIME) and regardless of whether it is a CA cert or an end-entity 
cert, the button always verified it for the same purpose (which I do not recall,
but was probably SSL client auth end-entity).  I'll guess that the method 
used for that old button is now invoked by FF's cert manager upon viewing
a cert.  

> The issuer is the Thawte Personal Freemail CA, which is also trusted
> for email signing, and is reported to be valid as an email signer and 
> recipient.

> So why is FF telling me that the intermediate CA cert has an untrusted issuer?

Perhaps that's because it's being asked the wrong question.

> If I look at that cert in more detail, it has a "Key Usage" extension with a
> usage of 0x06 (KU_KEY_CERT_SIGN | KU_CRL_SIGN).

That tells you it's a CA (only) cert.  

> I'm calling nsIX509Cert::GetUsagesArray() to check the cert, which calls via
> nsUsageArrayHelper::GetUsagesArray() into CERT_KeyUsageAndTypeForCertUsage()
> with 'ca' set to PR_FALSE. 

So, you're asking "is this a valid end-entity (EE, non-CA) cert?" and 
you're getting back a negative response, because it's a CA cert.  Perhaps
more accurately, you're asking "for what usages is this a valid EE cert?"
and the answer is: none, because it's not an EE cert.  I think you'd get
a rather different answer if you called it with 'ca' set to true.

> This requires that email signing certs have a key
> usage of KU_DIGITAL_SIGNATURE (c.f. the ca==PR_TRUE code path, which sets
> requiredKeyUsage to KU_KEY_CERT_SIGN). They cert's key usage does not match
> KU_DIGITAL_SIGNATURE, so a SEC_ERROR_INADEQUATE_KEY_USAGE error is returned

Sounds right, down to this point.  You asked if it's a valid EE cert, and got
a correct negative answer.

> (though this gets later masked by SEC_ERROR_UNTRUSTED_ISSUER errors).

That seems wrong, but may be another consequence of the fact that you asked
if it was an EE cert.  That may have confused the error logic into thinking
that this CA cert is actually an issuer of the leaf cert with which the 
inquiry started, and not the leaf cert itself. (that's speculation)

> So, I'm not sure who's at fault here, but it's odd that the leaf cert is
> reported as verified for email signing, even when its issuer is unverified.

I hypothesize that the EE cert was verified properly, producing the expected
answer, and the attempt to verify the intermediate CA cert wasn't, resulting 
in an unexpected answer.  GIGO.

Comment 3

[Simon Fraser [no longer active]]

(In reply to comment #2)

> There is an ancient PSM bug (much older than bug 289988, dating back to before
> 2004) which I am unable to find today that reports a similar complaint.  The
> problem, IIRC, is that there was a button that offered to "verify" a cert, 
> but made no mention of the purpose for which the cert would be verified.  
> So, regardless of the purpose for which the user wants it (e.g. SSL client 
> auth, or S/MIME) and regardless of whether it is a CA cert or an end-entity 
> cert, the button always verified it for the same purpose (which I do not recall,
> but was probably SSL client auth end-entity).  I'll guess that the method 
> used for that old button is now invoked by FF's cert manager upon viewing
> a cert.  

The method that FF is using to get the verified status of the cert is
nsNSSCertificate::GetUsagesArray(). This method runs through the various
purposes, verifying for each one -- code here:

http://lxr.mozilla.org/mozilla/source/security/manager/ssl/src/nsUsageArrayHelper.cpp#177

and it returns a "verified OK" status if the cert is verified for at least one
usage. The problem seems to be that we're not propagating down whether the cert
is being used as a CA or not, and CERT_VerifyCert() is assuming it's not a CA
for certain usages (including the certUsageEmailSigner/certUsageEmailRecipient
which is what this cert is used for). Maybe this is why CERT_VerifyCert() is
marked as "obsolete, don't use in new code"?

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

The comment about CERT_VerifyCert being obsolete is wrong, IMO.
There is a newer function named CERT_VerifyCertificate, but it does not 
obsolete CERT_VerifyCert, AFAIK.  The newer function merely allows a caller 
to check for multiple usages in a single call.

The usage argument tells those functions what set of properties the cert
chain must have to be valid. For most usages, it is common that the leaf
(EE) cert will have one set of requirements, and its issuer certs will have
another somewhat different set of requirements.  A usage of certUsageEmailSigner
or certUsageEmailRecipient (implying decryptor) requires the leaf (the first 
cert passed in) to have certain properties, and its issuer CAs to have a 
second set of properties.  CERT_VerifyCert(ificate) assumes that the first
cert passed in is a leaf (EE) cert, and tests it for the usages appropriate
for an EE cert for the indicated usage, then tests the rest of the chain
for the CA requirements for that usage.

You're passing in a CA cert, and you want to ask "is this CA cert (and its
chain) valid to be an *issuer* of EE (or other CA) certs for the usage 
certUsageEmailSigner?"  There is a separate function intended for that 
purpose.  Call CERT_VerifyCACertForUsage instead of CERT_VerifyCert.  
CERT_VerifyCACertForUsage is intended to answer the question you want to 
ask, given the inputs you've been providing.  

However, I see that CERT_VerifyCACertForUsage is not presently used or tested 
by any of our NSS QA tools, so I'm not highly confident in it.  But it's 
worth a try, and it is officially supported, so if it's broken, we'll fix it.  
IMO, this is the "right" way to ask the question you want to ask.

Comment 5

[Simon Fraser [no longer active]]

Unforunately CERT_VerifyCACertForUsage() isn't exposed in any of the XPCOM
interfaces, nor even called by the PSM C++ code.

Comment 6

[timeless]

all of that code was changed by bug 149834, see http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/manager/ssl/src/nsUsageArrayHelper.cpp&rev=1.6

are things still unhappy?

(i'm searching for a psm bug, but searching for psm bugs in the psm bug piled is searching for hay in a haystack)

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Timeless, yes, I'd say this bug is still unhappy.  :)

I'd summarize this bug this way: 

Cert manager verifies certs for use a "End Entity" (EE) certs (formerly called  "leaf" certs) for various usages (e.g. SSL, SMIME), not for use as CA certs.  

This bug wants cert manager to notice when the cert being verified is a CA cert 
and verify it for validity as a CA cert, not as an EE cert.  

Comment 8

[Kai Engert [:KaiE:]]

reassign bug owner.
mass-update-kaie-20120918

Comment 9

[Dana Keeler (she/her) (use needinfo) [:keeler]]

From what I can tell, when viewing an intermediate in the certificate manager, the correct text is displayed for that intermediate's usages.