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):
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.
Re: How to sign an applet (and get it to work)
Oct 2, 2001 1:16 PM
(reply 2
of 63) (In reply to
#1 )
To sign a jar you need both a public key and a private key. The certificate you imported is effectively the public key. If you create a new keystore and import the certificate you will still be missing the private key.
This is why you need to generate a key first, export a request to a CA verification source, and import the response. The response effectively overwrites your public key and keeps your private key the same.
If you need to use your key to sign jars on another machine, copy the keystore file instead of just the cert and it should work for you.
You can tell the difference in the keystore listing between a cert and a key by looking for the keyword 'keyEntry'
Public Certificates are marked as: trustedCertEntry
Full keys that can be used to sign are: keyEntry
I am wondering...whether i need to ask my users to change their policy files if i want my applet access their local drives? I have already setup a self-signed certificate and imported it to my users' machine.
It seems to me that self-signed applets still can't access local drives unless the client change their policy file. Is this correct?
Many thanks in advance.
If the jar the applet comes from is signed, the user should see the screen allowing them to grant all permissions to the applet.
If the user 'oks' the applet, all rights are given to the applet. However, if the applet uses classes in more than one jar, all the jars must be signed for all the classes to have full permissions; otherwise, classes in unsigned jars will be will be restricted by the security manager.
Policy files should not be necessary. When all the applet's jars are signed correctly, and the user grants the applet rights to run, the applet will have all permissions granted to it.
One query: My applet is self signed. It is signed by jdk 1.1.7. At the client side, it is verified using JDK 1.1.7 also. I have 3 questions in this scenario:
1. Is there some way to avoid installing the plug-in at the client??
2. At the client side, the user of this intranet application needs to manually import the certificate in his keystore using javakey -import. Is there a possibility of the applet handling this itself i.e. when the applet is downloaded, the certificate gets imported into the client's keystore automatically??
3. Is there any problem with permanently using self signed certificates in an intranet application?
1) Without using the plug-in, you need to use browser based security. Both Netscape and IE have different ways of granting security rights and have different requirements of certificates. You would need to get different tools from Microsoft and Netscape (similar to the security tools that come with the jdk like keytool) to generate those keys. The plug-in allows the ability to sign an applet that will work in both browsers. The plug-in is the easiest thing to use and guarantees the JVM environment is compatible with sun, but if this app is for an intranet you can probably deal with a few browser specific quirks. Here is a site that explains more about browser specific security:
http://www.suitable.com/Doc_CodeSigning.shtml
2) JDK 1.1 was fundamentally flawed in that it can't distribute certificates. There are a couple of solutions (hacks) around this problem people have come up with.
This link will explain more about how to distribute your 1.1 certificates:
3) There is no problem using self-signed certificates in an intranet as long as every user on the intranet has there keystore updated with your certificate. (see the url in response 2 for more information)
i'm well had been step 9 that i nothing meet the matter
but step 10 error occuring............
i'm Linux platfom and i have Client directory access case by browser
===================================================================
step 10.
Keytool -certreg -alias tstkey -file tstcert.req excute after
enter keystore password : xxxxx ;
after..... occuring the matter....
To import response:
keytool -import -trustcacerts -alias tstkey -file careply.crt
====================================================================>
keytool error : java.io.FileNotFoundException: careply.crt (No such file or directory)
because i not Certificate browse..........
please!! help me..
First of all, sorry for my English (since im spanish...)
I've followed the 10 steps 4 sign an applet for the plug in 1.2
but when I open the HTML locally or from a HTTP server, (IE5.5, W98), the plugin 1.2 loads
and start loading classes, but it pop up this exception:
( Im translating the following from spanish, so it may differ from
english version of plugin :)
Java Module security adv.<<<<
"Its imposible to verify the cert. Code will be used as not signed"
And a exception stack for:
"java.security.cert.CertificateException: Unable to verify the cert. with root CA"
First of all, sorry for my English (since im spanish...)
I've followed the 10 steps 4 sign an applet for the plug in 1.2
but when I open the HTML locally or from a HTTP server, (IE5.5, W98), the plugin 1.2 loads
and start loading classes, but it pop up this exception:
( Im translating the following from spanish, so it may differ from
english version of plugin :)
Java Module security adv.<<<<
"Its imposible to verify the cert. Code will be used as not signed"
And a exception stack for:
"java.security.cert.CertificateException: Unable to verify the cert. with root CA"
The plug-in needs to have the certificate corresponding to the key you signed your jar with in it's trusted keystore. Any jar signed with a certificate that is verified by Verisign or Thawte will automatically be recognized because Verisign and Thawte are considered to be root CAs (Certificate Authorities).
For example, you authenticate your code is yours by signing it, but the plug-in does not know who you are. Therefore, if another entity such as Verisign verifies you are who you say you are, the plug-in will recognize you.
If you want to self-certify your applet, you need to make the plug-in trust your signature like it would a Root CA. The JDK 1.3 plug-in has a keystore in which it hold certificates to all root CAs. If your certificate was added to it, the plug-in would recognize you.
However, JDK 1.1 & JDK 1.2 are a little different then JDK 1.3. To make the JDK 1.2 plug-in work you could try what I read on another website: http://java.sun.com/products/plugin/1.2/docs/netscape.html
My understanding is the JDK 1.2 plug-in verifies Root CA certificates are valid based on what your browser determines is a root CA. Therefore, if you export your cert to a file and import it with explorer, MS Internet Explorer should now consider your signature to be a root CA and your applet should work in the plug-in the next time you restart your browser.
Here is another site that specifically deals with the JDK 1.2 plug-in and how to get it to work with a self-signed certificate: http://java.sun.com/security/signExample12
I did followed your list of instructions. It worked well and now I am getting the question to let my applet work. But after I got a Security Exception, access denied. I try to use my applet to read and write a FoxPro table from the Active Desktop. I also tried to modify the Policy file, but the result is the same. Do you have any ideas what I did wrong?
This topic has
63
replies
on
5
pages.
1
|
2
|
3
|
4
|
5
|
Next »
Email this Topic
Edit this Topic
