37020 - lousy error when Send encrypted msg but sender's cert is bad

Status: NEW

(NSS :: Libraries, defect, P4)

Description

[Steve Parkinson]

(This bug imported from BugSplat, Netscape's internal bugsystem.  It
was known there as bug #355647
http://scopus.netscape.com/bugsplat/show_bug.cgi?id=355647
Imported into Bugzilla on 04/24/00 16:24)

I import a CA cert and do not trust it for anything.

Next I import another user's email cert too, and trust it explicitly with:
 security advisor->people,
 clicking on the user,
 trust the cert.

I try to send an encrypted email to the user. When I press 'send', I get an
error dialog (copied from allxpstr.rc for you convenience)...

 ResDef(SEC_ERROR_UNTRUSTED_CERT,                SEC_ERROR_BASE   21,
 "The certificate for this server has been marked as not\n\
 trusted by the user.  Netscape refuses to connect to this\n\
 server.")

If I trust the CA certificate for email, then the mail is sent just fine.

One thing Lisa asked us to try was to open the security advisor before
pressing 'send'. In the top half of the security advisor screen, it did
not list any users whose certificates it did not trust (as expected).
When we turned off explicit trust for the user, and for the CA cert,
it did correctly say that the user's certificate could not be trusted.

So, the security advisor can correctly detect whether the recipient's
cert is trusted, but there must be another path through the code which
happens when you press 'send', which verifies trust in a different way.

Also note that the message in the dialog is inappropriate anyway. We're not
doing SSL to the server.

------- Additional Comments From lord  Jul-06-1999 08:04 ------- 

Assigning to ddrinan.

David, is this an NSS bug or a C4.x bug that we need to fix in Cartman?



------- Additional Comments From repka  Jul-06-1999 10:31 ------- 

The problem was actually that, when setting up this situation,
the *sender*'s cert ended up as not trusted.  The bug is really
two pieces -- the error shown does not adequately explain that,
and the Security Advisor does not explain it.  The former could
be fixed in either Cartman or in NSS; NSS is probably a more
appropriate place for the fix, but getting it right is harder
than you'd think because of the way our errors are done, and this
particular problem is just one of very, very many crummy errors
that we hope to seriously improve in Stan (*not* in NSS 2.7).
I'd like to consult with relyea before we agree to attempt to
fix this particular one.  But I'm going to change the title to
reflect that problem, and reassign it to me.  Just no promise
that it'll actually get fixed.

The other problem, though, in the Security Advisor really should
get fixed in Cartman, I think.  I'm going to open a separate bug
for that and assign it to ddrinan.

Comment 1

[Lisa Repka]

This is a specific problem part of a larger general problem.  The error message
is crummy (suggests the problem has to do with a "server" when SSL isn't even
involved, because most of our cert-related errors were originally created when
SSL was the only reason to use certs, and the error messages never got changed)
and also the error message doesn't get improved at higher levels which know
even more context about the problem going on.  This should get better as we
start to use an error stack instead of the current method, but this *specific*
case could be handled sooner if that is really desired.  Leaving the decision
up to chrisk, who might even want to close this as part of the bigger problem
of improving all error handling in either NSS-at-large or the PKCS7 part itself.

Comment 2

[Asa Dotzler [:asa]]

This should probably be confirmed.  Doing that.

Comment 3

[Wan-Teh Chang]

Set Target Milestone 4.0.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Clearing P1 from bugs for which we're obviously not holding any releases.

Comment 5

[Julien Pierre]

I don't believe any of this UI even exists anymore. I am not sure what the equivalent would be in Mozilla today. This makes the bug hard to reproduce and fix.