If I develop a signed applet and embed it in several webpages, each visitor:
Should I accept the same applet on every single webpage?
Should accept it again if the user deletes the temporary internet files?
Shoud accept it again if the user visits the same webpage with a different browser?
What about unsigned applets?
Thank you
The current Oracle JRE has an tick box option to always accept the certificate. This means that other applets [jars], or just different versions of the same applet, signed with the same certificate will also be always accepted. This is independent of site or cached files. Previously always trusted certificates can be removed in the Java Control Panel under the Security tab.
The current Apple JRE allows always accepting for an applet from the same site. It was recently announced that Apple will be contributing back to the Oracle OpenJDK.
For unsigned applets there is no certificate to accept. They are run without elevated privileges.
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.
With the new release of OS X 10.8, the Gatekeeper will popup the following warning, when you try to start a signed Java applet:
The applet has been signed with a valid code signing certificate and will work correctly on other platforms as well as previous versions of OS X. If I change "Allow applications downloaded from:" to "Anywhere", it works correctly.
As far as I can figure out "The digital signature could not be verified", actually means something like "the signature has not been made with a Mac Developer ID".
So: Can I sign Java applets with a Mac Developer ID? Can I sign it with both a Mac Developer ID and a standard code signing certificate? Is there a better approach?
Here's the answer that I got from Apple Developer Technical Support:
Thank you for your patience while we investigated this.
The alert is presented by Java, not by Gatekeeper. However, you're
correct that the verification logic was changed on OS X Mountain Lion.
For a while now, users have been presented with this alert when
running a signed applet, because signed applets can escape the Java
sandbox and make unexpected changes to the user's system. Users have
the option to check the "Allow all applets from " box if
they trust the developer and thus they won't see the alert again
unless they remove the item from the Java Security preferences.
What's changed in Mountain Lion is that the verification alert now
basically means that the applet's signature is valid, but the applet
is from an unidentified developer and is trying to escalate privileges
when Gatekeeper is enabled and the user has to decide whether to allow
that.
"Unidentified developer" means a source other than the Mac App Store
or a Developer ID-identified developer. Note that Java applets cannot
participate in the Developer ID program.
If Gatekeeper is set to trust only Mac App Store apps, then you will
not be able to add the applet to the trusted list unless you add the
applet's certificate to the keychain using the sheet that appears
after clicking Show Details.
Unsigned applets are not allowed to escape the Java sandbox at all.
This is consistent with Gatekeeper's treatment of native Mac apps;
apps from unidentified developers are not allowed to run by default.
If you'd like to see the wording of the alert changed, please file a
bug report at https://developer.apple.com/bugreporter.
This basically means that there is no way to sign the applet in such a way that you can avoid this message to be shown. I filed a bug report to Apple saying that I want the wording of the message to be changed not to contain words like UNIDENTIFIED, UNVERIFIED, INSECURE... because that's the whole point of signing the applets, so that the users can feel all warm and cosy inside when they need to allow the applet to run, to assure them that what they are about to allow is OK and verified and it won't do any harm to their computer, and we need to show it on a place where it will be visible, to poke their eyes with it.
You answered your own question.
Gatekeeper considers that certificates / signatures not issued by Apple are not trusted.
Apple Documentation will tell you how to export your certificate. You can then use it as usual.
The codesign command may also do the trick.
I created a java applet that uploads a file to a server via ftp, it uses an external library by apache, I signed my applet but when I start the applet from the browser I get two security popups, how do I prevent to show or show only one? hello and thanks
this is the example link:
http://frx08.altervista.org/javaftp/
(the second popup says that the code contains signed and not signed code but I don't know why..)
Either:
Make sure all your code is unsigned, perhaps using javax.jnlp available to applets since 6u10. [best route]
Make sure absolutely all your code is signed (and this includes resource files).
The "Trusted-Library" feature allows a signed and trusted library to run with untrusted code. It can be very difficult to write the library securely.
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).
I am looking to start a java web applet, as I need something that doesn't need downloaded (saved to computer) and for the most part will work for Windows and OSX.
I have never done anything with java, so my question is can you do everything you can do with a normal java jar file on the web?
More specifically, can you write a web applet that detect window titles (Like the title of an active window), running processes, look in the windows registry, or find hard drive serial numbers?
The applet needs special permissions for these type of actions. It needs to be signed and trusted by the user.
Have you considered using Java Web start? If the communication with the browser from which the applet is run is crucial, then applets are probably the way to go. Otherwise Java Web start is preferred as you'll face less compatibility problems with browsers' Java plugins and different JVM versions.
Yes, but your applets must be trusted by user (user change some browser security settings)