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?
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. 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 > > -- View this message in context: http://old.nabble.com/How-to-refresh-Firefox-keystore-tp29042183p29080574.html Sent from the Mozilla - Cryptography mailing list archive at Nabble.com. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
