Last Comment Bug 94413 - OCSP needs more fine tuned error messages.
: OCSP needs more fine tuned error messages.
Product: NSS
Classification: Components
Component: Libraries (show other bugs)
: 3.2.1
: x86 All
P2 enhancement (vote)
: 3.9
Assigned To: Julien Pierre
: Bishakha Banerjee
Depends on:
  Show dependency treegraph
Reported: 2001-08-08 16:53 PDT by Javier Delgadillo
Modified: 2003-09-29 18:50 PDT (History)
4 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

set new SEC_ERROR_OCSP_INVALID_SIGNING_CERT error if needed (1.40 KB, patch)
2003-09-29 17:22 PDT, Julien Pierre
wtc: review+
nelson: superreview+
Details | Diff | Splinter Review

Description User image Javier Delgadillo 2001-08-08 16:53:26 PDT
When NSS performs OCSP as part of verification, it doesn't set an error if in
the process the cert that signed the request doesn't verify. For example,
recently our OCSP service provider's certificate expired.  When I call
CERT_VerifyCertNow on a certificate, the error I get when calling PR_GetError is
that for an expired certificate.  As a caller I assume that means the cert I
passed in has expired, but that error actually means the ceritificate belonging
to the signer of the OCSP response has expired.

This makes giving adequate UI in PSM in error cases with OCSP tricky because we
don't know if it's the cert in question's error or the signer cert that fails.
Comment 1 User image Wan-Teh Chang 2001-10-31 19:17:27 PST
Assigned the bug to Julien.
Comment 2 User image Julien Pierre 2001-11-05 17:24:14 PST
I haven't been successful at doing any OCSP test yet - I always get errors, so
I'm unsure how to reproduce this problem right now.
As far as the fix, do you think I should add new error codes for this case (and
possibly other odd OCSP failures) ?

Comment 3 User image Julien Pierre 2001-11-06 16:55:53 PST
Lowering priority to P2 with Wan-teh's agreement.
Comment 4 User image Wan-Teh Chang 2002-04-25 16:31:08 PDT
Changed the QA contact to Bishakha.
Comment 5 User image Wan-Teh Chang 2002-05-08 17:07:54 PDT
Set target milestone to NSS 3.5.
Comment 6 User image Wan-Teh Chang 2002-05-29 16:14:53 PDT
Moved to NSS 3.6.
Comment 7 User image Wan-Teh Chang 2002-12-06 11:16:24 PST
Moved to target milestone 3.8 because the original
NSS 3.7 release has been renamed 3.8.
Comment 8 User image Julien Pierre 2003-01-29 19:07:17 PST

Don't CERT_VerifyCert / CERT_VerifyCERTNow (and the newer functions,
CERT_VerifyCertificate / CERT_VerifyCertificateNow) provide you a log ? Is this
log inadequate ? It seems this might be the answer to this complex issue, rather
than a simple PRError code.
Comment 9 User image Javier Delgadillo 2003-01-29 19:30:27 PST
Even if that were possible (I'm not sure), if I do OCSP and PR_GetError returns
SEC_ERROR_UNTRUSTED_CERT when in fact OCSP validation on the issuer failed,
that's flat out wrong.  The error code that gets set should be
Comment 10 User image Nelson Bolyard (seldom reads bugmail) 2003-05-09 21:19:00 PDT
Remove target milestone of 3.8, since these bugs didn't get into that release.
Comment 11 User image Julien Pierre 2003-05-12 16:35:13 PDT
Actually this is an OCSP enhancement and belongs in 3.9 .
Comment 12 User image Julien Pierre 2003-09-29 17:09:01 PDT

Regarding comment #9
The error code that you want here, SEC_ERROR_UNTRUSTED_ISSUER, is normally used
to signify that a certificate's issuer is invalid. It is not used to signify
that an OCSP response's signer certificate is an invalid.
Therefore it would be improper to use it for this case.

I think the best we can do for these cases where the responder's certificate
fails to verify is to set a new generic error code, such as
"SEC_ERROR_INVALID_OCSP_SIGNING_CERT" . I don't think it's possible to surface
any more level of detail to the caller without using a different mechanism than
a single error code - ie. error stacks.
Comment 13 User image Julien Pierre 2003-09-29 17:22:41 PDT
Created attachment 132379 [details] [diff] [review]
Comment 14 User image Wan-Teh Chang 2003-09-29 17:49:52 PDT
Comment on attachment 132379 [details] [diff] [review]


There is more work to do before we mark this bug fixed.

1. You need to add the new error code to some files in
mozilla/security/nss/cmd/lib so that our command-line tools
know about it.

2. You need to add the new error code to the SSL Reference
Comment 15 User image Nelson Bolyard (seldom reads bugmail) 2003-09-29 17:56:59 PDT
Comment on attachment 132379 [details] [diff] [review]

sr=MisterSSL, subject to comment 14 above.
Comment 16 User image Julien Pierre 2003-09-29 18:19:57 PDT
Checking in certhigh/ocsp.c;
/cvsroot/mozilla/security/nss/lib/certhigh/ocsp.c,v  <--  ocsp.c
new revision: 1.16; previous revision: 1.15
Checking in util/secerr.h;
/cvsroot/mozilla/security/nss/lib/util/secerr.h,v  <--  secerr.h
new revision: 1.12; previous revision: 1.11

Checking in SECerrs.h;
/cvsroot/mozilla/security/nss/cmd/lib/SECerrs.h,v  <--  SECerrs.h
new revision: 1.7; previous revision: 1.6

How do I add the code to the SSL reference ? I don't have a account
to publish files.

Comment 17 User image Wan-Teh Chang 2003-09-29 18:44:30 PDT
Updated the SSL Reference.

Checking in sslerr.html;
/cvsroot/mozilla-org/html/projects/security/pki/nss/ref/ssl/sslerr.html,v  <--
new revision: 1.10; previous revision: 1.9
Comment 18 User image Julien Pierre 2003-09-29 18:50:02 PDT
Thanks, Wan-Teh !
Marking fixed.

Note You need to log in before you can comment on or make changes to this bug.