signed Applets : Java Glossary

*0-9ABCDEFGHIJKLMNOPQRSTUVWXYZ (all)
The JDisplay Java Applet displays the large program listings on this web page. JDisplay requires an up-to-date browser and Java version 1.7+, preferably 1.8.0_25. If you can’t see the listings, or if you just want to learn more about JDisplay, click  here for help. Use Chrome for best results.

signed Applets

Signed Applets are a technique of adding a digital signature to an Applet to prove that it came untampered from a particular trusted author. Signed Applets can be given more privileges that ordinary Applets. They even allow someone finding a jar file floating about the Internet to know that file is what it purports to be, even without checking with the author’s website.

Signed Applets are potentially dangerous. They have power to potentially damage your machine, e.g erase all your files or format your hard disk, or post your diary on LiveJournal. Just because an Applet is signed does not make it safe. Anyone, even a terrorist, can write a signed Applet. There are many schemes for signing and OKing signed Applets to run on your machine. I will concentrate on the most recent scheme.

RSA Creating A Signed Applet Java Web Start
java.policy Avoiding Signed Applets Revoking Perpetual Grant
.keystore Tutorials and Documentation Tips For Obsolete Schemes
cacerts Tame vs Wild Applets Learning More
Java 1.3 Signed Applet Jars Links
When Do You Need to Sign? Signed Applet Tips

Sun Plugin 1.3+ RSA (Rivest, Shamir and Adelman) Plug-in Style Applet Signing

This is the standard signing scheme, for Java version 1.3 and up.

This signing schemes uses a policy file where the system administrator pre clears certain dangerous Applets to run without asking the user. It is supported by Opera, Firefox, SeaMonkey and IE (Internet Explorer). Permission can also be a simple go/no go user grant, or individual permissions to do a variety of dangerous deeds.

Unless you are forced to support other styles of signing at gunpoint, I suggest you ignore every signing scheme but his one. Demand your clients upgrade to recent browsers that support the latest Sun JVM (Java Virtual Machine). Here is the basic recipe for making your Applet work with Sun-style signing:

  1. Buy a Sun Java Code Signing certificate from Thawte. You use keytool to create your certificate request. You then send the public key part of your certificate to Thawte for them to digitally sign as authentic and return to you. You don’t disclose your private key to Thawte.
  2. Alternatively, after reading my warnings, you can create a free phony certificate using keytool.
  3. Write your Applet as normal Java code. You don’t need to include any special permission-asking code. Just go ahead and do naughty things like read the local hard disk or talk to servers other than mother. Normally, your Applet just goes ahead and does what it wants, without any sort of pre-check. If it gets a SecurityException, it catches the exception and does its best to carry on. A signed Applet that was not granted permission can still do useful work, recovering from SecurityException exception after SecurityException the way Wassup does. However, if you want to avoid SecurityExceptions in the middle of your application code, you can do probes like this to see if you have permission:
  4. Then build your Applet as normal in a jar using jar.exe.
  5. Then sign your jar using jarsigner.
  6. If you want others to be able to use your Applet without hassle they must import your phony cert into their browsers as an officially accepted cert. This is not strictly necessary, but if you don’t do this, Sun will disparage your Applet and discourage users from granting it permission. For real certs you can skip this step so long at the browser has the root cert for the signing authority installed.
  7. You might consider adjusting the policy file at client sites to either give your Applet permission to run without having to OK it each time, or to control precisely what is it allowed to do, in terms of where on disk it can write, and just what naughty things it is allowed to do. You, as programmer, don’t control your client’s policy files. Typically some site administrator bureaucrat does and he puts the same policy files on nearly every desk in the institution.

java.policy

The simplest way to grant extra permission to run is to have the user click grant, for an all or nothing permission. However, there are finer grained methods using the java.policy file. For more information see the Sun documentation on policy-based security. as application programmer, don’t ever directly call their methods. They get called as a side effect of attempting potentially dangerous activity. For Sun style security you need a special Sun style *.cer X.509 certificate. A common policy file for all apps on a machine is stored in J:\Program Files\java\jdk1.8.0_25\ \jre\lib\security\java.policy You can edit java.policy as a text file, or use policytool to edit it. The rules about running all possible apps anywhere on the web have to be encapsulated all in this one place. You can append more grants on the end to handle additional apps, but this change must be made to every workstation potentially to use the new app. Happily you can grant blanket powers to all apps signed by a given certificate, so you don’t need to keep changing the policy file, at least for in-house apps.

