Bob, Thanks a lot for the reply.
We do the P12 export followed by CAPI based signing due to historical reasons. Customer wanted something quick and there was no time to change everything from CAPI to NSS. We now do have a NSS only version but it appears that we may need to make some changes there as well. We still have to support our quick and dirty (P12 export + CAPI) implementation since the customer is not ready to upgrade. If we were to spawn another process (not just a thread) and tried to initialize NSS, will it go through? Assuming we are in a mozilla browser in a https session and the browser JavaScript is the trigger for the process spawing either thorugh a Java applet or ActiveX (we can't use XPCOM since IE and SAFARI don't support it). So the question really it does NSS allow multiple clients on the same machine? Regards, Manoj Srivastava "Bob Relyea" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Manoj Srivastava wrote: > >>When the master password timeout option is set to "Every time it is >>needed", the <keygen> tag in the HTML page used for generating private key >>fails to work properly. This page has code to invoke our ActiveX component >>for signing the certificate request. Our component uses NSS API to open >>the Netscape certificate store and export as P12 the certificate the user >>selects for signing the request. This component does the NSS >>initialization as follows: >> > If you are calling NSS itself inside the a running mozilla browser, you > should not be calling NSS init. You'll find that your NSS_Initialize call > will fail if mozilla has already initialized NSS. If you want to use NSS > inside the address space, you need to use XPCOM to start the > nsNSSComponent object. Note, as is, your component copies the cert & key > db, then opens NSS. This means that if the user will not be able to modify > their database until they shutdown, since it's pointing to your read only > copy. > Also, overriding PK11_SetPasswordFunc, overrides this for all of mozilla, > that is why you are not getting a password prompt. > > Your design is also a bit brittle since you may not be able to export a > p12 file if the cert you want to sign with if the key and cert live in a > token. Is there a reason you can't just use NSS to sign? The hard part > about signing with NSS is finding the cert. You already do that (or p12 > export wouldn't work). > > If you still have to use your active X control, you might have better luck > installing a CSP that routes requests to your Component. You then load the > certificate using the normal NSS can windows Cert Store calls, and mark it > has pointing to your CSP. When your active X control needs to sign, it > will automatically get open the CSP, which would route your request to > your comonent, which would use NSS to do the actual signature. > > In either case it best to avoid trying to move the key around from a > loaded component. > > bob > >>HRESULT NetscapeUtilStart(char **tempNetDir) >>{ >>HRESULT res; >>SECStatus rv; >> >>*tempNetDir = (char *)malloc(MAX_PATH * sizeof(char)); >>res = copyNetscapeDatabases(*tempNetDir); // We copy the databases at a >>separate location to prevent interference with Netscape's usage of the >>database. >> >>// Initialize the password function >> >>PK11_SetPasswordFunc(SECU_GetModulePassword); //The password is passed >>programmtically and hence a prompt is not needed >> >>rv = NSS_Initialize(*tempNetDir, "", "", "secmod.db", NSS_INIT_NOMODDB | >>NSS_INIT_READONLY); >>if (rv != SECSuccess) >> res = S_FALSE; >>return res; >>} >> >>After we are done with exporting the selected certificate as P12, we use >>CAPI for actual signing. We do not shutdown NSS when we exit as it >>prevents Netscape from using it as well. >> >>If we do not use our component for signing the certificate request, >><keygen> works fine and prompts for password three times during the key >>generation process. When we use our component for signing the request, we >>are not prompted for password at all. >> >>Any help will be greatly appreciated. >> >>Best regards, >> >>Manoj Srivastava >> >> >>_______________________________________________ >>mozilla-crypto mailing list >>[email protected] >>http://mail.mozilla.org/listinfo/mozilla-crypto >> > > _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
