This is a big and complicated subject.  I'll just touch on some issues here.  I'm almost certainly wrong in many places, so you'll have to correct me if I'm wrong.

--[JanneJalkanen]

!!JDK1.1

A very comprehensive document is at [http://www.suitable.com/Doc_CodeSigning.shtml].  Basically, you'll need to sign your code separately for Internet Explorer and Netscape, and also use their own APIs to request access to resources.  This means that in most cases, you have to write separate applets (or at least separate code) for each browser.

!!JDK1.2, aka Java 2

Since neither Netscape nor Microsoft browsers support their own [Java] enviroment above JDK1.1 API, Sun Microsystems created a [Java plugin] for JDK 1.2.  JDK 1.2 enhanced the Java security API bringing in lots of granularity on the whole thing, including a standard way to sign applets.  This also meant that the old, JDK 1.1 code signing conventions were thrown out of the window.

Note that signing an applet is equal to signing JAR files in most cases.

You have two choices:

# Get a certificate from a [Certificate Authority], such as Thawte, Verisign, etc.
# Create and sign a certificate yourself, then sign the applet with that.

The advantage with a real certificate is that the browser plugin will automatically recognise it, and when the applet attempts to do something it requires your permission to do, the user will see a dialog asking for permission.

However, with a self-signed certificate you'll need to have the user create an entry in the policy file, stating that the JVM is allowed to execute code signed by you.

Unfortunately, this means that self-signed applets are pretty much useless if you plan to deploy java applets in a corporate intranet, unless you want to go to every user's machine and install a policy file.  Which sort of defeats the purpose of having an applet in the first place...

The [Java Developer Connection|http://developer.java.sun.com] gives a 
[pretty good walkthrough|http://developer.java.sun.com/developer/technicalArticles/Security/Signed/]
for signing applets.

----

!A shortcut

Instead of going through the pain of signing an applet, you could just distribute a policy file that would grant permission to any applet loaded from a standard location within your intranet.  If your intranet is secure, this should pose no problem. 

----

!Another view

Forget applets, use [JavaWebStart|http://java.sun.com/products/javawebstart/]. Information about JavaWebStart [Architecture|http://java.sun.com/products/javawebstart/architecture.html].

-- [Tuomasp]