I also saw this error and was able to clear it, which gives some ideas about the underlying cause. I'll try to be brief.
First, the solution I used. I deleted my domain and created it again. The next time I launched a client from that domain using Java Web Start it took a while, as does the first launch from any new or newly-installed domain, because GlassFish had to sign several JARs again and store them in its directories. Then Java Web Start on the client had to download all those JARs and verify their signatures. But all that worked and the client launched successfully.
You might be able to accomplish the same thing without recreating your domain. Unfortunately I cannot say for sure that these will work because I used a "bigger hammer" (recreating the domain) already on my system.
A. Cleaning the server side.
1. Deleting the directory ${domainDir}/java-web-start. -- This is where GlassFish stores its signed copies of the GlassFish system files. Deleting the directory forces GlassFish to regenerated those signed JARs. Because these will be newer than what's in any client-side Java Web Start cache, Java Web Start will download them again.
2. Redeploying the application(s) containing the clients. Similarly this will force GlassFish to recreate the signed copies of your application JARs, which in turn will force Java Web Start on the client to download the newly-created signed copies of the app JARs.
OR
B. Clean the client side.
You can, instead, try clearing out the Java Web Start cache on the client. One way is to use
javaws -viewer
You can then navigate to the Java Web Start cache and remove all the GlassFish related content. Be sure to cover not only the GlassFish files listed under the Applications category (there is a drop-list in the upper left corner of the display) but also under the Resources category.
Here is what I think might be happening...
GlassFish signs quite a few JARs in order to comply with the Java Web Start security model (which became stricter in maybe Java SE 1.6.0_17). This includes JARs from GlassFish itself (such as gf-client.jar) and also JARs from your applications.
You can sign your JARs yourself, but you don't have to -- GlassFish will do so for you automatically. These auto-signed JARs (from your application and from GlassFish) are signed with the self-signed certificate that is generated when a domain is created. (This also happens during the GlassFish build so your out-of-the-box domain1 has such a self-signed cert.)
GlassFish stores the signed GlassFish JARs on the server in ${domainDir}/java-web-start/... and stores the auto-signed application JARs in ${domainDir}/generated/xml/(appName)/... (although neither of these locations is officially documented or part of the published interface of GlassFish - so don't count on them always being the same).
A JNLP document, among other things, lists JARs that are needed by an application. Java Web Start requires that all JARs listed in the same JNLP must be either unsigned or all signed by the same certificate.
I suspect that what happened to us is that we got some files in the Java Web Start cache from one domain and/or GlassFish version and therefore were signed by one cert, and some other files signed by other certs. Java Web Start then complained about the different signers of JARs listed in the same JNLP document.
If/when you try any of these techniques, I'd appreciate hearing from you:
a. Which worked and which (if any) didn't.
b. If you can think of a sequence of launching clients on the same client from different versions of GlassFish, installing different versions of GlassFish at different times, etc. Anything that might shed some light on how your environment got into the state in which this happened.
In my case, I routinely run against various different versions and builds of GlassFish. Usually, I go "forwards" in time, meaning that my Java Web Start cache contains more and more recent files because I am launching from more and more recent builds of GlassFish. But, when I tried testing a simple app today against my 3.0.1 installation, I suspect the cached JARs were from a 3.1 build (and therefore had later dates than my old 3.0.1 installation) and so Java Web Start planned to use those cached JARs. I had to deploy the test app which means that the auto-signed JARs for it were very recent. And that may have caused the problem on my system, because I had the app JAR signed with one cert but the previously-cached GlassFish JAR signed with another one. And, yes, it's true that the main JNLP that launches your client refers both to a JAR generated when you deploy your app as well as a GlassFish system JAR.
Anyway, I apologize for the long explanation for anyone still reading by now. I hope it helps.
- Tim
[Message sent by forum member 'tjquinn']
http://forums.java.net/jive/thread.jspa?messageID=478601