Signing Applets..Policy File

Hi All,
I have developed a Applet to read from local hard disk file. I have signed it. Regarding policy file i hv sm confusion.wihtout policy file also it is working. Isn't must to use policy files. If it is must how and where i will install it on other remote machines.
Reg Certificates, whether we hv to manually give a link in our html. or anyother way is there to let IE automatically pop up that "Plugin Window" asking abt certficate(Grant,deny..\)
Lemme me know the details..

I have followed the instuction and signed all other libraries and I have encountered a runtime error in IE.
The title of the message is Microsoft Visual C++ Runtime Library.
The content is
Runtime error!!
Program: C:\program files\internet exploer\iexplorer.exe
Abnormal program termination.
I have tested serval version of IE and Java plug-in. It include:
IE 6.0 sp1 with JRE 1.3.1_10
IE 6.0 sp1 with JRE 1.3.1_06
IE 5.5 sp2 with JRE 1.3.1_05
Could someone can help me? Thanks!!

Similar Messages

Where does applet.policy files go?

does any body know where to put applet.policy file? i am running
appache so i believe it should go under c:\webdocs\applet.policy
it it correct???
Please help

The include directory contains C language header (.h) files that may be linked with files in the lib directory. Those files are used by adadmin and adpatch (and some other ad utilities) to relink executable files which will be located under the $PRODUCT_TOP/bin directory. Please note that not all products require this directory.
Oracle Applications Concepts
http://download-uk.oracle.com/docs/cd/B25516_14/current/acrobat/11iconcepts.pdf

Applets, Policy Files, jar signing, JNI, etc

Hi,
I need an Applet to be able to connect to sockets and use some JNI. Hence, as far as I can tell, I need to use a Policy File. In a standalone application, I have written my policy file tried it out by switching on the security manager. However I am not sure how I do this with an applet.
I have read many examples of Jar signing, yet every example uses appletviewer and the -J-Djava.security.policy to show the security policy in action.
However I want this to work through a normal browser, so how do I achieve this?
Do I specify a URL to the java.security.file in the embed/object/applet tags in the HTML?
Do I put the policy file in the jar and reference it via the Manifest?
Any ideas much appreciated,
John B

The standard AccessControlException:
java.security.AccessControlException: access denied (java.lang.RuntimePermission getClassLoader)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:270)
at java.security.AccessController.checkPermission(AccessController.java:401)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:542)
at java.lang.ClassLoader.getParent(ClassLoader.java:701)
Or something like that.
That's what I'm trying to solve, I wish to use the Java Security Policy system to allow my applet access to various resources, such as writing files. Now I've seen that signing an applet will give it full access (in my view, this is rather insecure, but anyway), however following the steps to sign an applet two or three times has still presented me with the same problem. The signing is ignored, and the exception is thrown.
Applet signing aside, I fail to see any documentation stating how the policy file is used by the VM when running on a browser. I assumed it might be an entry in the Jar's manifest file, but again, I can find no documentation.
It's all very annoying, and Sun have done quite a bad job at documenting this. For example, their example talkes about -D-Jjava.security.policy=.... being passed to appletviewer. Who on earth uses appletviewer! If policies only work with that, then they are useless. I want them to work with whatever browser the applet is being run within.
Surely this isn't too much to ask? :)

