Some of the details of the Java Web Start support in GlassFish have changed. You can still launch any app client you deploy using Java Web Start, so that this outward behavior has not changed. But what happens inside the app server has evolved, and you have some new options for controlling some of that processing.
Basically, we are trying to help end-users protect themselves even more vigorously from the risks of downloading programs over the network, which is after all what the Java Web Start feature of GlassFish does. Very briefly, two types of jar files downloaded via Java Web Start from the app server are now always delivered in signed form:
the appserv-jwsacc.jar (which contains key parts of the app client container that actually executes an app client), and
the generated app client jar files (which contain the contents of the original app client jar from the developer plus some additional information needed to run the client correctly).
The app server will sign them automatically for you using a self-signed certificate that is created any time you create a new app server domain. This auto-signing behavior is very convenient in a development environment since it requires you to do no additional set-up. But the default auto-signing behavior it is not very secure, because anyone can create a self-signed cert claiming to be anyone. In fact, this is why Java Web Start warns you, when it downloads a jar signed with a self-signed certificate, that the cert is invalid. The end-user can still choose to run the downloaded code, but at his or her own risk.
If you have your own certificate, you can arrange for the app server to use it instead of the domain's self-signed certificate in this auto-signing mechanism. If your certificate is in a trusted chain to a certificate authority, then your end-users can be much more confident that the code is trustworthy.
In either case, the auto-signing behavior signs every jar file with the same cert. If you want to, you can manually sign individual jars with different certs.
The steps to trigger the non-default behavior – either to have the app server auto-sign the jars with your cert or for you to sign the jars manually – are actually fairly simple, but there's some important background information that you'd need. I have written up this rough document that tries to explain this. The content will probably form the basis for the product documentation for this aspect of the Java Web Start feature, so I would very much appreciate any feedback people have on the description as well as the feature itself. I already know of several ways in which I would like to improve the overall process, but I'd love to hear what others have to say.

Posted by Augusto Cesar Righetto on April 24, 2006 at 06:24 PM CDT #
Posted by Tim Quinn on April 25, 2006 at 08:40 PM CDT #
Posted by Ignacio Goyeneche on May 09, 2006 at 07:02 AM CDT #
Posted by Tim Quinn on May 15, 2006 at 06:32 AM CDT #
Posted by Tim Quinn on August 16, 2006 at 08:52 AM CDT #