I've been quite happily signing my jar files for a year or so and had no issues whatsoever, but very recently I have noticed that I'm getting the warning below.
Now, nothing has changed, I'm not creating anything different, my certificate is valid, I'm signing in exact same way, same JDK and same JRE and I'm uploading to the same location and so on so kind of hitting a wall.
I've tried running from a different computer, different OS and JRE, all with same outcome.
What I have also noted though and find this particularly strange, is that even if I add a site exception, I still get the same error.
Are there any logs or can such logging be enabled to find out exactly why the applications are not being allowed to run?
My issue was caused by mismatched information in the manifest file inside the jar and the jnlp file, my own oversight as it happens. The CODEBASE and PERMISSIONS differed, not quite sure how that happened but guess it makes sense for java security to not allow such an application to run with said differing information.
Related
I am downloading a java web start app from the web, and using the jnlp file to run it in my MAC OS. But the application does not start and gives me the following error.
Now, I have read a lot about this error here and how to sign the application here and other places. Plus I have read about the security update which started this error here.
All these articles and answers give the impression that this error can only occur due to the application being from an unidentified developer.
I just wanted to confirm whether that is the case, or can there be some other reason behind this, like expired code signing cert, or a self signed cert?
If there can be multiple reasons for this error, how to find out which one it is?
I am having a problem with getting a ruleset.xml file to function as expected. I am using a Windows 10 client for testing and to keep things simple, i'm trying to get http://javatester.org/version.html to use version 1.8.0_92 as specified within my ruleset.xml file (below).
Deployment Rule Set - ruleset.xml
There are two versions of JRE installed on my machine i.e. 1.6.0_25 as well as that already mentioned above. Unfortunately, when i browse to the above URL, the instance reported is the 1.6.0_25 version which is not what i want.
In terms of the DeploymentRuleSet.jar file, as you can see this is valid and i have appropriately signed the certificate etc. Additionally, if i remove some essential content from the ruleset.xml file then the DeploymentRuleSet.jar becomes invalid which further suggests that up to the point of reading the file everything is OK...i just can't seem to figure out why this isn't applying. In fact, i've even tried blocking everything by default yet this also doesn't work...Any help and suggestions would be much appreciated.
Thank you!
I managed to figure this out.
The short answer is that I had two different versions of Java running, however one of those versions was x64 whereas the other version was (obviously) an x86 version. The DeploymentRuleSet.xml was working as expected however the x64 version was not firing. It wasn't firing because because i needed to add the site in question into the 'Trusted Sites'. This was due to the enhanced restrictions within IE and come as a result of the 'Enhanced Protection Mode' and 'Enhanced Protection Mode for 64 bit Processes' (i believe it comes under this from the top of my head). Adding the sites in question to the Trusted Sites is not a security issue (for us)given these are national systems we know and use.
i have noticed that signed applets are loaded much slower with the latest plugin (included in java 8u31 and 7u75). I have debugged the situation quite a lot and i found out that the problem is directly related to the size of the jar files that are referenced in the jnlp file. The problem is that each time the applet starts, there is some 're-indexing' of the cached jar files that takes time.
To reproduce the issue i did this:
I created a minimal applet and in the jnlp file i used to deploy it, I added several irrelevant .jar files (that are not even referenced, so the classloader does not load them) of considerable size (e.g. 30MB). Of course i am using versioning in the jnlp and capture all http traffic to make sure that the delays are not because of traffic (either re-downloading or certificate revocation checks, etc). I run the applet with the trace enabled and then went through the xml trace log file and found out where the delays come: they are always from the JarSigningVerifier ....
Has anyone else seen something like that?
It is very easy to see and reproduce this behavior and i wonder if there is something i am overlooking. Having worked on applets for the past years extensively, i am totally lost at what can be happening. I can verify that reverting to the previous version of the plugin (and every other version before) works as expected.
I have submitted a bug report with oracle, but i haven't heard back still. Any info or idea will help,
TIA
Same here. I thought already I'm getting crazy. Thanks for sharing this.
We are using Java Web Start, but it's sharing the same problem of re-indexing all jar files (in our case it's an app with quite some jars, so starting takes ages).
Aside from the fact that Oracle suddenly decided to check the certificate of the deploy TLS, which caused some hickup on Linux and Macs (we used a StartSSL certificate there, which isn't included in the Java keystore - on Windows it works as it uses the platforms root certs, too).
And, to make it even worse, on Windows x86 the 8u31 silently dies if -XX:+DoEscapeAnalysis or -XX:+OptimizeStringConcat is present in the JVM arguments, though both parameters are standard in Java 8 (but not in 7, that's why they've been included, still). The 64bit engine doesn't have that problem.
The next thing they changed is they now overwrite the start icons if they've been changed (we changed them to put the 64bit engine's path in there), so it stubbornly changes the path back to the 32bit engine every time.
The behaviour of Oracle is not helpful at all, as they didn't announce any of these changes in their changelogs, let alone announcing the certs changes a few days ahead.
I would like to hear from anyone who's sharing the problems and possible workarounds.
Patric
Have you been able to solve this issue? Have you had a reaction from Oracle?
UPDATE START
I've tried everything I can think of and haven't managed to solve the
issue, so I posted my own question on this issue.
A similar bug report can be found here and is backported to at
least Java 8u51 which I tested. Yet again they managed to increase
startup time for our application.
END UPDATE
We are using Java Web Start for an Eclipse RCP-based application with jars that are all signed.
Startup time is 8s within the IDE, Java version doesn't seem to matter here. With web start the story is different. It becomes (much) worse with every Java update:
7u?? (<60): +2s (10s)
7u60: +5s (13s)
7u75: +15s (23s)
8u31: +12s (20s)
8u40: +21s (29s)
8u51: +23s (31s)
Have you tried your jnlp without versioning? In my experience Java jnlp is very buggy specially if you change the jnlp default values. Versioning support is disabled by support, so try it without versioning and see if it still slow?
For me, I noticed some bugs when I used update="background" value, so I no longer change the default update method. My theory is that Oracle only tests jnlp against default values before they release new Java versions.
One of the bigger software packages I maintain is deployed via JNLP. Lately we're running into a lot of issues with it. I had a previous Stackoverflow question due to it not allowing MD5 hashes to be done. Another major issue is that sockets get blocked sometimes. Some of our manual code is fine, some that looks otherwise identical is intermittent, and some of the included libraris (EWS for updating our Exchange calendars) fails everytime when launched via JNLP (but works every time if the JAR is run off a local copy).
How can I fix the security so that everything works via JNLP just like it was a local copy?
Newer versions of JNLP have changed parameter passing restrictions for security reasons. I was able to eventually get everything required in place and migrate back to JNLP.
This is really driving me crazy. No matter what I do, it seems that Mirth (1.8.2) is running an older version of my JAR file; I know because of various signs, like:
I can't call any functions
Information logged is not showing up in the logs
Changed log messages are not changed in the log files
Files that were once created and written to in code, but no longer touched by code, are still being created and written
I've tried everything I can think of to make this work. It was working at one point, but now it seems like it's no longer being updated. My process to integrate my changes into Mirth are:
Run an ant script to build the JAR file
Copy the JAR file to \lib\custom
Restart the Mirth service (via Mirth administrator)
I've tried restarting (Mirth service via Services, Java, computer) -- to no avail. I know my JAR file is correct, because I've decompiled it (to make sure it has the latest code) and hashed it (to compare to the hash of the ant-built JAR) -- it is correct and the code is there; it's just not being run.
I'm at wit's end; this occurs infrequently but completely blocks me from developing.
Edit: I also know that my code is correct, because when I run unit tests, it generates the right files and calls the right functions and logs the right information. Only Mirth seems to "not get it."
And my classes are very simple; simple one-argument constructors and a few public methods that return various data. Nothing complex, no nested classes/JARs/dependencies.
Edit: I even deleted my custom JAR file and restarted Mirth, and it's still running my code. Awesome :/ I've added a bounty for this question. I suspect the JAR is cached somewhere (even though they deny it on the Mirth forums) and that cache needs to be cleaned out somehow (although why restarting the Mirth service and my PC doesn't do it is beyond me).
I've also killed all instances of Java (and rebooted my computer), so that makes it highly unlikely that the JVM is caching the JAR somewhere.
I tried reinstalling Mirth. For some reason, it had my custom channel when I booted the administrator for the first time; and infuriatingly, it's still running the old JAR, even though I've updated it with the new one in lib\custom.
I ended up solving this with a combination of actions:
Uninstalling Mirth and Java, and then reinstalling.
I also removed all Java installations except one (one JDK and one JRE).
I stopped Mirth when you copying my JAR. Stop Mirth, copy, and restart; don't try to copy on a live installation. It may or may not pick up your updated JAR depending on if it's loaded into a JVM or not.
This combination of steps seemed to work. Prior to this, I had 3-4 JREs installed (and two JDKs) and I was copying (successfully, according to Windows 7) the JARs while Mirth was running. It's working now!
Mirth is a J2EE application running on a plain old JVM; you have options for debugging it.
You could follow the instructions here for running Mirth Connect via Eclipse. You could then see the JVM classpath, you could set breakpoints and use the debugger.
Mirth is based on the Mule ESB. Mule has its own way of class-loading. You could research it.
If Mirth is really using an old version of your JAR, maybe it's got a cached version around somewhere. Or maybe you made some configuration changes you've forgotten about - perhaps you added a new directory for jars. (Not sure how you do that.)
Mule pays attention to an environment variable named MULE_LIB; maybe that's relevant.
It looks like Mirth Connect 1.8 and Mirth Connect 2.0 have different places for jars (lib/custom and custom-lib, respectively). Which version are you using?