Problems with signed Applet for File Download under JRE 1.4 (works with 1.3

Dear all,
i encountered a very strange behaviour with JRE 1.4x. A signed applet used for file download worked on all platforms (Windows NT, 2000 and XP wth/wthout SP...) until I installed JRE 1.4.x (1.4.1 or 1.4.2)
I get an EOFException when downloading binary files (for ASCII it works fine) when trying to readByte() from a DataInputStream. But not immideately, but after x bytes in the while-loop. Security is fine (I know there have been changes to that in jre 1.4, the applet itself can be started an runs with ASCII files for transfer)
Does anyone know, what has changed in jre1.4.
As I said, it works fine under jre 1.3.x
The relevant code is below: byte bt = dis.readByte(); causes the error
try{
// Get URL from Server
URL uFile = new URL(sFilename);
sThisURLFile = uFile.getFile();
Integer inte = new Integer(i);
//open input stream for the file on server
DataInputStream dis = new DataInputStream(new BufferedInputStream
(uFile.openConnection().getInputStream()));
//open output stream for the file on local drive
String sFilenameOnly = sThisURLFile.substring(sThisURLFile.lastIndexOf('/')+1);
int iDotPos = sFilenameOnly.lastIndexOf(".");
String sExt;
if (iDotPos > 0) {
sExt= sFilenameOnly.substring(iDotPos);
} else {
sExt = "";
File fileOut = new File(sDownloadDir + sThisURLFile.substring(sThisURLFile.lastIndexOf('/')+1) );
DataOutputStream dos = new DataOutputStream(new
BufferedOutputStream(new FileOutputStream(fileOut)));
//read one byte from input stream, and write that byte to output stream
long nByte = 0;
int iCnt = 0;
iFilesizeDone ++;
while (nByte < iFilesize){
String sErrPs = new String();
try{
sErrPs = "00";
byte bt = dis.readByte();
sErrPs = "01";
dos.writeByte(bt);
} catch (EOFException ee)
System.err.println("internal EOFException: " + ee.getMessage());
System.out.println("Error Filesize is " nByte " of " iFilesize "---" + sErrPs);
break;
nByte++;
iFilesizeDone ++;
iCnt ++;
if(iCnt >= 10240) {
ShowProgress(nByte, iFilesize, iFilesizeDone, iFilesizeTotal); // repaint does not work during init-procedure
iCnt = 0;
line = "Progress: Total: " + ((iFilesizeDone*100)/iFilesizeTotal) + " perc, " + iFilesizeTotal/1024 +" kbytes" ;
labLine.setText(line);
//dos.flush(); // improves Client performance (Agent-Call!)
dis.close();
dos.close();
}// End try
catch (EOFException ee)
System.err.println("EOFException: " + ee.getMessage()e);
catch (SecurityException se)
System.err.println("SecurityException: " + se.getMessage());
catch (IOException ioe)
System.err.println("IOException: " + ioe.getMessage());

perhaps they've changed something with the file blocking.
btw, you should try to use something like this
DataInputStream dis = new DataInputStream(is);
byte[] buffer=new byte[8192];
int numBytesRead;
while ( dis.available()>0 ) {
numBytesRead = dis.read(buffer);
}

Signed applet for file download?

Hello folks,
I have a signed applet through which i can upload multiple files to a servlet. I wish to create another applet or enhance this one to enable it to download multiple files from the server to the client m/c. Any idea, how to go about it?
I will appreciate your helpful replies.
Thank you,
Coreli

which part? You apparently already know how to sign an applet... and use a file chooser... and create servlets that can take files.... seems you need to do the opposite and use input streams where you used output streams before and vice versa...

AddProvider in a signed applet(cab file)

Hi,
I have been trying to sign an applet such that I can use the JCA from within
an applet.
My goal is to encrypt a file and then ftp it to a server. I am currently
able to "read" the file from the client's system and then ftp it. I have
created a test certificate and signed the applet grandting it "low"
privileges. I was able to open an input stream on a file without having to
make use of assertPrivilege(...) !
I believe the above was possible because I was invoking a method (which
reads the file and ftps it) on a button click and thus I think the
checkPermission(...) didn't somehow get to the init(...) ot other default
methods. I think this is the case because of the following.
After I had accomplished the above I tried to use the JCA to encrypt the
file. To be able to do so I had to use addProvider(...). This is where I am
facing the problem. I used the applet I developed to achieve the above and
inserted the call to addProvider(..) on the method handling the button
click. I even used the assertPrivilege(...) and revertPrivilege(...)
methods. But I get an exception as follows ---
om.ms.security.SecurityExceptionEx[com/pyrasec/online/pyracrypt/PyraCryptCipher.pyraCryptConnect]
     at com/ms/security/PolicyEngine.deepCheck
     at com/ms/security/PolicyEngine.checkPermission
     at com/ms/security/StandardSecurityManager.chk
     at com/ms/security/StandardSecurityManager.checkSecurityAccess
     at java/security/Security.check
     at java/security/Security.insertProviderAt
     at java/security/Security.addProvider
     at com/pyrasec/online/pyracrypt/PyraCryptCipher.pyraCryptConnect
     at com/pyrasec/online/pyracrypt/PyraCryptGUI.init
     at com/ms/applet/AppletPanel.securedCall0
     at com/ms/applet/AppletPanel.securedCall
     at com/ms/applet/AppletPanel.processSentEvent
     at com/ms/applet/AppletPanel.processSentEvent
     at com/ms/applet/AppletPanel.run
     at java/lang/Thread.run
----- the ABOUT TO ASSERT PERMISSION
PERMISSION ASSERTED are my System.err.printlns.
I initially invoked assertPrivilege(..) using SECURITY Permission ID and
later tried using SYSTEM too. But nothing seems to help. I have read and
re-read the sdkdoc, but just can't come up with any thing I have missed out
on.
Could any one help me here, please. I saw someone suggest on the newsgroup
at the java.sun site to sign the applet. He ssemed pretty confident that the
above stack trace is a result running an unsigned applet. But after all that
I have tried I no longer think so.
What did i have to do to solve this problem ?
Thanks
Ralf

Security is very different for different combinations of web browser and/or Java Plugin. In most cases (unless you are using Plugin 1.3+) you have to have import your certificate into trusted area of your browser/plugin and only then your signature will enable those features.

How to resolve problems in policy file of signed Applet

Hi to All,
I want to connect the web site through my Signed Applet which is working as a Proxy server. but i m facing certain problems in my policy file:
this is my policy file :-
grant {
permission java.security.AllPermission "", "";
permission java.net.SocketPermission "http://www.google.com:4321", "connect, accept,resolve";
permission java.security.UnresolvedPermission;
n i got such type of exceptions n my Applet prompt applet not initialized.
Got connection Socket[addr=/192.168.1.232,port=1200,localport=4321]
Reading request...
URI is: http://www.google.com/
Host to contact is: www.google.com at port 80
Got request...
java.security.AccessControlException: access denied (java.net.SocketPermission www.google.com resolve)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
at java.security.AccessController.checkPermission(AccessController.java:427)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.SecurityManager.checkConnect(SecurityManager.java:1031)
at java.net.InetAddress.getAllByName0(InetAddress.java:1117)
at java.net.InetAddress.getAllByName0(InetAddress.java:1098)
at java.net.InetAddress.getAllByName(InetAddress.java:1061)
at java.net.InetAddress.getByName(InetAddress.java:958)
at java.net.InetSocketAddress.<init>(InetSocketAddress.java:124)
at java.net.Socket.<init>(Socket.java:179)
at ProxyApplet.handle(ProxyApplet.java:75)
at ProxyApplet.<init>(ProxyApplet.java:132)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at java.lang.Class.newInstance0(Class.java:350)
at java.lang.Class.newInstance(Class.java:303)
at sun.applet.AppletPanel.createApplet(AppletPanel.java:721)
at sun.applet.AppletPanel.runLoader(AppletPanel.java:650)
at sun.applet.AppletPanel.run(AppletPanel.java:324)
at java.lang.Thread.run(Thread.java:595)
here 4321 is Port no. which i've as a random port no.
plz Help
thnx in advance
with regards
pank_naini

Please, if you can't help me, could you tell me who can I contact ?

IS there code to avoid policy file push in a VeriSign Signed applet?

Q: Must a digtally signed ( thus Trusted) Applet have some some security code scripts -within the applet- to read specific "out of SandBox Permission" which have been Granted in the users Java.Policy file.
Actually at first I thought the applet was not finding the users Java.Policy file so I hard coded the permission below into the standard java.policy file just to test it but no luck.
I have the following Java Applet code which is digitally signed against a Versigin Class3 Code Signing Certificate in the Trusted root. SO I kow the applet runs..
import java.awt.*;
import java.io.*;
import java.lang.*;
import java.applet.*;
public class UserName extends Applet {
public void init() {
public String runajacode()
String UserName="";
try {
UserName = System.getProperty("user.name");
catch (SecurityException e) {
return UserName;
I Keep getting the security exception error when I try to read User.name property
Here is the text of the Java.Policy file which is placed in the users home directory
/* AUTOMATICALLY GENERATED ON Fri May 10 11:37:28 CDT 2002*/
/* DO NOT EDIT */
grant {
permission java.util.PropertyPermission "user.name", "read";
Thanks BeforeHand
AJ

We cannot use the Java Plugin (company Rules) so you
are saying I must modify the original java.policy
file and without the Plugin the IE 5.5 VM will notWell, i have to say that if u r not using the java plugin, then there is no need for the policy file and u have to use the VM of the browser.I dont think the browser will support the latest version of java and so u have to write your code according the java 1.0 version. Mircosoft have not updated their java jvm due to issues with sun.
Can u give me the code of the html file where u include the applet tags and let me have a look at it.
if u plan to use the applet in IE and signed, then u have to use the CAB file utility which can be downloaded from the microsofft site. A signed cab file can run on IE only.Signed Jar can be run in plugins and netscape .
Let me know if u need further help.
ciao

Signed applets (are policy files needed!)

I have experienced on a number of different machines that a signed applet that the client trusts (via clicking on yes to the prompt asking to trust the applet), is able to access the local resources with NO policy file on the client machine. I'm using JRE 1.4.1_02
Is this the expected behavior?
I sure hope it is because how in the world can you install applications to many clients and update their policy file? you can't via the web! BUT why am I reading that you have to have a policy file even if you sign an applet. I want to get rid of using Netscape security model but I can not update many client machine policy files... Please help!!! thanks. Is signing an applet all you have to do to access local machines, I sure hope so! Thanks in advance.

I've done some more research specifically a very good article at http://developer.java.sun.com/developer/technicalArticles/Security/applets/index.html. I'll try to highlight the more interesting comments that I found. At least for the JRE 1.3 there appears to be a new class loader, sun.plugin.security.PluginClassLoader that allows a signed jar file (once trusted by the client) to have access to local resources.
Code signed using the private key of the signer can be run on client machines once the public key corresponding to the signer is deemed as trusted on the respective machine.
Applet security in browsers strives to prevent untrusted applets from performing potentially dangerous operations, while simultaneously allowing optimal access to trusted applets.
There is no simply way to deploy and use customized policy files, a policy will have to be set by files based on the JRE installation. Customized class loaders or security managers cannot be installed easily.
Policy files are difficult or at least not very straightforward for normal users, which could be thousands of machines where an applet is deployed.
The java plug-in (I believe its 1.3 and later) provides a workaround although its recommended to use policy files wherever practical and applicable. (This implies to me that using the plug-in, all that is required is to sign the jar file to have access to local resources).
RSA-signed applets can be deployed using the Java plug-in. (which can run in an identical way for Netscape and IE).
In order for a plug-in enhanced browser to trust an applet and grant it all privileges or a set of fine-grained permissions (as specified in a J2EE policy file), the user has to preconfigure his or her cache of trusted signer certificates (the .keystore file in JRE 1.3) to add the applet's signer to it. However, this solution does not scale well if the applet needs to be deployed on thousands of client machines, and may not always be feasible because users may not know in advance who signed the applet that they are trying to run. A NEW CLASS LOADER, sun.plugin.security.PluginClassLoader in the Java Plug-in 1.3, OVERCOMES THE LIMITATIONS MENTIONED ABOVE.
I hope this helps, I've been looking for this solution for quite some time, trying to understand why singed applets work with no policy files for version 1.4... Talk to you later, Jay.

Self sign applet without doing any change in policy file at client end

Hi all,
I developed an applet which make some webservice calls,
I have given following permission in policy file at client end
grant codeBase "http://nta2311:7001/-" {
permission java.lang.RuntimePermission "createClassLoader";
permission java.lang.RuntimePermission "getClassLoader";
permission java.util.PropertyPermission "*", "read, write";
permission java.net.SocketPermission "*", "connect, resolve";
with these settings applet is working fine
Now I want to make applet signed in order to avoid policy file modifications
for testing I want to self sign it
please help me

Signing applets:
http://forum.java.sun.com/thread.jsp?forum=63&thread=524815
second post and reply 18 for the java class file using doprivileged
http://forum.java.sun.com/thread.jsp?forum=63&thread=409341
4th post explaining how to set up your own policy with your own keystore
Still problems?
A Full trace might help us out:
http://forum.java.sun.com/thread.jspa?threadID=656028

Signed applets called from javascript - how/where to load policy file?

I'm running into some apparently well-known problems with signed applets accessing a client machine's hard drive.
So, I can get things to work if I place the following two lines in my 'local' JDK installation:
permission java.io.FilePermission "${user.home}/x.properties", "read,write";
permission java.util.PropertyPermission "user.home", "read";These let me a) read the user's home directory and b) read/write a file that's located there.
What I don't want to do is edit the java.policy file, but I'm having problems loading a separate policy file. The app server we run with our product is jetty, and I'm assuming I would be passing in the '-Djava.security.policy=='filename' with the other jetty start-up parameters- is this a correct assumption? And, what path do I give for the file, will I need to put it somewhere in the .war file we distribute, or in the JDK installation on the server? If it's on the server, will client machine's know about these extra rights?
I'd REALLY appreciate any help I could get on this...
thanks in advance,
+0^^

Maybe you didn't realize but my previous post was sarcastically ment:
"hello SUN security stop bugging me in writhing this malicious program"
and
"hello SUN security, I'm a good boy now trust what I'm doing"
Are in a practical sense exactly the same.
SUN should either remove the stack check or the doprivileged. The stack check takes up
valuable resources for nothing since a malicious program can easily circumvent that.
Your post about a malicious user abusing your (CA) signed applet to ruine someone's
system is correct, it would not be difficult. A CA signed applet will not even ask a user to
trust or not. This is one of the reasons we have the usepolicy in affect, but this cannot be
used on "grandma's old PC" since it's too complicated for users to do such things.
YOU seem to be the one to blame, not the hacker! (The user accepted YOUR
certificate!).Actually you are to blame, because you made software that exposes a vonurability
other people can take advantage of.
what you can do before calling the doprivileged private method is check the call stack.
So your signed applet has a public method checking the callstack, if this lookes OK
that method will call the private doprivileged method.
Here is the example
package t;
import java.util.Properties;
import java.applet.Applet;
public class test extends Applet {
         public test(){
               startingPrivileged();
         public void startingPrivileged(){
               System.out.println("this is the stack");
               try{
                    throw new Exception("get the call stack");
               }catch(Exception e){
                    StackTraceElement stack[] = e.getStackTrace();
                    for (int i=0; i<stack.length; i++) {
                         System.out.println("file: " + stack.getFileName() + " method: " + stack[i].getMethodName() + " class: " + stack[i].getClassName() + " at " + new Integer(i).toString());
                    // this is a really simple check to see if this method was started from the t. package
                    // a good hacker can just create it's own package named t and take advantage of this method
                    // if this method was started from the same package there is no reason to make this method
                    // public, protected would work.
                    // there must be a better way to check if this method was called by "your" or "trusted" code
                    if(stack[1].getClassName().startsWith("t.")){
                         dosomePrivileged();
          private void dosomePrivileged(){
               System.out.println("this is the method that does privileged stuff");
     public static void main(String args[]) {
          new test();

How can I access the Server file system without using any signed applet?

Is it possible for me to run an applet on the client machine such that the client can view my server file system and perform uploading and downloading of files through the applet without signing the applet?

Add the following in your java.policy file, your plug in accesses.
grant {
permission java.permission.AllPermission;

File Access with unsigned Applet through editing the java.policy file

I'am starting to lose my hair on this...
I am trying to get an applet to run so that it can access the file system to move files on my local maschin. Because this applet is only running on my VM i can change the java.policy to avoid the signing of the applet.
first of all, if i wrote in the java.policy file
grant {
permission java.security.AllPermission;
};everything is working perfekt.
But I have not the intention to open the gates for any applet out there, so i want to limit the access to my applet. With every of the following versions I get at best an
java.security.AccessControlException: access denied (java.io.FilePermission...
My Setup
My Java Version: jre1.6.0_02
My applet is located unter the url
http://admin.mydomain.com/applet.jar
In Html i tryed the following different versions of loading the applet - none worked
<applet codebase="http://admin.mydomain.com/" name="shortcut" code="start.class" archive="applet.jar" width="0" height="0"></applet>
<applet codebase="http://admin.mydomain.com" name="shortcut" code="start.class" archive="applet.jar" width="0" height="0"></applet>
<applet name="shortcut" code="start.class" archive="http://admin.mydomain.com/applet.jar" width="0" height="0"></applet>in java.policy i tryed following versions with every html applet load version
grant codeBase "http://admin.x-press.de/-" {
permission java.security.AllPermission;
grant codeBase "http://admin.x-press.de/+" {
permission java.security.AllPermission;
grant codeBase "http://admin.x-press.de/applet.jar" {
permission java.security.AllPermission;
};why is it with
grant {
permission java.security.AllPermission;
};working, and not with the other versions?
i am almost bold now, please try to save my last hair from falling down.
any suggestion would be nice
thanks, feyyaz
Message was edited by:
feyyazdogu

I read the mentioned documentation and your right, some of my versions were wrong, but after reading the doumentation again i came to following result which should had worked but didn't.
java.policy
grant codeBase "http://admin.mydomain.com/*" {
permission java.security.AllPermission;
HTML File
<applet codebase="http://admin.mydomain.com/" name="shortcut" code="start.class" archive="applet.jar" height="0" width="0"></applet>if I am entering http://admin.mydomain.com/applet.jar i can download the jar, so the archive lays in the correct directory.
what i am doing wrong? do i have to change an additional file somewhere else?

Question about Java Applet Jar file signing.

These questions pertain to Java 6 Standard Edition 1.6.0_22-b04 and later.
I have gone through the Oracle Java Tutorial for generate public and private key information
to sign a jar file, and how to sign the jar itself, all at
[http://java.sun.com/developer/onlineTraining/Programming/JDCBook/signed.html|http://java.sun.com/developer/onlineTraining/Programming/JDCBook/signed.html]
, and seek some clarification on the following related questions:
-In order to "escape" the java applet sandbox that exists around the client's
copy of the applet running in their web browser, ie.
(something forbidden by default), is verification of the signed applet enough, or is a policy file required
to stipulate these details?
-using the policytool policy file generator, what do I need to add under "Principals"
(if anything) when dealing with a Java applet? Are Codebase and SignedBy simply author information?
-If I choose to use a java.security.Permission subclass object set up in equivalent fashion within the Applet,
which class within the Applet jar do I instantiate that object in? Does it need to be mentioned
in the applet's jar Manifest.MF file?
-Is the "keystore database" a java language service/process which runs in
the Server's memory and is simply accessed and started by default
by the client verifier program (appletview/web browser)?
-The public key certificate file (*.cer) is put in the webserver directory holding
the Applet jar file (ie. Apache Tomcat, for example).
-Presumably, the web browser detects the signed jar
and certificate file, and provides the browser pop up menu asking the user
about a new, non recognised certificate (initially).
Is this so?
-With this being the case, can the applet now escape
the sandbox, be it with or without the stipulated
policy permissions?

848439 wrote:
-In order to "escape" the java applet sandbox that exists around the client's
copy of the applet running in their web browser, ie.
(something forbidden by default), is verification of the signed applet enough, or is a policy file required
to stipulate these details?Just sign the applet, the policy file is not necessary.
-Is the "keystore database" a java language service/process which runs in
the Server's memory and is simply accessed and started by default
by the client verifier program (appletview/web browser)?No.
-The public key certificate file (*.cer) is put in the webserver directory holding
the Applet jar file (ie. Apache Tomcat, for example).No. For a signed Jar, all the information is contained inside the Jar.
-Presumably, the web browser detects the signed jar
and certificate file, and provides the browser pop up menu asking the user
about a new, non recognised certificate (initially).
Is this so?No. It is the JVM that determines when to pop the confirmation dialog.
-With this being the case, can the applet now escape
the sandbox, ..Assuming the end-user OK's the trust prompt, yes.
..be it with or without the stipulated
policy permissions?Huh?

How to sign java applet policy to end user?

i have putted my applet class on server, i want all end users can access it on server, how to sign the java.policy to there JRE?
can anyone help me?

I found this some where else. It shows how to sign an applet.
START OF DOC
How To Sign a Java Applet
The purpose of this document is to document the steps required to sign and use an
applet using a self-signed cert or CA authorized in the JDK 1.3 plugin.
The original 9 steps of this process were posted by user irene67 on suns message forum:
http://forums.java.sun.com/thread.jsp?forum=63&thread=132769
-----begin irene67's original message -----
These steps describe the creation of a self-signed applet. This is useful for testing purposes. For use of public reachable applets, there will be needed a "real" certificate issued by an authority like VeriSign or Thawte. (See step 10 - no user will import and trust a self-signed applet from an unkown developer).
The applet needs to run in the plugin, as only the plugin is platform- and browser-independent. And without this indepence, it makes no sense to use java...
1. Create your code for the applet as usual.
It is not necessary to set any permissions or use security managers in
the code.
2. Install JDK 1.3
Path for use of the following commands: [jdk 1.3 path]\bin\
(commands are keytool, jar, jarsigner)
Password for the keystore is any password. Only Sun knows why...
perhaps ;-)
3. Generate key: keytool -genkey -keyalg rsa -alias tstkey
Enter keystore password: *******
What is your first and last name?
[Unknown]: Your Name
What is the name of your organizational unit?
[Unknown]: YourUnit
What is the name of your organization?
[Unknown]: YourOrg
What is the name of your City or Locality?
[Unknown]: YourCity
What is the name of your State or Province?
[Unknown]: YS
What is the two-letter country code for this unit?
[Unknown]: US
Is CN=Your Name, OU=YourUnit, O=YourOrg, L=YourCity, ST=YS, C=US
correct?
[no]: yes
(wait...)
Enter key password for tstkey
(RETURN if same as keystore password):
(press [enter])
4. Export key: keytool -export -alias tstkey -file tstcert.crt
Enter keystore password: *******
Certificate stored in file tstcert.crt
5. Create JAR: jar cvf tst.jar tst.class
Add all classes used in your project by typing the classnames in the
same line.
added manifest
adding: tst.class(in = 849) (out= 536)(deflated 36%)
6. Verify JAR: jar tvf tst.jar
Thu Jul 27 12:58:28 GMT+02:00 2000 META-INF/
68 Thu Jul 27 12:58:28 GMT+02:00 2000 META-INF/MANIFEST.MF
849 Thu Jul 27 12:49:04 GMT+02:00 2000 tst.class
7. Sign JAR: jarsigner tst.jar tstkey
Enter Passphrase for keystore: *******
8. Verifiy Signing: jarsigner -verify -verbose -certs tst.jar
130 Thu Jul 27 13:04:12 GMT+02:00 2000 META-INF/MANIFEST.MF
183 Thu Jul 27 13:04:12 GMT+02:00 2000 META-INF/TSTKEY.SF
920 Thu Jul 27 13:04:12 GMT+02:00 2000 META-INF/TSTKEY.RSA
Thu Jul 27 12:58:28 GMT+02:00 2000 META-INF/
smk 849 Thu Jul 27 12:49:04 GMT+02:00 2000 tst.class
X.509, CN=Your Name, OU=YourUnit, O=YourOrg, L=YourCity, ST=YS, C=US
(tstkey)
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.
9. Create HTML-File for use of the Applet by the Sun Plugin 1.3
(recommended to use HTML Converter Version 1.3)
10. (Omitted See Below)
-----end irene67's original message -----
To make the plug-in work for any browser you have two options with the JDK 1.3 plugin.
1) Is to export a cert request using the key tool and send it to a CA verification source like verisign.
When the reponse comes back, import it into the keystore overwriting the original cert for the generated key.
To export request:
keytool -certreg -alias tstkey -file tstcert.req
To import response:
keytool -import -trustcacerts -alias tstkey -file careply.crt
An applet signed with a cert that has been verified by a CA source will automatically be recognized by the plugin.
2) For development or otherwise, you may want to just use your self-signed certificate.
In that case, the JDK 1.3 plugin will recognize all certs that have a root cert located in the JDK 1.3 cacerts keystore.
This means you can import your test certificate into this keystore and have the plugin recognize your jars when you sign them.
To import self-signed certificate into the cacerts keystore, change directory to where the JDK plugin key store is located.
For JDK 1.3.0_02: C:\Program Files\JavaSoft\JRE\1.3.0_02\lib\security
For JDK 1.3.1: C:\Program Files\JavaSoft\JRE\1.3.1\lib\security
Import your self-signed cert into the cacerts keystore:
keytool -import -keystore cacerts -storepass changeit -file tstcert.crt
(the password is literally 'changeit')
Now, regardless of which method you use, the applet should be recognized as coming from a signed jar. The user can choose to activate it if he / she chooses. If your applet uses classes from multiple jars, for example Apache's Xerce's parser, you will need to sign those jars as well to allow them to execute in the client's brower. Otherwise, only the classes coming from the signed jar will work with the java.security.AllPermission setting and all other classes from unsigned jars will run in the sandbox.
NOTE: Unless otherwise specified by the -keystore command in all keytool and jarsigner operations, the keystore file used is named '.keystore' in the user's home directory.
The first time any keystore is accessed (including the default) it will be created and secured with the first password given by the user. There is no way to figure out the password if you forget it, but you can delete the default file and recreate it if necessary. For most operations, using the -keystore command is safer to keep from cluttering or messing up your default keystore.

Signing Applets..Policy File

Similar Messages

Maybe you are looking for