JNLP FileOpenService warning despite signed applet w/ "all-permissions"

Hi all,
We are deploying an applet using java 7u21. The applet is signed and the jnlp file contains a security section requesting "all-permissions". Even so, every time that we run the applet a pop-up appears with "The application has requested read/write access to a file on the machine. [...]"
My understanding is that this warning should no longer display... Is that true? The only thing I have found related to this is http://docs.oracle.com/javase/7/docs/technotes/guides/javaws/developersguide/faq.html#s407, but that seems to indicate I should only see this dialog if I lack file access permissions. (I think I have those via trusted cert + jnlp all-permissions setting).
Thanks for the help,
Buzzy
Relevant text from the link:
5074526: ExtenededService file APIs show security dialog even if app is signed.
In version 1.5.0.
When using the FileOpen Service, the security dialog will only show if the application does not
have file access permissions. This is not true with the new ExtendedService OpenFile, and
OpenFiles methods, the security dialog shows anyway.

I am having the same problem. We are using JRE 1.4.1_05. When a certain EJB is called I get:
java.security.AccessControlException: access denied (java.net.SocketPermission XXX.XX.XX.XXX:7001, connect,resolve)
at java.security.AccessControlContext.checkPermission (Unknown Source)...
I have tried setting the following permission in my jre's /lib/security/java.policy file:
grant{
permission java.net.SocketPermission "host:port", "accept,connect";
After setting this permission the EJB that caused this error seems to crash. Is this the correct permission to set for the above mentioned exception? Is there any other alternative to uninstalling the security manager?

Similar Messages

Capture and RTP on a SIGNED applet.

I am trying to build an applet that allows users to chat both ways. I want the user to install nothing (other than java) and i provide the libraries they need (including jmf). I have signed the applet to ease my troubles, but it seems they are still there. The basic goal: capture audio from two microphones, send the audio via RTP, hear audio on both sides.
Even though I have a signed applet with all permissions, I lack permission to capture from applets? Aside from the fact that this seems absurd, it's frustrating. I am looking to find a way around this. I don't want the users to have to manually change the JMFRegistry or download a program to it.
The better options :
1) Is there a way to take advantage of the signed applet to alter the permissions in the program? (Seems very unlikely, but it would be the best).
2) Is there a way to provide the permissions in the jmf.jar (including jmf.properties?) that I include? (Seems more unlikely than 1)
3) What makes this more interesting (frustrating), I can use the Java Sound API to access the microphone and open an AudioInputStream. Can I plug this stream, or some other object from javasound, into the JMF somehow to send it via RTP?
4) Other options?

