I not sure about the current version (3.6) of FF, but earlier versions
(FF 2.0 and 3.0), the key/certificate DB did not support multiple write
interfaces i.e. DB write using one API does not get propagated to other
API. As a result, keys/certs added by JSS API are not picked by the PSM
XPCOM API.
I am not sure if there was any bug filed, but I have encountered this
bug in Firefox versions 2.x and 3.0.
My understanding is that current version NSS supports another DB (not
set by default) that supports multiple read/write interface with change
propagation.
--
Subrata
On 07/05/2010 07: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?
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
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
