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.
Related
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 have a Java Web Start application, which I've tested on Windows 7, Linux and Mac OS X 10.7 (works fine on all).
On Mac OS X 10.8 Mountain Lion the following error occurs, with no option to choose "Allow".
The error looks like this:
Does anyone know of a workaround for this?
Just found a solution: Go into System prefs -> security and privacy, and check the box that allows applications to be downloaded from anywhere (you might have to click the lock to make changes to this)
This is because of a new feature in Mountain Lion known as 'Gatekeeper'. Following is a brief description:
Choose where apps are installed from:
Gatekeeper gives you three security options for downloading and installing apps for your Mac. You can download and install apps from anywhere, with the same protection that OS X Lion provides. For maximum security, choose to allow only apps from the Mac App Store to be installed. Or download and install apps from the Mac App Store and apps that have been signed with a Developer ID.
Gatekeeper alert:
Mountain Lion alerts you if you download and try to install an application from a developer who does not have a Developer ID.
Manual override:
If you receive an alert that an app is from an unidentified developer, you can still choose to install it. Control-click the installer or the application icon to reveal a contextual menu. Choose Open and you’ll see a dialog that allows you to install the application.
I had this same problem. I would also add that once the app is installed and you know it's working. You can revert the setting that you changed to set your mind at ease in terms of your OS X Security.
Regards
Click "Show details"
Tick the "Always trust "…"" which refers to the expired (or whatever) certificate involved
Click continue, and authorise the change in cert trust settings, "Update settings", which is added to your keychain
if "Allow" is still greyed out, relaunch
I recommend going to command line and using the following
$ sudo installer -pkg /path/to/installer -target /
and viewing the output. If you receive an error about the installer being untrusted and you know the source is accurate and you want to install it anyway, then
$ sudo installer -pkg /path/to/installer -allowUntrusted -target /
This is an issue with MacOS 10.8 and older installers using a different code signing tool than what Mountain Lion likes. Or so I'm told.
This has nothing to do with Gatekeeper. I have Java 7 (JRE build 1.7_09) and I do have this popup. I also allowed everything in Security. The site I use is for banking but please note mydlink does not work, either, nor does the Yahoo finance screen.
This is the same exact thing that I had experienced back in 2003 on my Jaguar back when the Java RE was completely outside. Now, Apple handed it back to Oracle and look what happened (not to mention the font resolution on the Java window.
it is not accessing the certificates (or lacking the signatures). Solution would be simple if anybody at Oracle could program for this platform. Appe had fixed it and now they pulled the rug from under us. Java is not the future but tell it to my bank...
OK here is he fix , just set your clock to manual and take it back a couple of years, then install the program and set your date and clock back to auto
sorted
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.
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 have a Java applet which doesn't need any special privileges to run (i.e, it runs fine in the sandbox), but which expects the user to enter some sensitive information. Therefore, I'd like the user to be able to verify the origin of the applet.
I then signed the applet, and everything appears to be working correctly. The browser apparently accepts the signature; for test purposes, I tried executing PrivilegedActions and everything worked. However, the browser doesn't inform the user that the browser is signed - from user's perspective, both unsigned and signed versions of the applet appear exactly the same.
So my question is: is there a way to instruct the browser to present the signature authority to the user, or something similar?
Firstly, this is not a valid usage for signing a jar.
Did you at some point ever forget to untick the always trust tickbox?
Back to the first point because it is quite important. By signing a jar you are putting the certificates name to the claim that it is secure. Note that being secure is very much broader than being non-malicious. The security dialog which asks whether the user wants to give full local user access pops up if any code anywhere is encountered is signed. It doesn't mean that some particular set of pixels are from a trsuted source.
The correct approach is to use https.