I found a way to use javasound instead of the jmf for the source audio (that's number 3 in my original post). So, i'm good for my problem.
If you want to do mixing, javasound should have more support for mixing (though I've not done it). Check out this thread, it was very useful for me.
http://forum.java.sun.com/thread.jspa?threadID=680525&start=0&tstart=0
I might have spoken too soon... I am just getting static - but that might be related to audio formats.....
Message was edited by:
mortserg

Right click for copy/paset on signed applet not working

Hi Guys,
I have an application which runs forms containing different controls like text fields, text areas etc. The forms are rendered in applets in Windowos 7. After upgrading to JRE1.7u45 the right click menu containing copy/paste options which used to appear when any right click done inside textfield or other control has disappeared except for textarea controls. Interestingly the right click is working inside TextArea but not in other controls.
My Applet is digitally signed(Verisign) and all permissions set. I have also tried accessClipboard permission in my .java.policy file to no avail.
My applet code is rather old. We tried to upgrade JDK to 1.7u45 to compile and sign the JAR but we got few errors so we used JDK 1.3 to compile the JAR and 1.7u45 to sign the JAR file. Can this be a cause for right click menu not working?
Please suggest/advise on this.
Thanks,

Hi Guys,
I have an application which runs forms containing different controls like text fields, text areas etc. The forms are rendered in applets in Windowos 7. After upgrading to JRE1.7u45 the right click menu containing copy/paste options which used to appear when any right click done inside textfield or other control has disappeared except for textarea controls. Interestingly the right click is working inside TextArea but not in other controls.
My Applet is digitally signed(Verisign) and all permissions set. I have also tried accessClipboard permission in my .java.policy file to no avail.
My applet code is rather old. We tried to upgrade JDK to 1.7u45 to compile and sign the JAR but we got few errors so we used JDK 1.3 to compile the JAR and 1.7u45 to sign the JAR file. Can this be a cause for right click menu not working?
Please suggest/advise on this.
Thanks,

Problem on runtime enviorment for signed applet

I am using the Java Media Framework for video capturing .Problem which i am facing is i have to configure the client machine so i wanted to download few of the class files which will execute on the client side and then stream the video back to the server .For this i have dezigned a java applet.This applet is signed by myself without any external agency so when ever the application is executed where it was signed this application gives no problem but when a different machine access the applet the user is asked for the verification of the applet but the error is thrown stating that the class not found exception .So please guide me that while making a signed applet which all packages need to be signed and what is the procedure .Do i have to sign the jmf packages also .

I have signed applets but not with jmf. Your best bet is to put the applet in a jar and sign the jar. Most java runtimes with a self signed applet will prompt the user and ask the user if they want to grant permission. You probably have to use the java html converter to code your html to force the use of suns plugin. I am not sure if you have to sign the jmf jars or they may already be signed.

Warning popup for jnlp and all-permissions security, recent java update

We have a java program running with java webstart. The jnlp includes the all-permissions security level.
All jar files have a manifest with Permissions: all-permissions and all jar files are signed with our trusted certificate.
When the program is started we get a popup saying something like:
"This application will run with unrestricted access which may put your computer and personal information at risk. Run this application only if you trust the locations and publisher above."
This popup is coming _everytime_ the program is started... which is very annoying for the user and causes support issues for the organization.
This has started to happen in the recent java update. First the program did not start at all until we included the Permission attribute in every jar's manifest.
How can we get rid of this popup?
Best regards,
Emil

If we add the following to the manifest of the jar files:
Permissions: all-permission
Application-Library-Allowable-Codebase: *
Caller-Allowable-Codebase: *
It seems like the "checkbox" to only show the warning message once is back again (without those two last lines above in the manifest there is no checkbox at all).

Change language on the security warning popup when using signed applets

Hi
Today when we use a signed applet the user get a security warning popup box where the langauge is English.
Is it possible to change the language to other that English and if possible how can this be done ?
Thanks in Advance,
Henrik Rasmussen
Denmark

The Microsoft one is especially annoying because they should know better than to submit from secure to insecure.
Let's say you are currently logged in to a Microsoft account and you click Sign in on MSDN. The site redirects to login.live.com, which recognizes that you are logged in, and generates a page with a hidden form and submits it back to MSDN using a script. This is where the problem is, because the hidden form action URL is not secure, yet it is on a secure page. (See Screen shots)
The workaround (hack, whatever) is to modify the form to a secure address before it is submitted. How can you do that? Since it is impractical to do by hand, you can use an add-on.
In an earlier thread, user thx1200 posted a link to a userscript that fixes this issue on login.live.com. The userscripts''.''org site has seemingly died, but there is a copy on a mirror of that site.
* Earlier thread (long): [https://support.mozilla.org/questions/964250 How do disable this Warning? Although this page is encrypted, the information you have entered is to be sent over an unencrypted connection]
* You need Greasemonkey to run user scripts: https://addons.mozilla.org/firefox/addon/greasemonkey/
* User script install page: [http://userscripts-mirror.org/scripts/show/173384.html Fix security warning for Microsoft Live login]

Classloader caching in signed applet is very slow and weird

I have a signed applet running in the 1.4.1_01 plugin environment, and
I'm getting the following kinds of messages when I use debug mode 5 in the console:
Connecting http:[myserver]/someclass.class with no proxy
Connecting http:[myserver]/someclass.class with cookie "JSESSIONID=..."
Sometimes, the classloader will say:
WARNING: Unable to cache someclass.class
Moreover, some classes will be repeated two or three times, as if the classloader is trying to get the same class two or three times.
Some of these classes are even in the java.lang package!!
The thing is, I'm actually trying to get the applet to use webservices, so I've signed the Apache Axis jar files (about 8 or so) and included them in the "cache_archive" parameter. The classes giving problems are from these archives, not from my main applet jar.
The applet will eventually work, but the first time takes a LONG time to initialize because the classloader is trying to verify all the classes (i think). Subsequent runnings of the applet within the same browser will be much faster, but the same thing will happen if I start a new browser instance.
My questions are:
1) Why is the classloader trying to load from my http server rather than from the local jars? (they seem to be statically cached, I checked the plugin control panel)
2) Why is the classloader reloading the same classes multiple times?
3) Is the classloader verifying the signatures for each class, because it's taking a long time due to very many classes (100's).
I can't seem to find ANY documentation for this at Sun or Google.
Please help if you can!
Andrew