It is actually a little more complicated than that. There are three files to be concerned with: J:\Program Files\java\jdk1.8.0_25\ \jre\lib\security\java.security points to the policy files, usually two, one called: J:\Program Files\java\jdk1.8.0_25\ \jre\lib\security\java.policy and the other called user.home/.java.policy. To find out what user.home is, check out the system properties with Wassup. It will be something like C:\Documents and Settings\%username%. And if that was not confusing enough, the JDK (Java Development Kit) has two JRE (Java Runtime Environment) s, the public one in C:\Program Files\java\jre1.8.0_25\ and the debugging one in J:\Program Files\java\jdk1.8.0_25\ \jre each with its own set of policy files.

.keystore

The signing certificates are stored in a common file user.home/.keystore managed using keytool. There is one for each user of the machine. On your clients, this would possibly contain your phony self-signed certificates (the public key portion). There would be no need to install your purchased signing certificates. You only need to install your signing certificates (with private key) on your development machine where you sign your jar files. Of course, your phony certificates(public key only) would also be installed in the .keystore files of your development machines too.

cacerts

The
%JRE64\lib\security\cacerts
They are no longer by default stored in the browsers. You can add to the cacerts. file with keytool using the password changeit, (changeme on the Mac). There is only one cacerts. shared by all users. However, like the java.policy files, there is one cacerts. per JRE.

One common error to make is to change the wrong copy of cacerts., .keystore or java.policy. If you don’t know what you are doing, change them all!

Enhancements in Java version 1.3 or later

trustProxyServer is now by default true, which means websites are no longer required to confirm their DNS (Domain Name Service) name. The rules on matching of the jar signer with a root authority certificate have been relaxed. You can now preload Applets jars into lib/plugin.

When Do You Need to Sign?

Check out the list of restrictions on unsigned Applets. If you don’t need to do any of those things, you don’t need to sign. In general you have to sign if your Applet does anything potentially dangerous like reading or writing the disk, or pestering various servers on the net other than the one it was loaded from.

Overall Process of Creating A Signed Applet

There are many different Applet-signing schemes, but the general flow is as follows:

Avoiding Signed Applets

If you don’t plan to distribute Applets to others, or if you want to postpone the agony for a while, you can avoid the hassles of signing to allow your Applets to do naughty things, by using JDK  1.8.0 and creating a java.policy file in your J:\Program Files\java\jdk1.8.0_25\ \jre\lib\security and C:\Program Files\java\jre1.8.0_25\ \lib\security directories. In those files add these commands:
grant codeBase http://yourservername/* {
permission java.security.AllPermission;
};
grant codeBase file://localhost/C:/yourjavafilesdir/- {
permission java.security.AllPermission;
};

This gives blanket permission to all locally created Applets to do what they please.

Other ways to avoid signing are converting your Applets to applications by adding a main method. See Applet for how. This can be useful for debugging. Get the Applet working as an application first, then worry about Appletness and signing later. Also consider Java Web Start as an alternative to Applets.

Signed Applet Tutorials and Documentation

Happily, there is a wealth of online documentation to read:

Tame vs Wild Applets

A tame Applet is intended to be run by a captive audience, usually within a single corporation. Typically a network administration will do special preparation of all client machines such as installing a certificate or policy file before the Applet can be run. Sometimes the certificate is installed into the browser, sometimes into a separate file. The author typically works for the corporation. The Applet might be signed, self-signed or unsigned. If there are any security decisions to me made to allow the Applet to run, the permissions are granted by the network security administrator ahead of time.

In contrast, a wild Applet is intended to be run by the general public without any special preparation such as installing a certificate or policy file. A wild Applet in one you might just stumble across in your web browsing. You don’t know much about the author. The Applet might be signed, self-signed or unsigned. If there are any security decisions to me made, the browser asks the end user for permission each time the Applet is run, using technobabble.

