Loading KeyStore acts differently on Mac JDK and Windows JDK

Our company has been required to integrate with a 3rd party vendor which requires 'client authentication' to their server using a Digital ID certificate (Class I). After purchasing our Digital ID from Verisign (which is installed in Firefox), we export the certificate to a PKCS12 format (which includes the private and public key). This file is what we use to load our KeyStore object. Here is the code:

URL url =new URL("digital_id.p12");

KeyStore ks = KeyStore.getInstance("PKCS12");

InputStream isDigitalId = url.openStream();

ks.load(isDigitalId,"abc123".toCharArray());

Here's what is baffling and I've googled for 3 days looking for the reasoning behind the inconsistent behavior. When the above code is compiled on my mac which is running JDK 1.5.0_07 (build 1.5.0_07-164), my junit tests and everything work perfectly. If I create an executable jar which calls the code above, IT WORKS ON ALL PLATFORMS when I run the jar file.

Now, when the above code is compiled and the junit tests are executed on my Windows machine running JDK 1.5.0_12 (build 1.5.0_12-b04), the unit tests throw exceptions. When the test is compiled and built into an executable jar file and run on Windows, it also throws the same exception which is:

java.io.IOException: Too much data

at sun.security.util.DerIndefLenConverter.parseLength(DerIndefLenConverter.java:140)

at sun.security.util.DerIndefLenConverter.convert(DerIndefLenConverter.java:298)

at sun.security.util.DerInputStream.init(DerInputStream.java:94)

at sun.security.util.DerInputStream.<init>(DerInputStream.java:63)

at com.sun.net.ssl.internal.ssl.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:1221)

at java.security.KeyStore.load(KeyStore.java:1150)

at com.frontierairlines.giftcard.service.AuthSSLProtocolSocketFactory.createKeyStore(AuthSSLProtocolSocketFactory.java:192)

at com.frontierairlines.giftcard.service.AuthSSLProtocolSocketFactory.createSSLContext(AuthSSLProtocolSocketFactory.java:238)

at com.frontierairlines.giftcard.service.AuthSSLProtocolSocketFactory.getSSLContext(AuthSSLProtocolSocketFactory.java:310)

at com.frontierairlines.giftcard.service.AuthSSLProtocolSocketFactory.createSocket(AuthSSLProtocolSocketFactory.java:349)

at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)

at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)

at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)

at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)

at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)

at com.frontierairlines.giftcard.service.GiftCardClient.connect(GiftCardClient.java:66)

at com.frontierairlines.giftcard.service.GiftCardClientTest.testConnectWithResponseAsString(GiftCardClientTest.java:75)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:585)

at junit.framework.TestCase.runTest(TestCase.java:154)

at junit.framework.TestCase.runBare(TestCase.java:127)

at junit.framework.TestResult$1.protect(TestResult.java:106)

at junit.framework.TestResult.runProtected(TestResult.java:124)

at junit.framework.TestResult.run(TestResult.java:109)

at junit.framework.TestCase.run(TestCase.java:118)

at junit.framework.TestSuite.runTest(TestSuite.java:208)

at junit.framework.TestSuite.run(TestSuite.java:203)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:585)

at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)

at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)

at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)

at org.apache.maven.surefire.Surefire.run(Surefire.java:132)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:585)

at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)

at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818)

Has anyone ever come across this or have any insight on how we can get this code to run properly on Windows as well as linux?

Thank you.

[5250 byte] By [wb138834a] at [2007-11-27 11:51:12]
# 1

It seems the problem lies in the content of the pkcs12 file. Where did you place it? Is the binary file changed on Windows?

wangwja at 2007-7-29 18:36:46 > top of Java-index,Security,Other Security APIs, Tools, and Issues...
# 2

I've exported the digital id into a pkcs12 file about a dozen times and I've placed it in the root of the jar file which bundles this application so that I can read it from the ClassLoader (classpath). Every time I've exported it, the unit test runs perfect on my Mac, on Windows, they bomb and throw that exception. The binary file is not changed from one environment to the other. I've even removed CVS out of the potential culprits and transfer just the pkcs12 file from computer to computer with a USB thumb drive. Still the same result.

I've also tried exporting the digital id into a pkcs12 file from Windows/Firefox on my Windows machine and running my junit tests against that file and I still get the same result.

Could it have anything to do with the versions of the JDK? That seems to be the only variable between the two environments. Same code and same exact pkcs12 file.

Thank you for your reply.

wb138834a at 2007-7-29 18:36:46 > top of Java-index,Security,Other Security APIs, Tools, and Issues...