I've got the same problem with applet using SOAP based on jwsdp.
But classloader only try to get classes from server that are used in SOAP calls.
The only workaround I found is to move this classes to root package, but still there are problems with
Connecting http://<host>/int.class with no proxy
Connecting http://<host>/int.class with no proxy
WARNING: Unable to cache http://<host>/int.class
requests.
Maybe this is a bug of Sun SOAP implementation?

Signed applet does not grant AudioPermission "record"

From what I gather, if I have a trusted signed applet sitting on a webpage and
the visitor accepts (runs) the applet, then they should not need to have:
grant {
permission javax.sound.sampled.AudioPermission "record";
in their java policy file. Well I have done all this (with a certificate from
Thawte) and posted a thorough example at:
http://www.livesite.net/JavaSoundTest
At the bottom of that page there is a "Check permissions" link which will alert
true/false if we have record permission. Clicking any "Record" link will
attempt to open a TargetDataLine.
My experience (and problem) is: record permission must be granted even though
the applet is signed by a trusted CA.
I would very much appreciate any help.
Are you able to record/playback (without granting record permission in your
java policy files) with the JavaSoundTest applet webpage?
Is there something I am missing?
------ More information ------
Java Control Panel -> Advance -> Security
'allow user to grant permissions to signed content' is checked
Reproducable on:
MS NT4 w/ IE6
MS Windows 2000 w/ Firefox 1.5
MS Windows XP w/ Firefox 1.5
MS Windows XP w/ IE6
Fedora FC6 w/ Firefox 2.0
Also, this happens with a commented-out record permission in the user
.java.policy file, or when the policy file does not exist.
------ Source code: opening the target data line ------
Using the JavaSoundTest applet page without granted permission, clicking a
record link will yield this exception in the java console:
java.security.AccessControlException: access denied (javax.sound.sampled.AudioPermission record)
at java.security.AccessControlContext.checkPermission
at java.security.AccessController.checkPermission
at java.lang.SecurityManager.checkPermission
at com.sun.media.sound.JSSecurityManager.checkRecordPermission
at com.sun.media.sound.DirectAudioDevice$DirectDL.implOpen
at com.sun.media.sound.AbstractDataLine.open
at net.livesite.jsound.Recorder.run(Recorder.java:161)
while opening a TargetDataLine as:
23 private static TargetDataLine line;
157 line = (TargetDataLine) AudioSystem.getLine( lineInfo );
158
159 try
160 {
161 line.open( format, (int) format.getSampleRate() );
162 }
------ Source code: Using the security manager ------
The "Check permissions" link on the TestJavaSound applet page calls this method:
191 public boolean hasSoundRecPriv()
192 {
193 boolean ret = false;
194
195 try
196 {
197 SecurityManager sm = System.getSecurityManager();
198 if (sm != null)
199 {
200 sm.checkPermission(new AudioPermission("record"));
201 }
202 ret = true;
203 }
204 catch(SecurityException e)
205 {
206 ret = false;
207 }
208
209 return ret;
210 }
(This is a continued post from JAVASOUND-INTEREST at SUN.COM)

Is there something I am missing?1) Applets are not well supported by Sun,
and are inherently problematic as a reult
of that.
2) My experience suggests that the diagnotics
applet is not reliable for detecting JMF.
3) I guess the JMF applet is doing checks of
policy files, despite the signed code.
You might circumvent most of these problems,
by using web-start to launch an application.
Here are some of my tests at launching
JMF using web-start.
http://www.javasaver.com/testjs/jmf/

