Java JRE Mixed Code Security, starting with JRE 1.6.0_19 and on
Initially around 2010 a main jar Java Applet was implemented, build, and deploy using JDK/JRE 1.6.0_12; the main jar and third party jars were signed, everything work fine. The main jar java applet and third party jars work fine with JRE 1.6.0_12 thru JRE 1.6.0_18.
However, with the introduction of the Mixed Code security starting with JRE 1.6.0_19, the main jar will not launch with JRE 11.6.0_27 unless the Mixed Code security is disable.We are moving our JRE from 1.6.0_12 to update 27. I am trying to fix this problem, that is, to allow the signed main jar Java applet and the signed third party jars to launch when the Mixed Code security is enable.
I have a main jar that has the Java Applet source code and several third party jars that are use by the main jar; for instance, activation.jar, log4j-1.2.13.jar, ojdbc14.jar, etc.
Using keytool.exe in JDK 1.6.0_27 I created a new keystore that has the private/public key pair for the Java applet. Using jarsigner.exe in JDK 1.6.0_27 I signed the main jar and all the third party jars with the private key successfully; each jar has a signature file .SF and a signature block file .DSA (Digital Signature Algorithm). I exported the public key to be use to verify the signed jars.
The Java Applet and the third party jars are in a web apps' webcontent/applet directory, when the applet is launch using the web app, the main jar and the third party jar are downloaded into the user's computer. The digital signature part works fine, the Java applet is able to launch and work successfully when the JRE Mixed Code security is disable. This still does not solved the Mixed Code security when is enable.
I tried by deploying the main jar as Trusted-Only and Trusted-Library. In both situations when the Mixed Code security is enable, the main jar Java Applets is not able to launch, I get different exceptions but same results.
Trusted-Only :: Mixed Code Enable
.........................
cache: Mark prevalidated: http://hostname:port/path/main.jar true tm=numbers cert=numbers
security: http://hostname:port/path/main.jar is newly asserting Trusted-Only
basic: Plugin2ClassLoader.getPermissions CeilingPolicy allPerms
security: Validate the certificate chain using CertPath API
security: The certificate hasnt been expired, no need to check timestamping info
security: Cannot find jurisdiction list file
security: The CRL support is disabled
security: The OCSP support is disabled
security: This OCSP End Entity validation is disabled
security: Checking if certificate is in Deployment denied certificate store
security: Checking if certificate is in Deployment permanent certificate store
basic: Embedding dialogs not enabled in Configuration
basic: Plugin2ClassLoader.getPermissions CeilingPolicy allPerms
.........................
.........................
network: Cache entry not found [url: http://hostname:port/path/StatLib.jar, version: null]
network: Connecting http://hostname:port/path/StatLib.jar with proxy=DIRECT
network: Connecting http://hostname:port/ with proxy=DIRECT
network: Connecting http://hostname:port/path/StatLib.jar with cookie "CheckboxChecked=Y; JSESSIONID=j_session_id"
network: CleanupThread used 1 us
network: Downloading resource: http://hostname:port/path/StatLib.jar
Content-Length: 62,219
Content-Encoding: null
network: Wrote URL http://hostname:port/path/StatLib.jar to File C:\path\LocalLow\Sun\Java\Deployment\cache\6.0\24\167b0298-1365f142-temp
security: Trusted libraries list file not found
cache: Create from verifier: JarSigningData{hasOnlySignedEntries=true, hasSingleCodeSource=true, hasMissingSignedEntries=false}
cache: Adding MemoryCache entry: http://hostname:port/path/StatLib.jar
basic: Plugin2ClassLoader.isTrustedByPolicy called
basic: Plugin2ClassLoader.isTrustedByPolicy returns false
security: resource name "com/name/statistics/lib/I_Dispatch.class" in http://hostname:port/path/StatLib.jar : java.lang.SecurityException: Trusted-Only loader attempted to load sandboxed resource from http://hostname:port/path/StatLib.jar
04/01/2013 16:58:41,588 - [FATAL Thread-15 com.lfg.name.JavaObjectName.init(JavaName.java:193)] - Error in Method() java.lang.SecurityException: Trusted-Only loader attempted to load sandboxed resource from http://hostname:port/path/StatLib.jar
at com.sun.deploy.security.CPCallbackHandler$ParentCallback.check(Unknown Source)
at com.sun.deploy.security.CPCallbackHandler$ParentCallback.access$1500(Unknown Source)
at com.sun.deploy.security.CPCallbackHandler$ChildElement.checkResource(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.checkResource(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.defineClassHelper(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.access$100(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
.... Java Applet is calling and loading a class in a third party jar that I signed but for some reason is been treated as unsigned ....
.......................
network: Cache entry not found [url: http://hostname:port/path/ojdbc14.jar, version: null]
network: Connecting http://hostname:port/path/ojdbc14.jar with proxy=DIRECT
network: Connecting http://hostname:port/ with proxy=DIRECT
network: Connecting http://hostname:port/path/ojdbc14.jar with cookie "CheckboxChecked=Y; JSESSIONID=j_session_id"
network: CleanupThread used 1 us
network: Downloading resource: http://hostname:port/path/ojdbc14.jar
Content-Length: 1,448,790
Content-Encoding: null
network: Wrote URL http://hostname:port/path/ojdbc14.jar to File C:\path\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\51\534fe7f3-21a4d4ae-temp
security: Trusted libraries list file not found
cache: Create from verifier: JarSigningData{hasOnlySignedEntries=true, hasSingleCodeSource=true, hasMissingSignedEntries=false}
network: CleanupThread used 1 us
cache: Adding MemoryCache entry: http://hostname:port/path/ojdbc14.jar
basic: Plugin2ClassLoader.isTrustedByPolicy called
basic: Plugin2ClassLoader.isTrustedByPolicy returns false
security: resource name "oracle/jdbc/driver/OracleDriver.class" in http://hostname:port/path/ojdbc14.jar : java.lang.SecurityException: Trusted-Only loader attempted to load sandboxed resource from http://hostname:port/path/ojdbc14.jar
java.lang.SecurityException: Trusted-Only loader attempted to load sandboxed resource from http://hostname:port/path/ojdbc14.jar
at com.sun.deploy.security.CPCallbackHandler$ParentCallback.check(Unknown Source)
at com.sun.deploy.security.CPCallbackHandler$ParentCallback.access$1500(Unknown Source)
at com.sun.deploy.security.CPCallbackHandler$ChildElement.checkResource(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.checkResource(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
..... java applet is loaded a java class in a third party jar that was signed, but is been treated as untrusted.....
Trusted-Library :: Mixed Code Enable
..............................
cache: Mark prevalidated: http://hostname:port/path/main.jar true tm=numbers cert=numbers
basic: Plugin2ClassLoader.getPermissions CeilingPolicy allPerms
security: Validate the certificate chain using CertPath API
security: The certificate hasnt been expired, no need to check timestamping info
security: Cannot find jurisdiction list file
security: The CRL support is disabled
security: The OCSP support is disabled
security: This OCSP End Entity validation is disabled
security: Checking if certificate is in Deployment denied certificate store
security: Checking if certificate is in Deployment permanent certificate store
basic: Embedding dialogs not enabled in Configuration
basic: exception: java.lang.NoClassDefFoundError: org/apache/log4j/Logger.
java.lang.RuntimeException: java.lang.NoClassDefFoundError: org/apache/log4j/Logger
at com.sun.deploy.uitoolkit.impl.awt.AWTAppletAdapter.instantiateApplet(Unknown Source)
at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Logger
at com.path.MainClassApplet.init(MainClassApplet.java:line_number)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance0(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at com.sun.deploy.uitoolkit.impl.awt.AWTAppletAdapter$1.run(Unknown Source)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$200(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue$4.run(Unknown Source)
at java.awt.EventQueue$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Logger
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
... 27 more
Ignored exception: java.lang.RuntimeException: java.lang.NoClassDefFoundError: org/apache/log4j/Logger
basic: Dialog type is not candidate for embedding
basic: Removed progress listener: sun.plugin.util.ProgressMonitorAdapter#40ab5b6c
security: Reset deny session certificate store
The main jar applet (Rich Internet Application) is call using JavaScript code in a JavaServer Pages file (HTML page) with the html tag.
It is my understanding that JavaScript code is treated like unsigned code. When a signed applet is accessed from JavaScript code in an HTML page, the signed applet is executed within the security sandbox. This implies that the signed applet essentially behaves like an unsigned applet.
I am debating if I should use JNLP with the Deployment Tookit (deployJava.js) to deploy the applet or if I should add classes to the main JAR file's class-path in the main JAR file's manifest file; whose manifest references a different JAR file (or several different JAR files) that serve as utilities for the purposes of my applet.
Any idea on how to resolved this Mixed Code issue?
Please advise, thanks.
I can confirm the problem is with recent JRE. Calling from JS to Java will give you a "Mixed Code Warning". No matter how you sign or which library you include or not.
So the above comment is not true or not true anymore (after latest JRE upgrade, I'm working with 1.7.0_21).
But luckily it is still permitted to call from java do javascript without problems so the solution we came into for this kind of problem is to implement a commad queue that's being polled from the applet, like the following :
1) wrap each invocation to applet method in an "request object" and put it in a queue, for example:
var jobQueue = [];
function hello(message) {
request = {
cmd:"hello",
arg:"Jack",
callback:function(result) {
alert("I'm saying "+result);
}
}
jobQueue.push(request);
}
2) Create a method to be called from the applet to get a job:
function fetchJob(){
if (jobQueue.length>0) {
return jobQueue.shift();
}
}
3) When the applet starts, spawn a thread or a timer that will call the function fetchJob every X milliseconds. When the function returns a non null request, the applet can execute. The request can carry (like in the above example) even a callback to be called to return a result
That's all. But Beware : if you use a callback to return result beware not to return anything apart from native object or you will end up again with the mixed code warning. Even an array of string won't work. If you need to create a more complex result you need to call back to javascript using liveconnect API and create a native JS Object from Java Applet and then call the callback using that.
Good Luck!
Related
When using Java 8 update 162 and older in Internet Explorer, the applet loads and works as expected. When removing Java 8 update 162 and install Java 8 update 171 or 172, the applet errors with ClassNotFoundException referencing the class listed in the code attribute of the applet tag. I don't see any reason for this in the 171 or 172 release notes or the 171 or 172 bug fixes. I'm using Windows 10 Pro version 1709 build 16299.371. The applet is signed with a certificate that is trusted and still valid. There aren't any exceptions in the Exception Site List and adding an exception for this site (it worked fine without one on Java 8u162) still displays the exception. Using Java 8 update 162 and older is still working on another PC.
When clearing the Application cache in the Java configuration, the applet's JAR file doesn't appear again in the cache.
Are you aware of any changes in Java 8u171 or 172 that affect applets? Do you have any suggestions to resolve this?
Update 1: I'm aware that applets are deprecated in Java 9 and that applets don't work in Firefox and Chrome, but this is in Internet Explorer.
Update 2: I'm also aware that the 3DES Cipher Suites have been disabled in the update to 171 and 172, but the current digest algorithm is SHA-256 and the signature algorithm is SHA256withRSA with a 2048-bit key, which matches the signing certificate's signature algorithm and key. I've even tried signing the applet using Java 8 Update 172 without altering java.security to remove 3DES_EDE_CBC and using that version the ClassNotFoundException still persists as expected.
Update 3: When using Fiddler 4 or Charles as a proxy for Internet Explorer and capturing traffic between the server and the browser, the applet loads and works as expected. Both the Java SE Runtime Environment 8 Update 172 and Java Plug-in 11.172.2 Add-ons are set to Allow on all sites. When I clear the applet from the Resources cache using the Java Cache Viewer in the Java Control Panel, the applet doesn't download in the cache again without the proxy, but if I use a proxy again then it does download into the cache. My guess is that the proxy traffic is being treated as local and so has different permissions. Any other ideas or what permissions it could be?
Update 4: Enabling the debugging options in the Java Control Panel causes the full stack trace to show, where CODE_ATTRIBUTE_VALUE is the value I set on the code attribute of the applet tag. The applet's JAR file doesn't seem to be downloading even though I list it in the archive attribute.
java.lang.ClassNotFoundException: CODE_ATTRIBUTE_VALUE
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
The Java Console now also shows more details about the connection and I see the following which is the cause:
javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(Unknown Source)
at sun.plugin.PluginURLJarFileCallBack.connect(Unknown Source)
at sun.plugin.PluginURLJarFileCallBack.retrieve(Unknown Source)
at sun.net.www.protocol.jar.URLJarFile.retrieve(Unknown Source)
at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source)
at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source)
at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source)
at sun.plugin.net.protocol.jar.CachedJarURLConnection.connect(Unknown Source)
at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFileInternal(Unknown Source)
at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.getJarFile(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.access$900(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.ensureOpen(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.<init>(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at sun.security.ssl.InputRecord.read(Unknown Source)
... 40 more
Currently the applet is hosted on Windows Server 2003 using IIS. Moving it to Windows Server 2008 also using IIS causes that problem to go away. Mr. Laitinen was right the TLS connection was using 3DES_EDE_CBC.
JAVA_HOME\lib\security\java.security
Update 171 adds 3DES_EDE_CBC to the list of disabled algorithms (jdk.tls.disabledAlgorithms). Remove it and your applet will work again.
Faced the same issue and it comes down to Update 171 no longer supporting TLS 1.0.
Our webserver was old and only supported TLS 1.0 so the download of the Applet was failing and this could be seen in the Java Console, the connection was being closed.
Upgraded the webserver to support TLS 1.2 and it all works again.
I'm trying to run a java JNLP-based application.
It works fine from home : javac+javaws are the same v.1.8.?
Now I'm trying to run my application at work. I'm working behind a proxy and I used the Controlpanel to tell java to bypass the proxy for our local server hosting the JNLP.
On the server side, the aplication is compiled with
javac 1.7.0_60
On the client side, I'm trying to run it with:
$ javaws -version
Java(TM) Web Start 11.40.2.26-fcs
$ java -version
java version "1.8.0_40"
Nevertheless, I get the following exception in javaws
javax.net.ssl.SSLHandshakeException: com.sun.deploy.security.RevocationChecker$StatusUnknownException
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1937)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1478)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:212)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:969)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:904)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1050)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1363)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1391)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1375)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1512)
at sun.net.www.protocol.http.HttpURLConnection.access$200(HttpURLConnection.java:90)
at sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1432)
at sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1430)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessController.doPrivileged(AccessController.java:713)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1429)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
at com.sun.deploy.net.HttpUtils.followRedirects(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doGetRequestEX(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.checkUpdateAvailable(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.isUpdateAvailable(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.javaws.Launcher.updateFinalLaunchDesc(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main.access$000(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Thread.java:745)
Caused by: com.sun.deploy.security.RevocationChecker$StatusUnknownException
at com.sun.deploy.security.RevocationChecker.checkCRLs(Unknown Source)
at com.sun.deploy.security.RevocationChecker.check(Unknown Source)
at com.sun.deploy.security.RevocationCheckHelper.doRevocationCheck(Unknown Source)
at com.sun.deploy.security.RevocationCheckHelper.doRevocationCheck(Unknown Source)
at com.sun.deploy.security.RevocationCheckHelper.checkRevocationStatus(Unknown Source)
at com.sun.deploy.security.X509TrustManagerDelegate.checkTrusted(Unknown Source)
at com.sun.deploy.security.X509Extended7DeployTrustManagerDelegate.checkServerTrusted(Unknown Source)
at com.sun.deploy.security.X509Extended7DeployTrustManager.checkServerTrusted(Unknown Source)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1460)
... 33 more
I read https://community.oracle.com/thread/3651870?start=15&tstart=0
But I don't really understand what I should do.
For example, I've commented out <>/lib/security/java.security
#jdk.tls.disabledAlgorithms=SSLv3
but that still doesn't work. As I see a 'getInputStream' in the stacktrace, I wonder if javaws tries to download something outside the proxy ?
Any idea ?
EDIT: the JNLP works if,in the controlPanel, I check
Perform signed code: do not check (not recommended)
Perform TLS certificatie revocation: do not check (not recommended)
is this problem linked to my proxy server ?
Java certificate revocation checking uses one or both of these methods:
Certificate Revocations Lists (CRLs)
This method needs lists to be generated and published periodically by Certificate Authority (CA) to keep the it current.
Online Certificate Status Protocol (OCSP)
This method performs a real time certificate status check with CA making it more reliable and faster.
If your server certificate is self-signed, or your company has an internal CA, your JRE may not be able to complete the revocation check properly -- hence the "Unknown" status. If you want to run with revocation checking on (and usually you do), you will need certs signed by a CA that supports one or both of these methods.
It is also important to remember that there are potentially two certificates in play here:
The cert used to sign the JARs; and
The cert used to connect to the server
Both certs must be signed and valid (that is, not revoked) in order for the handshake to succeed.
We have a secured server (RSL) where my applet gets some errors (it worked well on other, less restrictive servers). I found java security signing so complicated; from version to version, from PC to PC etc. In one word, after researching for almost a week+ I came to a point where I cant seam I can move forward anymore.
What this applet does is simply uploads a local file to application FTP site. My users hate default INPUT control to browse a file, location of which is defined so, I made this applet simply to upload that defined file to this FTP site (this original project was done w/ classic asp some years ago; this is an upgrade per client request).
This java project uses apache FTPClient library and my package includes commons-net-3.3.jar (also few dependencies: ant-apache-oro.jar, ant-commons-net.jar and jakarta-oro-2.0.8.jar). There is absolutely no issue when I run this applet on my PC (eclipse). However problems start when I run the applet on production site (on that restrictive server). Here is how I sign and compile my jar.
START
My MANIFEST.MF file content:
Manifest-Version: 1.0
Class-Path: commons-net-3.3.jar
Permissions: all-permissions
Trusted-Library: true
Created-By: 1.8.0_31 (company)
My .java.policy file content:
/* AUTOMATICALLY GENERATED ON Thu Feb 19 13:51:28 PST 2015*/
/* DO NOT EDIT */
keystore "JavaFileUploader.keystore";
grant {
permission java.security.AllPermission;
};
...and this is how I sign and compile my classes:
keytool -genkey -alias JavaFileUploader -validity 1500 -keystore JavaFileUploader.ks
keytool -selfcert -keystore JavaFileUploader.ks -alias JavaFileUploader -validity 1500
javac JavaFileUploader.java
javac LinLyn.java
javac FTPUpload.java
jar cvfm JavaFileUploader.jar MANIFEST.MF *.class .java.policy JavaFileUploader.ks JavaFileUploader.txt
jarsigner -keystore JavaFileUploader.ks JavaFileUploader.jar JavaFileUploader
END
At the end I collect all my jar files (total of five: 4 already listed above and one-mine; JavaFileUploader.jar) and placed on the same directory where my asp pages are.
Right now this is what I'm getting from java console that bothers me and I think this is where all errors are hidden.
A. When my applet appears - java console shows this suspicious messages (ips are changed):
...
cache: Read manifest for http://11.11.111.11/APPNAME/JavaFileUploader.jar: read=423 full=423
Missing Permissions manifest attribute in main jar: http://11.11.111.11/APPNAME/JavaFileUploader.jar
security: Missing Codebase manifest attribute for: http://11.11.111.11/APPNAME/JavaFileUploader.jar
security: Missing Application-Library-Allowable-Codebase manifest attribute for: http://11.11.111.11/APPNAME/JavaFileUploader.jar
...
B. ...then, after I attempt to upload the file java console show this:
...
network: Connecting http://11.11.111.11:21/crossdomain.xml with proxy=DIRECT
network: Connecting http://11.11.111.11:21/ with proxy=DIRECT
network: Connecting http://11.11.111.11:21/crossdomain.xml with cookie "ABCDEFGHIJKLMN=QRSTUVWXYZ; LAID=1"
java.io.IOException: Invalid Http response
...
C. ...then few lines below, this:
...
java.security.AccessControlException: access denied ("java.net.SocketPermission" "11.11.111.11:21" "connect,resolve")
...
I have no clue why java reports "Missing Permissions manifest attribute in main jar" in the first place when I have "Permissions: all-permissions" set on my MANIFEST.MF file. Same for other "missing" attributes...(section A)
On my second section of errors (section B) I'm guessing that crossdomain.xml file not found. Otherwise I don't see anything that clould generate IOException. "Invalid Http response" is the further result from IOException error I guess.
On my third section of errors (section C) I have no clue whatsoever, because other errors above could drain and end up errors to complete irrelevant point.
Please let me know if you had this kind of problem and have a solution.
Thanks.
Here is the full content of the java console right after the applet appears:
Java Plug-in 11.45.2.15
Using JRE version 1.8.0_45-b15 Java HotSpot(TM) Client VM
User home directory = C:\Users\MY_USER_NAME
----------------------------------------------------
c: clear console window
f: finalize objects on finalization queue
g: garbage collect
h: display this help message
l: dump classloader list
m: print memory usage
o: trigger logging
q: hide console
r: reload policy configuration
s: dump system and deployment properties
t: dump thread list
v: dump thread stack
x: clear classloader cache
0-5: set trace level to <n>
----------------------------------------------------
basic: Added progress listener: sun.plugin.util.ProgressMonitorAdapter#1b1e125
security: Expected Main URL: http://11.11.111.11/APPNAME/JavaFileUploader.jar
basic: Plugin2ClassLoader.addURL parent called for http://11.11.111.11/APPNAME/JavaFileUploader.jar
Missing Permissions manifest attribute in main jar: http://11.11.111.11/APPNAME/JavaFileUploader.jar
security: Missing Codebase manifest attribute for: http://11.11.111.11/APPNAME/JavaFileUploader.jar
security: Missing Application-Library-Allowable-Codebase manifest attribute for: http://11.11.111.11/APPNAME/JavaFileUploader.jar
security: Validate the certificate chain using CertPath API
security: SSV validation:
running: 1.8.0_45
requested: null
range: null
javaVersionParam: null
Rule Set version: null
network: Created version ID: 1.8.0.45
network: Created version ID: 1.8.0.45
security: continue with running version
network: Created version ID: 1.8.0.45
network: Created version ID: 1.8
network: Created version ID: 8.0.45
security: Missing Codebase manifest attribute for:
http://11.11.111.11/APPNAME/JavaFileUploader.jar
security: Missing Application-Library-Allowable-Codebase manifest attribute for: http://11.11.111.11/APPNAME/JavaFileUploader.jar
security: Validate the certificate chain using CertPath API
basic: Applet loaded.
basic: Applet resized and added to parent container
basic: PERF: AppletExecutionRunnable - applet.init() BEGIN ; jvmLaunch dt 549750 us, pluginInit dt 7116411154 us, TotalTime: 7116960904 us
basic: Applet initialized
basic: Starting applet
basic: completed perf rollup
basic: Applet made visible
basic: Applet started
basic: Told clients applet is started
Here are addition messages on java console right after I apply my upload method:
java.security.AccessControlException: access denied ("java.net.SocketPermission" "11.11.111.11:21" "connect,resolve")
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkConnect(Unknown Source)
at sun.plugin2.applet.SecurityManagerHelper.checkConnectHelper(Unknown Source)
at sun.plugin2.applet.AWTAppletSecurityManager.checkConnect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at org.apache.commons.net.SocketClient.connect(SocketClient.java:182)
at org.apache.commons.net.SocketClient.connect(SocketClient.java:203)
at org.apache.commons.net.SocketClient.connect(SocketClient.java:296)
at FTPUpload.<init>(FTPUpload.java:21)
at JavaFileUploader.uploadWithFlexibleConnection(JavaFileUploader.java:311)
at JavaFileUploader.saveFileContent(JavaFileUploader.java:339)
at JavaFileUploader.actionPerformed(JavaFileUploader.java:531)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$500(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue$4.run(Unknown Source)
at java.awt.EventQueue$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
OK. One error is gone. I've created an xml file, called 'crossdomain.xml' with following content:`
<?xml version="1.0" ?>
<cross-domain-policy>
<site-control permitted-cross-domain-policies="master-only"/>
<allow-access-from domain="*"/>
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>
Error described on section B is gone.
Posted full content of java console messages are the most recent error messages. You can see my "suspected errors;" described as A (line 4 on the 1st part) and C (very 1st line in the 2nd part).
It's a good practice to sign all the .JARs (depedencies as well)
Try to include all the information below in your manifest:
<codebase>http://location.of.your.jar/</codebase>
<permissions>all-permissions</permissions>
<Application-Library-Allowable-Codebase>http://location.of.your.jar/</Application-Library-Allowable-Codebase>
<Manifest-Version>1.0</Manifest-Version>
<Implementation-Title>App Name</Implementation-Title>
<Implementation-Version>0.1.0</Implementation-Version>
<Application-Name></Application-Name>
<Created-By>1.8.0_45</Created-By>
<Main-Class>package.YourClass</Main-Class>
<mode>development (or production)</mode>
<url>url of the application</url>
Sorry to answer this as an 'answer' but I can't put comments. I'm currently working on an applet and this approach has worked fine.
After upgrading to Java 7, when launching remote jnlp, I see the following exception in the Java console:
java.security.KeyStoreException: WIExplorerMy not found
at java.security.KeyStore.getInstance(Unknown Source)
at com.sun.deploy.services.WPlatformService$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.services.WPlatformService.getBrowserClientAuthKeyStore(Unknown Source)
at sun.plugin2.applet.context.InitialJNLPExecutionContext.getBrowserClientAuthKeyStore(Unknown Source)
at sun.plugin2.main.client.DisconnectedExecutionContext.getBrowserClientAuthKeyStore(Unknown Source)
at sun.plugin2.applet.Applet2BrowserService.getBrowserClientAuthKeyStore(Unknown Source)
at com.sun.deploy.security.X509DeployKeyManager.<init>(Unknown Source)
at com.sun.deploy.net.protocol.https.Handler$Initializer$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.net.protocol.https.Handler$Initializer.<clinit>(Unknown Source)
at com.sun.deploy.net.protocol.https.Handler.openConnection(Unknown Source)
at java.net.URL.openConnection(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.createUrlConnection(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doGetRequestEX(Unknown Source)
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.security.NoSuchAlgorithmException: WIExplorerMy KeyStore not available
at sun.security.jca.GetInstance.getInstance(Unknown Source)
at java.security.Security.getImpl(Unknown Source)
... 26 more
In addition the error screen saying "Error. Click for details" appears for about 2 seconds and disappears afterwards.
Other then that, everything seems to function normally.
With Java 6 everything works as expected.
Ideas how to fix it?
I think some of the latest Java 7 updates have obsoleted some encryption schemes, so that would be a completely normal exception to get if you were using one of these while using Java 6.
See this list of enhancements and changes for Java 7:
Weak cipher suites deprecated
Per RFC 4346, RFC 5246, and RFC 5469, some cipher suites have been made obsolete and should not be used. These obsolete suites are all disabled by default in SunJSSE. For details, consult the cipher suite lists in the documentation about the SunJSSE provider.
That being said, that would explain the NoSuchAlgorithmException, but the error message seems to mention something about a missing keystore, so this may be unrelated and we woud need you to provide a SSCCE or anything close enough to one.
I solved this problem by adding
security.provider.11=com.sun.deploy.security.MSCryptoProvider
to C:\Program Files\Java\jre1.8.0_31\lib\security\java.security
Although the error wasn't fatal for me, it is just the javaws trying to read the local browser key store before falling back to the java keystores that are managed by the control panel. Those files are in C:\Users\USERID\AppData\LocalLow\Sun\Java\Deployment\security
Interestingly there is a security provider that comes pre-wired into the java.security file, and it is
security.provider.10=sun.security.mscapi.SunMSCAPI
This provider can also read the browser keystore, but the store type is windows-my, and not WIExplorerMy
Tarlog, do you have any resolution found yet? I have the same problem, I am suspecting that the first problem with KeyStoreException exception only happens if you are trying secure connection. And that sinister "Error. Click for details" issue happens on any Applet loaded through an jnlp.
I could not find any resolution yet.
Edit: For the KeyStoreException I have realised that the problem occured due to apache certificate files were gone somehow. I have generated ceritificate files and restarted apache. The exception no longer occurs.
The other problem with Error window still exists.
With regard to the Error Click for details issue – I resolved this by adding a class to the source that implements javax.jnlp.DownloadServiceListener (can just be a dummy class) and then specifying that class in your jnlp file (applet-desc/#progress-class="YourClass")
I would like to use this applet this applet in a html document. In the example on this site they use :
<applet code="de.wim.outldd.examples.DragDropTest_Applet"
width="150" height="150" alt="Applet1" archive="soutldd.jar">
</applet>
It does not work when I try it. My HTML document is in the middle of the extracted directory. How can I use the applet in html, somebody please try this.
THe error in the console
java.lang.RuntimeException: java.lang.ExceptionInInitializerError
at sun.plugin2.applet.Plugin2Manager.createApplet(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ExceptionInInitializerError
at de.wim.outldd.OutlookDD.init(OutlookDD.java:73)
at de.wim.outldd.examples.DragDropTest_Applet$1.run(DragDropTest_Applet.java:29)
at java.security.AccessController.doPrivileged(Native Method)
at de.wim.outldd.examples.DragDropTest_Applet.<init>(DragDropTest_Applet.java:26)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance0(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$12.run(Unknown Source)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.security.AccessControlException: access denied (java.util.PropertyPermission java.io.tmpdir read)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
at java.lang.System.getProperty(Unknown Source)
at de.wim.outldd.OutlDDNativeLib.loadDllFromResource(OutlDDNativeLib.java:135)
at de.wim.outldd.OutlDDNativeLib.loadDll(OutlDDNativeLib.java:104)
at de.wim.outldd.OutlDDNativeLib.<clinit>(OutlDDNativeLib.java:62)
... 19 more
Exception: java.lang.RuntimeException: java.lang.ExceptionInInitializerError
Your applet is trying to read the temp directory value from the java.io.tmpdir system property which is previleged. Applets run in a sandbox environment with restricted permissions beacause of security reasons. To fix it, override the default security policy to allow your applet to read the property by setting the property permission - java.util.PropertyPermission, on the property. To override default permissions define the policy in your user home's .java.policy file. It is recommended that you edit your user specific policy file and not the global policy file under your JRE security directory. Refer the template below:
grant codeBase "<code base>" {
permission <type> "<target>", "<actions>";
permission <type> "<target>", "<actions>";
...
};
For eg.
grant codeBase "http://geosim.cs.vt.edu/geosim/-" {
permission java.util.PropertyPermission "java.io.tmpdir", "read";
...
};
Edited:
I noticed that you already have the applet link specified in your post at the top. So, I am giving a step by step guide to get you started.
Here you go -
Copy $JRE_HOME/lib/security/java.policy file to your user home (on windows it is c:\users\< user name>) as .java.policy file. Please note the preceding "." in the file name.
Add the following lines to the end of .java.policy file:
grant codeBase "http://www.wilutions.com/outldd/-" {
permission java.security.AllPermission;
};
Run the applet in an appletviewer as follows and see if it works.
appletviewer http://www.wilutions.com/outldd/example.html
Please note that I am specifying all permissions to the applet for sake the of geting you started but it is potentially insecure to grant all permmissions. You should grant only the required permissions. So, I leave it to you to figure it out.
Have you followed the guide found here and are you sure the specified paths are correct in relation to your directory/html page?
Also what about applet JAR file soutldd.jar path is this correct?
go to Java preferences->advance and turn Java console on so that you can see what is happening on loading your applet in HTML.
in windows
java preferences: control panel -> java