You can choose to use the NSS database on both sides if you wish and use the JDK's SunPKCS11 bridge from your Java application to get to the keys and certificates in the NSS keystore/certstore.
Take a look at the source code of StrongKey (www.strongkey.org) on the client side (Symmetric Key Client Library). It can use JKS, NSS and smartcard-based keystores from the same Java-based application. Arshad Noor StrongAuth, Inc. P.S. If you absolutely needed to keep the keys in JKS on the client side and NSS on the server side, then you can use the source code in StrongKey to move the keys/certs from one keystore to the other, if you wish. You'll have to write a tiny little application to do the moves, but the library can take care of the access on both sides. Yevgeniy Gubenko wrote: > Let me explain you my motivation: > I have client java 1.6 application, which runs on windows platform. > The server java 1.6 application runs on Solaris 10 and should be FIPS140-2 > compliant. > Thus, all crypto on server side should pass through the tunnel of PKCS#11 > provider crypto API to NSS 3.11.4, which is FIPS 140-2 compliant. > The client server communication is performed by RMI over SSL. > Therefore, we should keep private/public key pair both on client side and on > server side. > The client keeps both keystores (private and public) on JKS format files > (they can be created with certificate, if needed for future NSS issues) , and > the server should keep it in NSS db in FIPS mode (otherwise it won't be FIPS > 140-2 compliant). > Still, both application need to share their public keys so that Java > applications on both sides will manage to instantiate SSL context for socket > traffic over SSL. > How would you suggest me to design my RMI traffic, so that I'll be able to > preserve my FIPS 140-2 compliancy mode? > Thanks > Yevgeniy > _______________________________________________ dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
