Nelson Bolyard wrote: > I wrote (quoting Bill Burns): > >>>>> One error I get while attempting to authenticate to an internal site >>>>> with my certificate-on-a-smartcard is this one: >>>>> "Alert: An internal failure has been detected. It not possible to >>>>> complete the requested OCSP operation." >>>>> >>> That error string has a name, which is "OCSPDeadlock". I think (not >>> sure) it happens when the OCSP request is sent over an https connection >>> and the OCSP server's cert itself specifies an OCSP URL, causing >>> recursive OCSP lookup. >>> > > Actually, I now believe it is the certificate of the OCSP responder itself, > the one used to verify the signature on the OCSP response, that may have > an AIA specifying OCSP, that causes the recursion. > > The recursion occurs while verifying the OCSP responder's signature cert, > not while verifying an https server's cert, IINM. >
Let me explain in more detail. This OCSPDeadlock is a regression in Firefox 2. It should already be fixed in Firefox 3 / trunk development code. The OCSPDeadlock got introduced when we added the code to support OCSP via proxies. At that time we changed NSS to no longer use a minimalistic http client to fetch OCSP data, but started to call back into Firefox' own http code. Unfortunately, while Firefox is a multithreaded application, there are limitations. The User Interface and the Networking code are sharing the same thread. You typically run into this deadlock in the following situation: - some code wants to present a cert in the UI - prior to display the code requests cert verification - so the UI thread calls into NSS, which calls back into Firefox for OCSP - but the thread that usually does networking is not available, because the thread is blocked on that earlier user interface code, waiting for the result So, it's not a deadlock at the NSS level. It's a deadlock at the Firefox level. Firefox 3 / trunk development code has smart new code that allows us to use the internal networking, even when user interface is blocked. I am not aware of a solution for Firefox 2. A solution would require to identify all code scenarios, where such a deadlock could occur. And it would require smart new code to spawn the verification to a separate thread and continue the user interface later after the answer arrived. This seemed too difficult to do on the Firefox 2 branch. How critical is this problem for you? If it's critical, maybe we could look into a patch that reverts Firefox 2 to use the NSS internal OCSP client, when no proxy is being used. However, if you require this to work over a proxy, I can not think of a good solution for Firefox 2. Kai _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
