I have created a jar and added trusted security certificate to it. This works good till Java 7 Update 21+ pops up.
From the update I see the warning message "The application contains both signed and unsigned code".
I have seen so many queries on the same problem posted here but my bad that nothing helped me.
After some random search I have seen the link,
http://www.oracle.com/technetwork/java/javase/tech/java-code-signing-1915323.html
and
http://bugs.sun.com/view_bug.do?bug_id=8016771
Explains to create index.list to jar first and then add certificate to it. Still I get the same error.
I have also seen that 'Trusted-Library' kind of things to be added in MF file. But this is going to be a security vulnerable.
Any help guys...
Related
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.
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?
Java Applet is signed by Comodo and looks fine. It starts as per picture:
I am not allowed to post pictures so I will try to describe it. The Java Applet starts and it says, "the publisher name is verified and the digital signature for this application was generated with a certificate from a trusted authority"
but when I press on "run" the following is popped up straight away:
"The publisher name is unknown. There is no digital signature for this application."
and the security warning as per picture above pops up all the time the applet is accessed / started. I tried cleaning Java cache and browsers' cache but no joy. I also tried re-installing Java completely to make it thoroughly clean "vanilla" but no dice either. The certificates are not expired, their validity is up to March 2016. I even tried importing the certs into Java's keystore but it did not help. Java is version 8 update 45 (build 1.8.0_45-b15) and it's run on Windows 8. Could anybody suggest anything, please as I am completely lost... Many thanks in advance!
In other words in order to get to the applet I have to click through the warning each time the applet is accessed..
Years ago I wrote a Java Web Start application in NetBeans that performs a simple file upload task. For years I had it as a self-signed applet but finally caved and bought a signing certificate. I've got it all signed now, but I'm running into a new problem.
One of the main class' public methods gets called by JavaScript. However, it seems to have stopped working. When I try calling this method manually in Firebug, here's the message I get back:
Error: Liveconnect call for Applet ID 8 is not allowed in this JVM instance.
UPDATE: Here's the version of the error that I get when I try this in Chrome:
Error calling method on NPObject.
I am already using the most up-to-date version of the Java plugin (7u51), so what gives? This applet used to work, but now apparently it no longer does. Do I need to add something special to the code? Or change a setting in the way it's compiled by NetBeans?
I figured it out; I found some forum posts that mentioned I had to update my Manifest file. Apparently Oracle recently changed the way Liveconnect works so you have to be explicit about allowing subdomains that can call the applet.
The information on that is here, and basically you have to add the Caller-Allowable-Codebase directive to the Manifest file. Fortunately it can be set to a wildcard, which is what I ended up doing. Apparently you're also supposed to set Application-Name along with it in the manifest file, and you're specifically NOT supposed to include Trusted-Library true. I don't really know why or what that does, but I was able to adjust my manifest file and everything seems to work again!
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).