FULL PRODUCT VERSION :
Java 6u71 and 6u75 (customer has Java SE 6 Advanced and Java SE 6 Support)

ADDITIONAL OS VERSION INFORMATION :
Windows 7 64-bit

A DESCRIPTION OF THE PROBLEM :
When our product is deployed as an applet in the browser, we create our own classloader in order to fetch and cache additional jar modules using a proprietary mechanism (which predates the jar index specification).
One of the modules we load is a third-party crypto library implemented as a JCA extension. This library is packaged as a jar file signed by the JCE Code Signing CA and must remain unmodified in order for JCA to authenticate the
provider (per http://docs.oracle.com/javase/7/docs/technotes/guides/security/crypto/HowToImplAProvider.html#Step1a). The provider jar itself also performs self-integrity checking as described later on that same web page.

In order for the crypto jar to be found by itself and by the JCA framework, our classloader defines each class extracted from the jar with a ProtectionDomain whose CodeSource specifies a file URL pointing to the jar
in our private cache directory on the local machine.

Starting in Java 6u71 and also seen in 6u75, JCE is unable to locate the jar in order to authenticate the crypto provider, but only when "Keep temporary files on my computer" is enabled in the Java control panel. This results in any subsequent crypto operations failing.

REGRESSION. Last worked in version 6u45

ADDITIONAL REGRESSION INFORMATION:
Does not occur in 6u45, nor in current versions of Java 7 (tried Java 7u65). Did not try Java 8.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Uh...difficult to create a simple testcase.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Crypto library should be locatable when JCE authenticates the jar using the URL of the CodeSource obtained from the ProtectionDomain of the cipher class being loaded.
ACTUAL -
JCE cannot authenticate the crypto provider due to failure to parse the jar file cached in the private location.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Top of stack traces that appear in Plug-in Java console:

java.lang.SecurityException: JCE cannot authenticate the provider JCRYPTO
at javax.crypto.Cipher.getInstance(DashoA13*..)
at javax.crypto.Cipher.getInstance(DashoA13*..)
...
...
...
Caused by: java.util.jar.JarException: Cannot parse jar:file:/C:/Users/myname/AppData/Local/Temp/private_cache_directory/s14b.999999999!/
at javax.crypto.SunJCE_c.a(DashoA13*..)
at javax.crypto.SunJCE_b.b(DashoA13*..)
at javax.crypto.SunJCE_b.a(DashoA13*..)
...
...
...

(Classes that call Java methods are omitted, and a couple of names of private jar file are changed.)

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Very difficult to provide a simple testcase because of mechanisms used to create secondary classloader and caching system.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Found several workarounds:

- Turn off "Keep temporary files on my computer"
- Upgrade to Java 7u65
- Install crypto jars in system classpath or specify crypto jar in archive attribute of applet tag.

One interesting note is that if you install Java 7u65 alongside 6u75, then in the Java control panel, turn off the Java 7 JRE in order to use the Java 6 version, the problem does not occur even when "Keep temporary files on my computer" is turned off. This seems to indicate that the problem is in the Plug-in rather than the JRE, as the console in this combination shows the newer plug-in with the older JRE.