Some security schemes are aimed at writing tame and others at writing wild Applets. User grant schemes are primarily for wild Applets, where the java.policy schemes are primarily for tame Applets.

Tame schemes typically use an ASCII (American Standard Code for Information Interchange) policy text file that describes all the Applets, users and websites and what permissions each has. It is thus just about impossible for an individual Applet to automatically maintain. It is designed to be maintained by a network administrator who tightly controls just what can be run. The policy files can also control the activities of applications. Most people find it easier to compose the policy file with a text editor than using Oracle’s GUI (Graphic User Interface) policytool.

Tame schemes typically use a certificate file completely separate from the browser’s list of root certificates. This is managed by keytool. Again certificates from all different Applets are merged in this file. This makes it almost impossible for an Applet to manage its certificates. The network administrator must compose and control this file.

Signed Applet Jars

After you have signed your jar, examine it with WinZip. You hould see a directory called META-INF. In there you will see three files with names like

Signed Applet Tips

Using signed Applets, and especially native code in signed Applets, is a little trickier than you might first think, largely because Applets were designed for security, not programmer convenience:
  1. If the end user refuses to grant permission, your Applet will run anyway! It has to soldier on somehow without permission. It can either:
    • Die on a  java.security.AccessControlException leaving people to think your Applet has a bug.
    • Catch the  java.security.AccessControlException and give some explanation for poor performance to the user.
    • Check if the user has granted permission, and if not, chastise the user for lack of trust, and possibly carry on in some degraded mode.
  2. Use a proxy server so that your Applet will talk only to one host, even if two hosts actually service its requests. Then you don’t need a signed Applet.
  3. The policy file is just an ASCII text file. It is quite a bit easier to manipulate it with a text editor than the policytool GUI.
  4. You need to order your digital certificates well in advance. You need to know which kinds to order. You will need a corporate DUNS (Dun & Bradstreet Universal Numbering System) number to apply.
  5. There are many different Applet security/signing schemes, including two for Netscape, two for Internet Explorer, two for Oracle’s Java version 1.1 Plugin, two for Oracle’s  Java version 1.2 Plugin, five for Oracle’s  Java version 1.3 or later Plugin/Web Start and one for the Macintosh. Each kind uses a different type of signing certificate, though there are some multi-purpose certificates you can buy. You have the possibility of self-signed dummy certificates or real ones from Thawte or Verisign. On top of that you have the choice of coarse or fine-grain capabilities. Make sure you are ordering the right kind of code signing certificate. You want a Java version 1.5 code signing certificate.
  6. The Applet must download and install the needed DLLs (Dynamic Link Libraries) and certificates on the client machine in magic directories. This is extremely difficult to do, but a piece of cake with JWS (Java Web Start).
  7. You need to write JNI (Java Native Interface) glue to your native C++/C/ASM code.
  8. Oracle’s JNI tutorials presume Solaris and have no hints on how to handle NT and Windows issues.
  9. Signed Applets take much longer to load because of the CPU-intensive verifying of the signatures of each class. Don’t sign jars just for the heck of it.
  10. You are best to tackle JNI in applications and signed Applets without JNI separately before combining them. For details on how, see JNI.
  11. You can use the Wassup Amanuensis to find out what your browser thinks the user.home directory is and what it is using for a java.class.path and any other system properties.
  12. For the Internet Explorer RSA certificate-based schemes, or with a Thawte DSA (Digital Signature Algorithm) Java Plug-In certificate, you don’t need to install the certificate on the client machine, just sign the jar file with your expensive certificate. The signing authority root certificate that Opera, Firefox, SeaMonkey or Microsoft pre-install in the browser is sufficient to check authenticity of your signed jar. See certificate for more details.
  13. You can create your own free self-signed phony certificates, but then somehow you must pre-install them on the client’s machine. The main time the hassle of self-signed certificates would be practical is if you had control of all the client machines, and were not allowing the general public to use your Applets.
  14. For you to be able to verify jars without installing your signing certificate on all the client machines, there needs to be a chain of trusted authorities and automatic verification of public keys with those authorities. Signed Applets are not magic cloak to protect you from bugs. Any boob can create a phony certificate using the signing tools and sign the Applet with it. (You do this when you are debugging and waiting for your real certificate to arrive.) Further, even a trusted author can write buggy code. See my essay on the general theory of digital certificates based on Steven C. Den Beste’s work.
  15. Java’s impregnable Applet security is a bit like France’s impregnable Maginot line prior to the second world war. Hitler simply went around it. Windows security is Swiss cheese, so it is easy to attack Java from the rear by replacing the various executables with doctored versions.