Access denied to a security provider on a signed applet

Hi,
I'm having permissions problems to work with a security provider.
The security provider is already installed at java.security. In fact, at Netbeans when debbuging the app it's working perfectly.
If I'm working the provider in an signed applet, then there are errors.
Even, I have created a .jar file and I have saved in the /ext directory, wich by default in the java.policy file has got all security permissions.
grant codeBase "file:${{java.ext.dirs}}/*" {
permission java.security.AllPermission;
Even with these granted permissions, I'm getting problems to work with the security provider that I have installed. Also, with these permissions I should be able to install the security provider.
log:
<record>
<date>2012-03-13T12:13:39</date>
<millis>1331637219126</millis>
<sequence>17</sequence>
<logger>appletpdf.appletPdf</logger>
<level>SEVERE</level>
<class>appletpdf.appletPdf</class>
<method>applTest</method>
<thread>11</thread>
<message>excepcion: {0} </message>
<exception>
<message>java.security.AccessControlException: access denied (java.security.SecurityPermission authProvider.SunPKCS11-Provider-name)</message>
<frame>
<class>java.security.AccessControlContext</class>
<method>checkPermission</method>
<line>393</line>
</frame>
<frame>
<class>java.security.AccessController</class>
<method>checkPermission</method>
<line>553</line>
</frame>
<frame>
<class>java.lang.SecurityManager</class>
<method>checkPermission</method>
<line>549</line>
</frame>
<frame>
<class>net.sourceforge.jnlp.runtime.JNLPSecurityManager</class>
<method>checkPermission</method>
<line>250</line>
</frame>
<frame>
<class>sun.security.pkcs11.SunPKCS11</class>
<method>login</method>
<line>1036</line>
</frame>
<frame>
<class>sun.security.pkcs11.P11KeyStore</class>
<method>login</method>
<line>874</line>
</frame>
<frame>
<class>sun.security.pkcs11.P11KeyStore</class>
<method>engineLoad</method>
<line>764</line>
</frame>
<frame>
<class>java.security.KeyStore</class>
<method>load</method>
<line>1201</line>
</frame>
<frame>
<class>apppdf.appPdf</class>
<method>tPKCS11</method>
<line>174</line>
</frame>
<frame>
<class>appletpdf.appletPdf</class>
<method>applTest</method>
<line>137</line>
</frame>
<frame>
<class>appletpdf.appletPdf</class>
<method>initapplDPdf</method>
<line>116</line>
</frame>
<frame>
<class>sun.reflect.NativeMethodAccessorImpl</class>
<method>invoke0</method>
</frame>
<frame>
<class>sun.reflect.NativeMethodAccessorImpl</class>
<method>invoke</method>
<line>57</line>
</frame>
<frame>
<class>sun.reflect.DelegatingMethodAccessorImpl</class>
<method>invoke</method>
<line>43</line>
</frame>
<frame>
<class>java.lang.reflect.Method</class>
<method>invoke</method>
<line>616</line>
</frame>
<frame>
<class>sun.applet.PluginAppletSecurityContext$4</class>
<method>run</method>
<line>699</line>
</frame>
<frame>
<class>java.security.AccessController</class>
<method>doPrivileged</method>
</frame>
<frame>
<class>sun.applet.PluginAppletSecurityContext</class>
<method>handleMessage</method>
<line>696</line>
</frame>
<frame>
<class>sun.applet.AppletSecurityContextManager</class>
<method>handleMessage</method>
<line>69</line>
</frame>
<frame>
<class>sun.applet.PluginStreamHandler</class>
<method>handleMessage</method>
<line>273</line>
</frame>
<frame>
<class>sun.applet.PluginMessageHandlerWorker</class>
<method>run</method>
<line>82</line>
</frame>
</exception>
</record>
Fails in the line where the KeyStore is loading:(Pin is correct)
KeyStore myKeyStore=null;
Provider p = Security.getProvider("SunPKCS11-Provider-Name");
myKeyStore = KeyStore.getInstance("PKCS11",p);
char[] pinData = pin.toCharArray();
myKeyStore.load(null, pinData);
Any help would be apreciated.
Thank you.
Bye

Thank you for your information, Frank, as it clarifies part of my confusion. However, there are a couple more loose ends I'd love to address before I mark your responses as answers.
Do backup and restore privileges apply at all over a network mount created via "net use"?
The network mount requires a username and password for the destination machine. Assuming the destination machine is a Windows box with a simple CIFS share, how does this user affect our permissions and access? Do we end up effectively impersonating this
user, or is the access check still done with our sync process's run-as user?
We require that both our configured run-as user for our sync process *and* the credentials passed to the network mount be administrator users of the local system and destination system, respectively, meaning they're in of the "BUILTIN\Administrators,
S-1-5-32-544" group.
On re-syncs, the destination file will exist and since we don't have the ability to read the ACL in all cases (we're running as one user, the file is owned by another user, and we aren't specified in the ACL in any way), we aren't able to determine if the
file has changed. Is it possible to determine the owner of this file in this case? Preferably, we'd obtain the entire SDDL.
My proposed plan is to interpret access denied as a difference requiring re-sync, resulting in us taking ownership of the file, granting ourselves access, determining if there are data differences, and then re-syncing the metadata as appropriate.

My signed applet works with 1.4.1 plugin but it doesn't with 1.4.2_02 !!!

Hi there, I've got problems trying to sign an applet with Java 2. That applet is an FTP which is used for uploading files throught the Browser (just upload).
I signed my applet with SDK 1.4.1 when I surfed the page which contains it, the applet works properly (the browser had Java plug in 1.4.1) ... the certificate appeared (thawte), I clicked "Yes" for agreeing the certificate .. everything went fine. The problem was when I tried to navigate that page with a Browser with Java Plug in 1.4.2, I agreed the cetificate, but when I tried to upload a file with the applet the following error happens :
ava.security.AccessControlException: access denied (java.io.FilePermission C:\install\slsk151.wma read)
     at java.security.AccessControlContext.checkPermission(Unknown Source)
     at java.security.AccessController.checkPermission(Unknown Source)
     at java.lang.SecurityManager.checkPermission(Unknown Source)
     at java.lang.SecurityManager.checkRead(Unknown Source)
     at java.io.FileInputStream.<init>(Unknown Source)
     at java.io.FileInputStream.<init>(Unknown Source)
     at FtpSigned.upload(FtpSigned.java:463)
     at FtpSigned.run(FtpSigned.java:526)
     at java.lang.Thread.run(Unknown Source)
after that I downloaded the SDK 1.4.2_02 and I installed the plugin
1.4.2_02 (build 1.4.2_02-b03)
I signed tha applet again and it didn't work ...
please ... I need help!
Thanks in advance.
Nico.

Funny, I had a problem going to _03 when it worked fine in _02. Symptoms: In IE, Sun's plug-in displays security warning prompt for signed applet, and, even though the user clicks YES to accept, all priv operations cause exceptions. It sounds like what you're referring to, but I'm wondering why I didn't see it in _02. Anyway, I'm going to look into the doPriv... stuff to see if that fixes my prob and I'll report back FWIW.

Signed applets and dialogs

hi all,
question to clarify my understanding of signed applets.
got a bog-standard applet. nothing clever or special.
got myself a bog-standard cert from thawte.
signed the applet and put it on a webserver.
displays the correct security notice on first load. continue and "Always trust this company" etc...
all runs fine.
in the applet init, i've put in
java.awt.AWTPermission perm = new java.awt.AWTPermission("showWindowWithoutWarningBanner");
try {
AccessController.checkPermission(perm);
System.out.println("access allowed?");
} catch (AccessControlException ex) {
ex.printStackTrace();
}open the main frame, and all is good. no banner or access denied exception.
show a popup menu, or tooltip. no banner.
display a dialog. oops, a banner "Java Applet Window" and the bottom section of the dialog is covered with the warning msg.
so i'm confused.
does this mean that this permission does not apply to dialogs? (if so, what?)
even with a cert, this msg cannot be removed? (please tell me no)
wrap and recode all dialog openings with AccessController.doPrivileged? (i dont wanna do this)
or i missed something with the setup.
i've been searching the forums for some info, but seem to be going in circles. editing the policy file on all client comps is not a valid option, unless there is sometrick i dont know about .
tia
-a

hi,
i got the answer from the link
http://www.javaworld.com/javaworld/jw-12-2000/jw-1215-security.html

What happen with my Signed applet

Hi all
I have just made a Signed applet
Step by step:
1. I made applet source code
2. I made a HTML file
3. I build applet source code
*javac FirstApplet.java*
*jar cf FirstApplet.jar *.class*
*keytool -genkey -keystore mykeystore -alias launcheralias*
*keytool -selfcert -keystore mykeystore -alias launcheralias*
*jarsigner -keystore mykeystore FirstApplet.jar launcheralias*
*del *.class*After that i run HTML the first.
it appears to me a message
*WARING SECURITY*
*The application's digital signature can not vertifed*
*Do you want to run the application ?*I check option *"Always trust content from this pulisher"* --> My program still runs well
I dont understand why when i run my applet the firt it appears to me that message.
What is wrong and how to solve ?
Please help me.
Thanks in advance.
Diego

Actually the above same prob is faced by me in my application.
The application's digital signature can not vertifed
Due to this pop up, our customer thinks our certi is nt valid & its nt possible to make them understand abt it since they feel insecure.
This warning appears due to JVM running along with application.
If we go to
Control Panel->Java->Security->Certificates and choose secure sites in Certificate type.
Here link of my web application should appear, in order to remove this warning.
So is there any way so that link of my web application shpuld be directly installed on the above mentioned location on Client's PC??? or any other alternative
Please Helppp...

Signed applet doesn't popup "trust applet" dialog

Hi,
I have the following situation with a Java applet:
It is VeriSign signed and needs access to the hard drive.
It works fine on most computers and prompts the user if they want to trust the applet.
But on some computers this trust window never appears.
The window I'm talking about is this:
Warning - Security
The application's digital signature has been verified.
Do you want to run the application?This question just won't show up on some computers.
I know that some of them are running Vista, and I know that UAC is causing major issues (I found a site explaining the reason).
Is there anything simple that I can tell Vista users to do to give permission to the applet to run?
Is there anything at all I can tell Vista users?
Thanks!

Dunno why Vista or XP or IE would be causing this with settings... except to not let applets run at all. The signing control is managed entirely by the plugin in any recent Java version (1.4+, at least).
Untrusted applets would have to be added to a list, if there was one, which I'm not aware of a list.
If this were an issue with default configs on Vista or XP or IE, believe me I would have heard about it all up and down the last year+. Early last year, we released a new applet which is signed, and that's how I know that 1.4.1_02 doesn't work at all. And late last year we actually started using new functionality that would take advantage of the signed applet (talking to another server) so, if that didn't work on a lot of client's PC's, I would have heard long before now.
What is the problem, actually? Is the applet running at all? If so, are you sure it's not running as a signed applet (can you test with something an unsigned applet couldn't do)? Cuz there is the "remember this decision" option so you don't have to get the warning more than once from the same signer.

