Hi adeteran,

Hi, we are using JCAPI to sing and validate documents from an applet. It's the best proveder we have found at time, to access MSCAPI, so we'll gladly buy a license to use it, when all tests are OK.

Thank you. Every contribution is step forward of making JCAPI better.

Regarding your problem; I've verified it and you are correct. We have not discovered it ourselves until now since all signatures made through a PKCS#11 CSP have been verified through MS CAPI. That's why the signatures also are successfully validated through both JCAPI and SunMSCAPI providers.

There's nothing wrong with the signatures, but we have to investigate why the signatures are different (which formats) when generated through MS CAPI and PKCS#11.

Regards,
Tommy

Hi,

That's an old problem. It's a type safety feature of the Java Virtual Machine - that is loading of the same JNI native library by separate class loaders is not allowed (for more info, see http://java.sun.com/docs/books/jni/html/design.html#862.

There are a couple of solutions available to circumvent this; the simplest (and ugliest) solution is to add the JCAPI provider (and thus dynamically load the JCAPI DLL) each time the applet is loaded. To ensure name space separation based on class loaders and still avoid exceptions will require you to load the same DLL, but with a DIFFERENT name. This means that the DLL must be renamed before adding the JCAPI provider. An annoying side effect here is that there will be multiple instances of the same DLL loaded into the JVM which in turn will increase the process space.
Here's an example of how this can be implemented:

void addJCAPIProvider()

    throws Exception

{

    //Use a temporary JCAPI DLL in a temporary directory.

    File dir = new File(System.getProperty("java.io.tmpdir") + "/jcapitmp");

    JCAPIDLL.getInstance().setDirectory(dir);

    String dllName = "JCAPIweb_" + Long.toString(System.currentTimeMillis()) + ".dll";

    JCAPIDLL.getInstance().setFilename(dllName);

    if(!dir.exists())

        dir.mkdir();

    else

        {

            //Perform cleanup.

            //Delete all JCAPI DLLs that are not already loaded into the JVM(s).

            File[] files = dir.listFiles();

            if(files.length > 0)

                {

                    for(int i = files.length - 1; i >= 0; i--)

                        files[i].delete();

                }

        }



    Security.addProvider(new JCAPIProvider());            

}

A more sophisticated solution (using JCAPI in an applet which resides in a hidden frame and then use applet-to-applet communication with the applet that is reloaded) of the same problem can be found here:
http://www.javaworld.com/javaworld/javatips/jw-javatip101.html

Regards,
Tommy

Hi Muthu,

We need to get some more information from you in order to solve this:
1. Please read chapter 7 (page 35) in the JCAPI User's Guide and post the requested information mentioned there. Especially important is to get your output from executing the following: JCAPIUtil.getEnvironmentInfo();
2. What is the full name of your eToken e.g eToken PRO 32k USB Token?
3. Perhaps a stupid question, but does your eToken function correctly in other environments i.e signing and decryption works alright in other programs?

Regards,
Tommy

Anonymous wrote:FF. It seems that solution posted on previous post doesn't work on IE

Our download database reports that you (ip 80.233.156.204) downloaded JCAPI twice i.e at 2007-08-11 21:58:39 and 2007-08-11 21:58:46. Do you mean that you didn't receive the file at all, or was it only possible when pressing the Download JCAPI button?

What version of IE are you using?

Regards,
Tommy

Anonymous wrote:JCAPI download link is broken, the from actually do not submit anything.

I was still able to download product by using http://pheox.com/download?productid=15
(looked into produced http://pheox.com/download html).

Please fix that.

We really would like to try out/by your products, but our managers prefer to work with "mature companies, which has non-broken download links"

What browser, and version, are you using? If you say that the form is not submitted at all then it's very serious.
Our site is tested with Firefox and IE (5, 6, and 7) and we have not encountered these kinds of problems before.

By searching our download database, I can see that JCAPI was downloaded by you (ip address 85.254.221.242) at 2007-08-11 19:17:46. Just before this time interval, our web logs reports a socket time out from the database connection used by our download servlet. I have to look closer at this to determine the cause of the time out.

Thanks for notifying us about the problem.

Regards,
Tommy

Hi,

Hmm, when looking closer at your JVM dump:

# Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode)

# Problematic frame:

# j java.lang.ClassLoader$NativeLibrary.load(Ljava/lang/StringV+0 

I see that the DLL fails to load completely i.e no native function in the JCAPI DLL is called at all. When an error (e.g a memory access violation) occurs inside the DLL it shall report that the error originated from within the DLL:

# Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing)

# Problematic frame:

# C  [JCAPI.dll+0x70ffa]

This is also the reason why you won't get any log output from the DLL since it is never loaded.

Just a thought, how is JCAPI packaged and deployed with your web service? Is it part of your web service WAR file (and thus loaded through the same class loader as your web service context i.e from webapps\<your service>\WEB-INF\lib) or is it stored in a shared JAR file folder or in any endorsed directory? In my tests, I did package JCAPI within my test WAR file without any problems.

Another possible reason for the JVM crash might be due to the protection (obfuscation) mechanisms applied onto the evaluation version of JCAPI. When the DLL is loaded, it will decrypt and relocate the PE sections in the DLL file which in turn might have some ugly side effects in rare situations. One possible solution here would be for us to send you the commercial (unprotected) version of JCAPI for you to test with. In this case we can at least disregard the protection mechanism to be the cause to your problem. Please send a mail to Pheox support (including a reference to this forum post) and we'll send you the unprotected version for you to try with.

Regards,
Tommy

Hi,

I've tested your web service example with Tomcat 6, JAX-WS 2.1.1, and Java 6 on Windows Vista without any problems.

Could you please answer the following questions:
1. Will your web service test program always crash the JVM, or are there any occasions when it turns out fine (indeterministic crashes)?
2. What happens if you load the JCAPI DLL by executing one of the JCAPI example programs from command line? Do they crash the JVM as well?
3. Can you use JCAPI in an applet via Tomcat without crashing the JVM?
4. Could you please send us your environment info to help us to locate your problem. Just call the method JCAPIUtil.getEnvironmentInfo() from within a Java app. For more info, see page 35 in the JCAPI User's Guide.

I've compiled and attached a special version of JCAPI for you to try as well. It will produce logging info when the jcapi.dll file is loaded into the JVM and store the result in file C:\JCAPI\jcapilog.txt (please make sure that the directory C:\JCAPI exists).
Please replace your current jcapi.jar file with the attached one and run your web service test again, and send us the content of "C:\JCAPI\jcapilog.txt".

Regards,
Tommy

Hi,

There's nothing wrong with your test code. When using JCAPI, the PIN code is only required when the (non-exportable) private key is actually accessed for signing or decryption operations. In this case when you call jks.getKey(alias, null);, JCAPI will first check if the private key is exportable, and if it's not exportable then JCAPI will return a handle (in a JCAPIRSAPrivateKey instance which implements the RSAPrivateKey interface) to the key i.e JCAPI is not accessing your private during the getKey() operation.

Please note that if you're going to use JCAPI together with SUN's own implementation of trust- and key managers, then your private key must be exportable since they assume that a private key instance passed to them contains its raw private key data, they simply do not know the meaning of a key handle. SUN has also recognized this problem and thus implemented support for this in Java 6, but their solution seem to be hard coded to their own MS CAPI provider. If you want to use JCAPI with non-exportable private keys and SUN's key- and trust managers, then you'll have to wait for the JCAPI v2.0 release.

In your current situation, there are five solutions available for you (as mentioned in the thread I pointed out in my previous reply):

1. You can use the JCAPI SSL plugin which contains and uses its own trust- and key managers. Unfortunately it uses SUN's own PKCS#11 provider beneath and will thus require Java 5 or higher.
2. Use SUN's PKCS#11 provider directly and choose your own key- and trust managers. This of course will as well require Java 5 or higher.
3. Use SUN's new MS CAPI provider in (introduced in Java 6) which might solve your issue.
4. Make your private key exportable i.e import it into MS CAPI instead of your hardware token.
5. Wait for JCAPI v2.0.

Regards,
Tommy

Hi,

Your error:

Caused by: java.security.InvalidKeyException: Modulus is missing

That error is typical to get when SUN's JSSE implementation is trying to use the private key for signing operation, but it fails since the key does not contain the private key data. Shortly it means that your private key is not exportable at all. Either your private key is stored on a hardware token, or you have imported your key into MS CAPI's container with export restrictions.

In any case, JSSE do require the data of the private key in order to successfully perform its signing operation. You can solve your issue in numerous ways, please read the following thread for advice:
http://pheox.com/posts/list/18.page

Regards,
Tommy

JCAPI version 1.2.2 has been released today.

This is a minor update containing one bug fix:

• Non-administrator users could not access certificates (and allotted private keys) imported by administrators into the LOCAL_MACHINE system store registry location.

For a complete list of enhancements and bug fixes made, please read the version history.

Our customers can download the commercial (unrestricted) version from the customers download page. Others are welcome to download the evaluation version from our public download page.

JCAPI version 1.2.1 has been released today.

This is a minor update containing:

• The JCAPI JAR file has been re-signed with a new code signing certificate since the former will expire at the 12th of May 2007. The new certificate is valid until 24th of May 2009. This will only affect you if you're using JCAPI in a trusted applet.
• Bugfix: The list of available MS CAPI system stores was not updated to include the missing ADDRESSBOOK store after JCAPI created it.

For a complete list of enhancements and bug fixes made, please read the version history.

Our customers can download the commercial (unrestricted) version from the customers download page. Others are welcome to download the evaluation version from our public download page.

Thank you for your support and the Assembla team (I have used the same libraries for another project).

No problem.

Now I've tried Sun MSCAPI, but during handshake it popups a window for PIN request, but I don't like it because I need to automatize all the login process without manually inserting anything.

Ok. I've not tested it myself with hardware tokens, but I admit that it sounds annoying.

Well, what you can do now is the following:
1. Get hold of the required PKCS#11 DLL for your SysGillo CSP. All CSPs that I've heard of do provide support through PKCS#11, so a good thing to do is to get in contact with the SysGillo CSP manufacturer and ask for the file. Another possibility is that you might already have the file in question on your hard drive. I made a search on the net for SysGillo and found the following interesting page (http://www.digitaltrust.it/i-sign/token.php). It shows the following SysGillo associated PKCS#11 files (perhaps you can find one or more of them on your hard drive?):
IpmPki32.dll
IpmPkilu.dll
IpmPkilc.dll

2. Or buy yourself another hardware token. I've had a discussion with a sales manager at Advanced Card Systems Ltd, and he says that the ACR30 model is old and is about to be phased out (and he has never heard about the SysGillo CSP). Perhaps there are other solutions available that will suit your needs?

Regards,
Tommy

Hi Marco,

Your stack trace is most peculiar:

Exception in thread "main" javax.net.ssl.SSLHandshakeException: Error signing certificate verify

Caused by: java.security.InvalidKeyException: You must use a RSA public key for encryption.

at se.assembla.jce.provider.ms.MSCipherRSAJNI.engineInit(Unknown Source)

If you want to use the Assembla JCE provider, then you have to speak with the guys at Assembla about your problem.

If you want to use JCAPI together with a hardware token in your SSL enabled program, then there are some JCAPI specific limitations to take into consideration:
1. There must be a PKCS#11 DLL available for your hardware token, and JCAPI must be configured to use it (either supported by default, or you have to add it manually through the method JCAPIUtil().addPKCS11CSP(String, String)).
2. You must use Java 5 or higher since the JCAPI SSL plugin is using SUN's PKCS#11 provider that is include in Java 5 and higher versions.
3. You have to use the JCAPI SSL plugin. If you're using JCAPI with your own key- and trust managers, then the JCAPI PKCS#11 support will not be available since it is utilised by the key- and trust managers within the JCAPI SSL plugin. Shortly meaning that you can only use JCAPI with your own key- and trust managers if the private key is exportable from MS CAPI.

Since your environment do not provide a PKCS#11 DLL for your CSP, then you cannot use JCAPI or SUN's PKCS#11 provider. But there is probably a solution available for you; SUN has implemented a MS CAPI provider in Java 6 that should support hardware tokens in SSL. A good starting point here would be:
http://java.sun.com/javase/6/docs/technotes/guides/security/SunProviders.html#SunMSCAPI
http://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html

Seamless SSL support for JCAPI with hardware tokens without required PKCS#11 support is subject to version 2.0.

Regards,
Tommy

Hi MN,

Sorry, that's not possible.
But don't you worry about the size of the JAR. It's only applicable for the evaluation version of JCAPI. The commercial variant is actually smaller than v1.1 since it doesn't contain the same protection mechanisms.

Regards,
Tommy

Hi Marco,

When you are not using the JCAPI SSL plugin, and instead uses the default key- and trust managers, then the following rules apply:
1. If JCAPI is required to export a private key, then JCAPI must be configured to export it i.e use the following code (see example program C:\JCAPI\examples\ssl\httpsclient\noclientauth\HTTPSClient.java):

JCAPIProperties.getInstance().setPrivateKeyExportable(true);

2. Only private keys that are exportable can be used i.e you cannot export private keys that are stored on a hardware token, nor can you export a key from MS CAPI that is marked as non-exportable.

If you want to use a hardware token with SSL than you can either use the JCAPI SSL plugin (which require Java 5 or higher since it uses SUN's PKCS#11 provider) or you can use SUN's PKCS#11 provider directly and use it together with the default key- and trust managers.

If you prefer the JCAPI SSL plugin, then please remember that you have to manually add your PKCS#11 supported CSP to JCAPI if the CSP is not supported by default, for example:

String cspName = "FooBar Cryptographic Service Provider";

String pkcs11FileName = "foobar.dll";

JCAPIUtil().addPKCS11CSP(cspName, pkcs11FileName);

Regards,
Tommy