Java Web Start

Just when you thought you were beginning to understand all this, Sun invented yet another type of sandbox called Java Web Start. JWS apps are usually signed, but they work more like ordinary applications.

Revoking Perpetual Grant

You can get into a situation when Java no longer asks you if you want to grant permission to a signed Applet to do dangerous things. How can you get it to start asking permission again?

  1. Click Start
  2. Click Control Panel
  3. Tlick Programs
  4. Click Java
  5. Under Temporary Internet Files, click Settings
  6. Click Delete Files
  7. Click Security
  8. Click Certificates
  9. Remove certificates you want to start manually granting.

Signed Applet Tips For Obsolete Signing Schemes

  1. If the user of the signed Applet is behind a firewall, for some strange reason, if he invokes the Applet using the IP (Internet Protocol) rather than the DNS name of the website in the codebase e.g CODEBASE="http:// 65.110.21.43 /"" instead of CODEBASE=mindprod.com", all works. Otherwise you get a trustProxy Property error message. This problem may have been fixed.
  2. The fiends who devised these security schemes should be shot. The designs deliberately make it very difficult to write a single piece of code that will work under all security schemes. You pretty well have to maintain three separate versions of your code, one for Netscape, one for Internet Explorer and one for the various versions of the Java Plug-in. Thankfully the older schemes have all but disappeared. It is even hard to find documentation on them any more. Good riddance!
  3. Netscape wants a jar file and IE a cab for its proprietary scheme. Mostly today IE uses the Java version 1.3 or later scheme.
  4. With the Netscape scheme, permission is granted only until the immediate caller of the permission-granting method exits. You can’t introduce even one layer of indirection, or your permissions immediately expire.
  5. Each scheme uses different exceptions, which have to nest neatly with try blocks. You must be careful never to execute any code from another security scheme, because its classes won’t be available. Happily, with Java, you can have calls to such methods in your code, so long as you never actually execute them.
  6. You can create dummy classes and dummy methods so that you can safely call methods from all security schemes. Netscape no longer supports their old scheme.
  7. Beware the catch-22 of not being permitted to examine interesting system properties until you have decided on which security scheme you need to use. You need permission before you can examine the restricted system properties.
  8. To your Netscape prefs.js file add this entry:
    user_pref(signed.applets.codebase_principal_support, true);
  9. Make sure you have the latest JDK. Early versions did not use the cacerts. file.

Learning More

Applet signing is considerably simpler than it used to be now that the obsolete schemes have died away and you don’t have so much conflicting information to digest.
Oracle’s Technote Guide on Security : available:

For a first cut, you can safely ignore all the information on Security Managers. You,
Oracle’s Technote Guide on Security Tools : available:
Oracle’s Technote Guide on Policy File Permissions : available:
Oracle’s Technote Guide on Privileged Blocks : available:
Oracle’s JDK Tool Guide to Jarsigner : available:
Oracle’s Technote Guide on Mixing Signed and Unsigned Code : available:


This page is posted
on the web at:

http://mindprod.com/jgloss/signedapplets.html

Optional Replicator mirror
of mindprod.com
on local hard disk J:

J:\mindprod\jgloss\signedapplets.html
logo
Please the feedback from other visitors, or your own feedback about the site.
Contact Roedy. Please feel free to link to this page without explicit permission.
no blog for this page
IP:[65.110.21.43]
Your face IP:[54.235.29.110]
You are visitor number