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.
Assigned the bug to Julien.
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) ?
Lowering priority to P2 with Wan-teh's agreement.
Changed the QA contact to Bishakha.
Set target milestone to NSS 3.5.
Moved to NSS 3.6.
Moved to target milestone 3.8 because the original NSS 3.7 release has been renamed 3.8.
Javi, 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.
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 SEC_ERROR_UNTRUSTED_ISSUER.
Remove target milestone of 3.8, since these bugs didn't get into that release.
Actually this is an OCSP enhancement and belongs in 3.9 .
Javier, 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.
Created attachment 132379 [details] [diff] [review] set new SEC_ERROR_OCSP_INVALID_SIGNING_CERT error if needed
Comment on attachment 132379 [details] [diff] [review] set new SEC_ERROR_OCSP_INVALID_SIGNING_CERT error if needed r=wtc. 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 (http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html).
Comment on attachment 132379 [details] [diff] [review] set new SEC_ERROR_OCSP_INVALID_SIGNING_CERT error if needed sr=MisterSSL, subject to comment 14 above.
Checking in certhigh/ocsp.c; /cvsroot/mozilla/security/nss/lib/certhigh/ocsp.c,v <-- ocsp.c new revision: 1.16; previous revision: 1.15 done Checking in util/secerr.h; /cvsroot/mozilla/security/nss/lib/util/secerr.h,v <-- secerr.h new revision: 1.12; previous revision: 1.11 done Checking in SECerrs.h; /cvsroot/mozilla/security/nss/cmd/lib/SECerrs.h,v <-- SECerrs.h new revision: 1.7; previous revision: 1.6 done Wan-Teh, How do I add the code to the SSL reference ? I don't have a mozilla.org account to publish files.
Updated the SSL Reference. Checking in sslerr.html; /cvsroot/mozilla-org/html/projects/security/pki/nss/ref/ssl/sslerr.html,v <-- sslerr.html new revision: 1.10; previous revision: 1.9 done
Thanks, Wan-Teh ! Marking fixed.