Web Start : JAR resources in JNLP file are not signed by same certificate

What does this error mean exactly?
All the jars in this JNLP file are signed by the same certificate it's just that some of them are also signed by another certificate.
According to this closed/fixed bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4928787
Web Start should not be rejecting jars due to multiple signers???
Is this a regression in 1.6? or was this never actually fixed?
I can make this work by not signing these 'presigned' jars and putting them into extension JNLP files but this is less than desirable.
Some reasons for not using the extension JNLP:
-- Avoid this bug (which is also marked closed but not fixed) --> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6566071
-- I would like to sign all the jars I deliver with my own certificate.
-- I would also like to give my clients the ability so sign the jars themselves (their own certificate) after they certify the application for distribution throughout their organization.

Thanks for responding.
Here is an example that will show the problem. If you want to try yourself:
NanoHTTPD.java is from here -> [http://elonen.iki.fi/code/nanohttpd/|http://elonen.iki.fi/code/nanohttpd/]
C:\test>java -version
java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode)
C:\test>dir
Volume in drive C has no label.
Volume Serial Number is CCC7-E05D
Directory of C:\test
04/10/2008 12:34 PM    <DIR>          .
04/10/2008 12:34 PM    <DIR>          ..
04/10/2008 11:04 AM               130 hello.java
04/10/2008 11:30 AM               500 hello.jnlp
04/10/2008 11:06 AM                89 hellohelper.java
04/10/2008 09:52 AM            20,547 NanoHTTPD.java
               4 File(s)         21,266 bytes
               2 Dir(s) 26,292,060,160 bytes free
