On 07/05/2010 04:13 PM, james07 wrote: > I notice the cert8.db and key3.db files get updated only when the JVM shuts > down. That may explain why the new certificate doesn't show up. Is this > (update of the db files) the expected behavior? It seems strange. Is there a > way to commit the change? > Those databases do not support concurrent access, so it's possible there there is some caching going on, (though softoken usually syncs after a write, so I would have expected the files to be updated as soon as the cert and key are written to softoken).
What is probably happening is that Java is holding the file descriptors of open for the given files and they aren't actually visible until they close? What kind of FS does your profile live in. > Also, in addition to importing the generated key and certificate into the > active profile, I want to import the key and certificate into another > profile directory. What is the best way to achieve this? It seems JSS > doesn't allow access to more than one profile in the same process, i.e. > calling CryptoManager.initialize() again pointing to a different profile > directory results in an AlreadyInitializedException. > Wait. You are using JSS, are you starting JSS up yourself and having JSS initialize NSS, or are you using something integrated with the browser? If you have your own handles to the cert an key database, bad things (TM) will happen. cert8.db and key3.db are not multi-user safe. All that being said, if you are using the PSM initialized NSS profile, there are NSS calls that allow you to concurrently open another NSS database on the fly. Don't forget the rule against multiple accesses (don't open a profile that another app may have open at the same time). Once the second database is open, it looks just like another token. The certs and keys in that second database is available for all users of NSS at that point (including the running browser). I don't know if JSS has a reflection of that NSS call, but even if it doesn't, once the call is made, JSS can access that new token. There's another call to close that second database as well (it shows up as a removable token, so apps don't have any issues with the token disappearing out from underneath them. bob > Would using NSS directly solve the above problems (update of db files and > access to more than one profiles)? > > Thanks for the tip on ssltap. Sounds like a handy tool... will try to set it > up. > > Cheers, > James > > > Nelson B Bolyard-2 wrote: > >> On 2010-07-01 18:10 PDT, james07 wrote: >> >>> I'm importing the key pair into the browser's soft token. >>> >>> I can see that the cert8.db and key3.db files in the profile directory >>> are >>> updated and I can also see the new certificate using certutil.exe -L. >>> >>> However when attempting to connect to a website that requires client SSL >>> authentication in the same browser session (immediately following the >>> import >>> of the keypair), the browser does not seem to detect the new certificate. >>> It >>> is only after restarting Firefox that I can establish the mutual SSL >>> session >>> (and the imported certificate appears in Certificate Manager > Your >>> Certificates) >>> >>> Is it possible to refresh the PSM cache while the browser is running? >>> >> I suspect that there may be another explanation for this behavior. >> It *may* (or may not) be that FF is establishing a TLS session with the >> server that is not client authenticated, and thereafter the server is >> merely content to use that same session over and over, and it never >> attempts to force the client to renegotiate a new SSL/TLS session. >> >> A tool like ssltap would tell you if that is the explanation. There's >> another way to tell as a diagnostic step. There is a way to get the >> browser >> to completely flush its TLS/SSL session cache. If you would >> establish the TLS session without a client cert, then import your client >> cert, and then flush all your TLS sessions, that would force the next TLS >> connection to start a new TLS session. You could do that test, manually >> flushing your TLS session cache. If that caused the client cert to be >> used in a client authentication, then you would know that the server is >> not continuing to demand client auth after the first time it negotiates >> a TLS session with only server auth. >> >> In the event that this test positively shows that continued reuse of old >> TLS >> sessions that were established without client authentication explains the >> behavior you see, I do NOT mean to suggest that additional flushing of the >> client's TLS session cache is the solution. It is only a diagnostic step. >> If we know the cause of the problem, then we can discuss the NUMEROUS >> different possible solutions. >> -- >> dev-tech-crypto mailing list >> dev-tech-crypto@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-tech-crypto >> >> >> >
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
