384719 - PSM's OCSP checks fail (NSS's work OK) with Startcom CA

Status: RESOLVED FIXED

(Core :: Security: PSM, defect)

Description

[Nelson Bolyard (seldom reads bugmail)]

Attachment: signed SMIME email message demonstrates behavior

This affects trunk builds dated 20070515 through today.
I received a signed email from Eddy Nigg of Startcom (the CA). 
If I view it with OCSP disabled, it appears to have a valid signature.

If I view it with OCSP enabled, but with the (new) preference that says 
"When an OCSP server connection fails, treat the certificate as invalid"
unchecked (the default condition), the signature appears valid.  

But If I view it with OCSP enabled, but with the (new) preference that says 
"When an OCSP server connection fails, treat the certificate as invalid"
checked, or if I view it in the slightly older SM 2.0a1 builds that didn't
have this new option, and always behaved as if it was checked, the signature
appears INVALID.  

Clicking on the broken pen icon brings up a dialog that says:
   Digital Signature Is Not Valid
   This message includes a digital signature, but the signature is invalid.
   The certificate used to sign the message was issued by a certificate 
   authority that you do not trust for issuing this kind of certificate.

That is utterly WRONG.  The problem is OCSP verification failure.

I wasted HOURS and HOURS trying to figure out why this CA was considered
untrusted before I realized that the error text was lying to me.  

So, then I tested the signature cert chain with NSS'c ocspclnt program.
The command I used was:
    ocspclnt -S [e-mail] -u E
It reported:
   Check of certificate "[e-mail]" succeeded.

So, this tells me that NSS's built-in OCSP client works OK with startcom's
OCSP server, but apparently PSM's OCSP client does not.  Therefore, I believe
this is a bug in PSM's OCSP client.

While trying to get to the bottom of the untrusted CA issue, I found another
problem that is a consequence of these OCSP failures.  When viewing Eddy's
cert in cert manager, or viewing the intermediate CA cert that issued Eddy's
cert in cert manager, cert manager told me, consistently, this:
  Could not verify this certificate for unknown reasons.

Unknown reasons?  I think not.  
I thought those "unknown reason" messages had been eliminated. 
Apparently not.

Comment 1

[Eddy Nigg (StartCom)]

Attachment: Wrong message

I found more inconsistent/wrong messages in current Thunderbird. This is an expired certificate, but the message is the same message that Nelson reported for OCSP failure. Obviously the CA is "trusted", only the certificate expired.

Comment 2

[Eddy Nigg (StartCom)]

Attachment: Wrong message

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Mr. OCSP, would you be willing to help diagnose this failure?

Comment 5

[Julien Pierre]

Nelson,

It would seem that the problem is in PSM, given that things work OK with ocspclnt. So Kai is the right person to look at this first. I will help if any NSS issues come up.

Comment 6

[Daniel Veditz [:dveditz]]

comment 3 sounds like an entirely different bug.

Comment 1 is close to derailing this bug into "fix PSM error messages" when the real problem at hand is getting OCSP to work right.

bug morph is evil, it'll result in partial fixes

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Categorizing this bug as "major".  Turning on OCSP by default with PSM has
made all certs issued by this CA stop working.  

Except for the fact that NSS's own OCSP test client program reports 
successful OCSP results, we might think this is merely a problem with 
the OCSP responder.  But since this seems to be a difference between 
the two separate OCSP clients (actually the two separate http front ends
for the one OCSP client), it's looking like a PSM bug.

OTOH, if NSS's ocspclnt test client program is lying to us, and the NSS
test requests are not having success, then ...

Comment 8

[Eddy Nigg (StartCom)]

Just a by-note, but current releases of both FF and TB _work_ with OCSP turned _on_. I understand that this covers both NSS and PSM. Using S/Mime and SSL for signature, encryption, IMAPS and POP3S.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Yeah, this problem is on trunk builds.  (Note the bug version: trunk)

Comment 11

[Kai Engert (:KaiE:)]

Nelson,

the problem you report in comment 0 is related to a bad error message.

You say, you assume that we fixed all error messages in PSM.

Unfortunately that is not true.

As of today, we only fixed the error messages "during SSL connections" to be more descriptive.

Because of separate bug 353535, I believe this bug is a request to improve the error message to indicate the real reason for saying "invalid signature" is because "cert is revoked".

Comment 12

[Kai Engert (:KaiE:)]

> Therefore, I believe
> this is a bug in PSM's OCSP client.

PSM does not have an internal OCSP client.
IINM PSM only does OCSP implicitly by calling NSS' cert verification functions.

Comment 13

[Kai Engert (:KaiE:)]

I was able to reproduce the bug.

NSS 3.11.7 fails in CERT_VerifyOCSPResponseSignature and sets SEC_ERROR_OCSP_INVALID_SIGNING_CERT

Being more specific, it fails while calling CERT_VerifyCACertForUsage, in the following code block:

1077        if (!validCAOverride) {
1078            /*
1079             * Make sure that if this is an intermediate CA in the chain that
1080             * it was given permission by its signer to be a CA.
1081             */
1082            /*
1083             * if basicConstraints says it is a ca, then we check the
1084             * nsCertType.  If the nsCertType has any CA bits set, then
(gdb)
1085             * it must have the right one.
1086             */
1087            if (!isca || (cert->nsCertType & NS_CERT_TYPE_CA)) {
1088                isca = (cert->nsCertType & caCertType) ? PR_TRUE : PR_FALSE;
1089            }


The failure is in line 1088. isca is PR_FALSE

(gdb) print cert->nsCertType
$66 = 16384
(gdb) print caCertType
$67 = 7


The certificate which signed the OCSP response has the subject:
"E=[e-mail],CN=StartCom Class3 Email Revocation Authority,O=StartCom Ltd.,C=IL"


Eddy, could you easily attach a dump of that cert?

Comment 14

[Kai Engert (:KaiE:)]

Sigh. Looks like we unnecessarily wasted a lot of time on this bug...

Mozilla trunk was still using NSS_3_11_7_BETA1.

The same issue got fixed in bug 381317...

I updated my tree to pull NSS_3_11_7_RTM and it works fine now :-/ :-/

Comment 15

[Kai Engert (:KaiE:)]

Attachment: Patch v1

While we haven't landed 3.12 yet, let's land latest 3.11.7 in the meantime, which will fix this bug...

Comment 16

[Eddy Nigg (StartCom)]

Attachment: S/MIME cert

As requested.

Comment 17

[Eddy Nigg (StartCom)]

Attachment: OCSP Class 3 Email Responder Certificate

The OCSP responder cert which was requested originally. Attaching for completeness of this bug.

Comment 18

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 269213 [details] [diff] [review]
Patch v1

I approve of this patch, whole heartedly!

Comment 19

[Kai Engert (:KaiE:)]

Patch checked into trunk, marking fixed.