C:\test>type hello.java
public class hello
public static void main(String[] args)
System.out.printf("Hello %s\n",hellohelper.getString());
C:\test>type hellohelper.java
public class hellohelper
public static String getString()
return "World";
C:\test>type hello.jnlp
<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.0+" codebase="http://localhost/" href="" >
    <information>
        <title>hello</title>
        <vendor>hello</vendor>
        <description>hello</description>
    </information>
    <security>
        <all-permissions/>
    </security>
    <resources>
        <j2se version="1.6" />
        <jar href="hello.jar"/>
        <jar href="hellohelper.jar"/>
    </resources>
    <application-desc main-class="hello"/>
</jnlp>
C:\test>javac *.java
Note: NanoHTTPD.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: NanoHTTPD.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
C:\test>jar cvf hello.jar hello.class
added manifest
adding: hello.class(in = 524) (out= 332)(deflated 36%)
C:\test>jar cvf hellohelper.jar hellohelper.class
added manifest
adding: hellohelper.class(in = 283) (out= 212)(deflated 25%)
C:\test>keytool.exe -genkey -alias hello1 -keystore hello1keys.jks -dname cn=hello1 -storepass hello1 -keypass hello1
C:\test>keytool.exe -genkey -alias hello2 -keystore hello2keys.jks -dname cn=hello2 -storepass hello2 -keypass hello2
C:\test>jarsigner -keystore hello1keys.jks -keypass hello1 -storepass hello1 hellohelper.jar hello1
Warning:
The signer certificate will expire within six months.
C:\test>jarsigner -keystore hello1keys.jks -keypass hello1 -storepass hello1 hello.jar hello1
Warning:
The signer certificate will expire within six months.
C:\test>start java -cp . NanoHTTPD
C:\test>javaws hello.jnlpAt this point click accept to trust the code and the program runs. Here is the console output:
Java Web Start 1.6.0_03
Using JRE version 1.6.0_03 Java HotSpot(TM) Client VM
User home directory = C:\Documents and Settings\4381
c:   clear console window
f:   finalize objects on finalization queue
g:   garbage collect
h:   display this help message
m:   print memory usage
o:   trigger logging
p:   reload proxy configuration
q:   hide console
r:   reload policy configuration
s:   dump system and deployment properties
t:   dump thread list
v:   dump thread stack
0-5: set trace level to <n>
Hello WorldNow for second signature, and run again:
C:\test>jarsigner -keystore hello2keys.jks -keypass hello2 -storepass hello2 hellohelper.jar hello2
Warning:
The signer certificate will expire within six months.
C:\test>javaws hello.jnlpThis time it fails. Console output:
Java Web Start 1.6.0_03
Using JRE version 1.6.0_03 Java HotSpot(TM) Client VM
User home directory = C:\Documents and Settings\4381
c:   clear console window
f:   finalize objects on finalization queue
g:   garbage collect
h:   display this help message
m:   print memory usage
o:   trigger logging
p:   reload proxy configuration
q:   hide console
r:   reload policy configuration
s:   dump system and deployment properties
t:   dump thread list
v:   dump thread stack
0-5: set trace level to <n>
#### Java Web Start Error:
#### JAR resources in JNLP file are not signed by same certificateTo verify jars:
C:\test>jarsigner -verify -verbose -certs hello.jar
         135 Thu Apr 10 12:39:26 CDT 2008 META-INF/MANIFEST.MF
         256 Thu Apr 10 12:39:26 CDT 2008 META-INF/HELLO1.SF
         770 Thu Apr 10 12:39:26 CDT 2008 META-INF/HELLO1.DSA
           0 Thu Apr 10 12:37:36 CDT 2008 META-INF/
