When VeriSign visited for OCSP inter-operability testing, we discovered that the PSM OCSP http code didn't properly fetch the entire request from their OCSP responder. When I doubled the buffer size NSS used for reading, all of a sudden it successfully read the entire response. This bug is here to track bug. To reproduce, install the following cert into your database http://javi.red.iplanet.com/u/javi/RSAOCSP.cacert (If you can't access this site, please e-mail so that I can get you the cert.) Then configure PSM to always use that cert when doing OCSP (or use a customized NSS OCSP client app). Use default responder mode and use the following defaults: site: http://status2.verisign.net/ocsp/ signer: Secure Server OCSP responder

VeriSign's service is currently down, so I can't test any fixes for now..

Javi, what is the buffer that NSS used for reading? Do you remember the source file and line number?

I don't remmeber if the change was required by doubling the size of the buffer allocated to read in, or if it was the read size that required doubling. Only one of these changes was necessary, I just don't remember which one. (Damn, I should've put the diff in the original bug report.) Both fixes are in the following patch, but I can't test them until VeriSign's service is back up. I can try again later today to see if their service is running again. D:\moz-security\mozilla\security\nss\lib\certhigh>cvs diff -c ocsp.c Index: ocsp.c =================================================================== RCS file: /cvsroot/mozilla/security/nss/lib/certhigh/ocsp.c,v retrieving revision 1.1 diff -c -r1.1 ocsp.c *** ocsp.c 2000/03/31 19:43:00 1.1 --- ocsp.c 2000/09/20 17:20:53 *************** *** 1792,1798 **** #ifdef BUFSIZ #define OCSP_BUFSIZE BUFSIZ #else ! #define OCSP_BUFSIZE 1024 #endif /* --- 1792,1798 ---- #ifdef BUFSIZ #define OCSP_BUFSIZE BUFSIZ #else ! #define OCSP_BUFSIZE 2048 #endif /* *************** *** 1836,1842 **** * all of the http headers, and just a bit of the content. * This is what I was aiming for, to minimize data copying. */ ! bytesRead = ocsp_MinMaxRead(sock, buf, 128, bufsize); if (bytesRead <= 0) { if (bytesRead == 0) PORT_SetError(SEC_ERROR_OCSP_BAD_HTTP_RESPONSE); --- 1836,1842 ---- * all of the http headers, and just a bit of the content. * This is what I was aiming for, to minimize data copying. */ ! bytesRead = ocsp_MinMaxRead(sock, buf, 256, bufsize); if (bytesRead <= 0) { if (bytesRead == 0) PORT_SetError(SEC_ERROR_OCSP_BAD_HTTP_RESPONSE);

I modified my NSS code and re-build PSM to double the buffer size for read and allocated buffer and this no longer fixes the problem. This is gonna require more investigation.

Javi, did you try doubling either the buffer size for read or allocated buffer (but not both)?

I applied the patch in this bug which doubled both. I don't remember if I went through and tried just one or the other. I believe I did. I don't have enough cycles to investigate this much further.

Reassigned to javi to investigate per the PKI leads meeting on Monday (9/25).

Is this the same OCSP interoperability problem that David Drinan investigated before? In that problem he found that the response we got from VeriSign's OCSP responder failed a check (on next update?) in NSS.

Javier, Do you have a dump (eg. from snoop) of Verisign's HTTP OCSP response ? In particular, do you know if it contained a content-length or was the code waiting for EOF on the socket ? There are basically 2 code paths within the HTTP OCSP code - one for content-length and one without. I had a quick look and it appears to be fine. Perhaps there is something wrong in Verisign's response. It would be useful if you could provide the exact URL of the HTTP OCSP responder for Verisign to test with.

Changed the QA contact to Bishakha.

Reassigned the bug to Julien. Target NSS 3.6. John, could you follow Javi's instructions and see if you can reproduce this bug with Mozilla 1.0 RC2 or the Mozilla trunk nightly build?

WTC, I've installed the cert and setup OCSP, but what should I be looking for now?

John, You just need to verify that the OCSP code in PSM inter-operates with VeriSign's OCSP responder. It seems like the host "status2.verisign.net" in the URL that Javi provided (http://status2.verisign.net/ocsp/) no longer exists. Javi, do you know the URL of the current VeriSign OCSP responder? I did a Google search for "VeriSign OCSP Responder" and found this page: http://www.openvalidation.org/publicresponders.htm. John, you can try http://ocsp.verisign.com.

I'm not sure what the service URL is anymore.

WFM. I downloaded and installed the root CA and a personal cert, then setup for OCSP service. The personal cert was invalidated using OCSP, and validated when OCSP was turned off.

Thank you, John. Could you tell me which Mozilla build you tested?

The buffer logic in the OCSP HTTP code was incorrect . Please see the patch in http://bugzilla.mozilla.org/attachment.cgi?id=83129&action=view . This is for bug http://bugzilla.mozilla.org/show_bug.cgi?id=141256 . I suspect this will solve this problem too.

WTC: Gecko/20020515 Netscape/7.0b1

I am changing the target milestone to NSS 3.4 because the NSS in Netscape/7.0b1 is a snapshot of NSS taken a few days before NSS 3.4 RTM, plus some bug fixes.

Verified WFM.