I am able to run applets that have signed jar files on Internet Explorer with Java 1.7 Update 45.
I am however not able to run applets with unsigned jar files.
I tried clearing the cache.
I have also changed the security java control panel settings to Medium.
I still get the error JarSigningException.
Is there any way I can proceed here?
Are only signed jar files allowed? This looks like a major limitation.
Is there anyway I can tweak some settings to get unsigned applets to load?
Any help is appreciated.
Is there any way I can proceed here?
Sure. Digitally sign the code with a certificate that links back to a trusted key chain.
Are only signed jar files allowed?
It is progressing towards that, yes.
Is there anyway I can tweak some settings to get unsigned applets to load?
On your own machine? Probably for a little while longer, as Oracle continues to tighten the security along the lines you have discovered.
For the users? No, nothing that is practical beyond 'educate your users as to the advantages of the digitally signed code', and to 'click OK when prompted'.
The best thing you can do if these are your applets is to sign them with a decent signing key. (Or if the applets are solely for your own use, a self-signed certificate will do once you have imported it into your JVM's keystore as trusted.)
If these are applets supplied by someone else, either convince the supplier to sign them (with a good key), or stop using their applets. Period.
The reason that Oracle are moving in this direction is that applets can do a variety of nasty things to your machine by exploiting security holes of various kinds. Disabling unsigned applets helps protect the user from being a victim of malicious applets ... since the "bad guys" are unlikely to sign their code with a certificate that says who they are.
From appearances, Oracle really screwed up. Not only did they break hundreds of thousands of man-hours worth of benign legacy applets... Having to digitally sign applets between local builds undermines new applet production. They seriously need to give some thought to this.
I guess you can always download and use an old version of Java (one that actually works...):
http://www.oldapps.com/java.php
I will never undestand why have the security slider in the Java settings if it does nothing...
After install, restart your browser.
It works like a charm for me.
Related
I would really like to know if it is even possible to run a self-signed java applet in Java 8. I have tried everything possible except buying a certificate and I my self-signed applet gets blocked every time. I can only just make it accessible if I add an exception in Java Security Settings but Ive never had to do that for anything else and what user is actually going to go to that much trouble. Im using applets because I want to embed a DosBox on my site... But Im beginning to think that Java 8 just can't do self-signed applets, period.
Can anyone else manage to get their self signed applet through security? I'm about to lose my mind with this to be honest.
Self-signed certificates are not trusted, by definition. You have two choices:
Buy a code signing certificate.
Have the user adjust his Java Security Settings, or trust the publisher via the popup dialog.
This is how the system is designed and intended to work. It's been that way for 20 years.
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.
In the previous months I developed a sandbox Java applet for an academic project. I wasn't able to sign it with a trusted Certificate Authority because of the restricted budget.
With the release of Java 1.7.51 I found that the new security restrictions forbid the execution of the applet, because of the lack of signature.
Until now, I have found two rough solutions to this problem:
ask the user to include the applet page on his/her exception lists;
ask the user to set the Java security level to "Medium" (which, of course, is a risky manoeuvre).
Is there a way to overcome the restrictions imposed by Java with a self-signed applet without asking the user to change the security settings?
I would deeply thank you for your answers, since the option to buy a trusted certificate remains an expensive one.
Is there a way to overcome the restrictions imposed by Java with a self-signed applet without asking the user to change the security settings?
Short answer, no. Long answer, nope.
Its not a real solution but maybe a bit more convenient for the enduser:
Write a small programm (as jar file, or batch) which adds your site to the exception list. This tiny programm you offer to the user which can't execute your applet. It only has to be executed once. How this can be done is described here.
The file controlling the Exception Site List is stored in the user’s
deployment location as described in the deployment configuration. On
Windows 7 the location is
C:\Users\username\AppData\LocalLow\Sun\Java\Deployment\security\exception.sites.
The format is one site per line.
If you think that is not really trustworthy to the user you are probably right ;-) who executes a file downloaded from the internet? You can also just add a small description to your page and a user could execute it from commandline. For windows it would like that:
mkdir %USERPROFILE%\AppData\LocalLow\Sun\Java\Deployment\security
echo http://www.carlos.com >> %USERPROFILE%\AppData\LocalLow\Sun\Java\Deployment\security\exception.sites
The more I read my post I think the best solution is the certificate but still wanted to share this option.
I am having an issue with WebStart. I am a coder for an Indy game company, and we are trying to do an admin-only test on the site. I signed the working code, threw it onto the server, made a JNLP and started it. It doesn't work.
It is supposed to be a launcher, and get the runtime. Then when the user clicks Start Game, it runs the command java -jar on the run time.
Now, since we are an indy company and just starting out, we can't afford a professional certificate yet, so I had to enter all my info in Java's KeySigner. Now, here is the weird part. The signed code can't do java -jar, even if its ran from the desktop. The unsigned code, however, can do java -jar... And I can't do unsigned code for WebStart.
So, what do I do??? Is this a bug, and is there anything I can do to fix it without a professional certificate? Any help would be appreciated!
[EDIT] Here is the code in question http://pastebin.com/nDK8NZFE [EDIT]
To answer your second question. It is very unlikely, that a professional certificate would be any different. Actually i would be (somewhat) surprised if Java/WebStart could even tell the difference. I have been using self signed certificates for a couple years and never had any issues.
Check Can a signed Jar be run as an executable? to see if this may be the issue.
You could also easily run the Game from the same JVM, which also gives you better control. (you could easily track stats for your Game inside the Launcher)
I have developed an applet. But when my browser fetches it from the webserver it pops a security warring. I don't want this message to come. Meaning applet should run without the end users permession. How can I do that? Do I need to get my applet signed? If yes, from where can i get it signed? What's the cost of geting it signed?
Your description might relate to a number of problems, such as the code trying to do things which require trust. That does not sound like the case in this instance. If your unsigned code tried to do things that required trust, it would not prompt the user at start-up, but either prompt them when the trusted action is attempted (e.g. for cross site access in later JREs) or just fail with an AccessControlException or similar.
It could be that your applet uses multiple Jars and has run into the mixed code restrictions introduced in Java 1.6.0_20. But the symptoms do not sound quite right for that either.
Is your applet publicly available? What is the URL where I/we can visit it?
As an aside, if your applet tries to break out of the security sand-box, it must be trusted. That means the code must be digitally signed, and OK'd by the end user at the prompt. There is no way around it.
But it does not require a code signing certificate issued from a CA. You can roll your own code signing certificate using the tools of the SDK. I have a few small demos. of code projects that compile and build code before signing it.
You need to get yourself a code-signing certificate. Probably by some "well-known" CA if you want to avoid all warnings. The certificate itself costs money, but once you have it, you can use it to sign as many applets as you want (you do the signing yourself).