To use the 'jar' command, open an MS-DOS window and navigate to the directory where your classes are stored. Notice that this assumes you have already set up a Path on your machine which allows you to use Java SDK commands from anywhere. The instructions for setting up your Path correctly are contained in chapter 2 of the Murach textbook.
On my machine for this example, I navigate in the DOS window to
C:\My Documents\Baruch\4150\Day14\EmailApplet\classes>
Then I use a jar command which specifies the options, output file name and the files to include:
>jar cfv EmailApplet.jar User.class UserIO.class UserEmailPanel.class EmailApplet.class
(You have to write this all in one line; there is a break above only for the purposes of the Word document layout.) Make sure you preserve case when you list these files, or Java won't be able to find them when it opens the .jar archive.
Once you have created the jar file, you can look at its contents by using 'tf' options:
>jar tf EmailApplet.jar
This will show you the metafiles created for the jar, and the files you added to it.
If you run your HTML file now, you will get a security exception (look in the Java console), and the read/write operations will not be carried out. You need to sign it. But before you can sign it, you need a key.
2. Create a public/private key pair. The command for this is
keytool -genkey
keytool is another SDK utility. It will prompt you for a password to your keystore. The keystore is a file that contains your public/private key-pairs, and the public-keys of others with whom you exchange information. See the documentation in the above link. Don't forget your password! You'll need it again.
You can use any of the options listed in the keytool documentation, but generally all you need is:
keytool -genkey -alias
If you don't specify an alias, it will make a key for you called 'mykey'. This will also work fine.
3. Create a certificate for the key you created in the previous step.
keytool -selfcert -alias
Again, keytool will prompt you for a keystore password and remaining parameters. This certificate is now self-signed by you, meaning that it has not been validated by any third party. This is suitable for demo purposes, and may be acceptable to yourself and those who know you because if there is any doubt that the certificate is really yours they can always call you up and ask you for the digest to verify that it is really you and not some impostor that created the certificate. However, if this applet were to be widely distributed, and you wanted it to be accepted by those who do not know you personally, you would certainly want to pay a modest fee to obtain a certificate that is validated by a trusted certificate authority. The procedure for this is straightforward, but beyond the scope of this simple tutorial.
Finally, you can see the certificates available in your keystore by using the following command:
keytool -list
4. Run jarsigner associate this certificate with the JAR file that contains your applet. You will need to give the name of the public key of the certificate you just created. This creates a digest for each file in your JAR and signs them with your private key. These digests or hashes, the public key, and the certificate will all be included in the "WEB-INF" directory of the JAR.
For my demo, I wanted to make several jars, some signed, some not, and some with signatures, some without, so I needed to use the -signedjar option. If you don't use this option, then the .jar file you are signing will be overwritten with the signed version. After the options, you complete your command line with the name of the file being signed and the alias of the key you want to sign it with. So for example, at one point I used:
jarsigner -signedjar EmailApplet2.jar EmailApplet.jar mykey
You can then check to see that the applet is signed by using the -verify option. It's a good idea also to add the -verbose option, so you can see all the details:
jarsigner -verbose -verify EmailApplet2.jar
Your applet is now signed. The next time you or someone else downloads it in it's page the browser will present a dialog box displaying the credentials you just created for it and asking the user permission to run it. If he/she chooses not to, the applet will throw the same AccessControlException that we saw in the Java Console window the first time we tried to run it in our browser. The difference is that now the user gets to make an informed decision as to whether or not they trust your applet to not harm his/her system.
You will only need to generate the public/private key-pair once, but you may want to automate the steps that create and sign the JAR file, because you will need to repeat those every time you modify anything in your code. Remember to update your HTML ARCHIVE command to point to the right .jar file, so that your web page tries to load the applet that is actually signed.
Be careful how you specify the destination for the file to be written in your Java IO class. If you only use the file name, the file will be written at the user 'home', which in the case of my machine is the Desktop.
2 comments:
nice
Amazing ! This is the best description that I have found so far that completely describes all the steps to create signed applet. I will follow the process as you have explained. Thanks for this brilliant explanation.
digital certificate
Post a Comment