sm       524 Thu Apr 10 12:37:04 CDT 2008 hello.class
      X.509, CN=hello1
      [certificate will expire on 7/9/08 12:38 PM]
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope
jar verified.
Warning:
This jar contains entries whose signer certificate will expire within six months.
C:\test>jarsigner -verify -verbose -certs hellohelper.jar
         141 Thu Apr 10 12:38:56 CDT 2008 META-INF/MANIFEST.MF
         262 Thu Apr 10 12:41:30 CDT 2008 META-INF/HELLO2.SF
         770 Thu Apr 10 12:41:30 CDT 2008 META-INF/HELLO2.DSA
         262 Thu Apr 10 12:38:56 CDT 2008 META-INF/HELLO1.SF
         770 Thu Apr 10 12:38:56 CDT 2008 META-INF/HELLO1.DSA
           0 Thu Apr 10 12:37:44 CDT 2008 META-INF/
sm       283 Thu Apr 10 12:37:04 CDT 2008 hellohelper.class
      X.509, CN=hello2
      [certificate will expire on 7/9/08 12:38 PM]
      X.509, CN=hello1
      [certificate will expire on 7/9/08 12:38 PM]
s = signature was verified
m = entry is listed in manifest
k = at least one certificate was found in keystore
i = at least one certificate was found in identity scope
jar verified.
Warning:
This jar contains entries whose signer certificate will expire within six months.Why does javaws say: "JAR resources in JNLP file are not signed by same certificate" when clearly they are both signed by the same certificate (the one aliased by CN=hello1)?

Signed applet on local filesystem not working anymore

Hi,
Everyone knows that accessing local file system has always been a security threat.
But clients are our bread and butter.
Our clients have asked for web app consisting in a zip file, downloaded, containing an html page with dynamic content and links to many pdf.
So far, so good: i download my zip unzip it, access my pdfs, and once every pdfs have been modified, i click on a button that is from a signed applet, and the applet checks which pdfs have changed, and post the files to a web service on a server....Et voilà.
It's been working for at least 5 years like that.
But now my clients are updating to jre 7u45.
And as A LOT OF PEOPLE HERE....my applet won't load and work if i compile it with the new sdk....: i get the InvocationTargetException...exception
Is there an easy way to , step by step, compile , sign and yadi yada...and make it work.
I mean my applet has always did its job..., nothing will change in the code...it's only the annoying changing everything without warning.....
Anyone whould have an alternate approach instead of applet (my guess is NO).....: but nowadays with an applet you program 5 hours and you deploy 10 days.

I have the same issue here and it is not working anymore with auto-signed certificate too
I am going to stop using Safari if that , all is working fine with Chrome Firefox and Opera
Apple says
As a good security practice, you should validate PGP keys you receive, and not trust keys that cannot be validated. Information to validate the Apple Product Security PGP Key is available from
Maybe but this is my problem and if I want to trust anyway I must use another browser

JNLP FileOpenService warning despite signed applet w/ "all-permissions"

Similar Messages

Maybe you are looking for