Hi Tim,
Thanks for the informative response! After reading through it a couple
times, it seems to me I have two options in the domain topology I am working
with. Currently I have a single DAS which is used to command a bunch of
node-agents, each of which starts / stops a single, stand-alone server
instance (non-clustered). I'll either have to:
1) go and install my certificate on each server-instance just after I have
created it (via the node-agent) but prior to deploying my EAR (including
app-client) or...
2) go around to each instance just after I have deployed the EAR, sign the
generated app-client jar and appserv-jwsacc.jar, then I'm all set.
It seems to me that option 1 is preferrable since I'll (hopefully) only have
to visit each server-instance once after the node-agent first creates it.
Option 2 would mean I have to visit each node everytime I update the
app-client or add a new app-client (yuck).
The problem now is...how do I install my certificate on node-agent created
server-instances so that the jars are siged with that one and not the
auto-generated self-signed cert?
Thanks so much for your help!
John
John Stalker wrote:
> Hi there,
> Does anyone know if the aforementioned jar is pushed out to server
> instances created by node agents if it is deployed in a DAS? I
> imagine it could happen if the server instances are in a cluster, but
> what about stand alone instances? Does one have to go around to these
> installations after they are created to sign that jar?
Short answer, no (the JAR is not actually pushed out) and no (you don't
need to do anything).
Long answer: GlassFish does this for you but not by pushing out the
signed JAR. The GlassFish distribution includes an unsigned version of
appserv-jwsacc.jar in the ${install-dir}/lib directory. This includes
the DAS as well as any remote instances for which you install the
GlassFish bits. In response to a request to any instance to launch an
app client using Java Web Start, GlassFish will look for the signed
version of that JAR in a known location
(${domain-dir}/java-web-start/). It will not be there for the very
first launch after a new GlassFish installation, so GlassFish will
automatically create it, signing it with the default cert from the
keystore. This happens on any instance asked to launch an app client
via Java Web Start.
> Sort of related, should all the other jars participating in the
> web-start distributed app-client (ie my jars and 3rd party ones) be
> signed before being packaged and deployed?
That deserves a two-part answer:
In GlassFish v2 that's not necessary although you can do so if you
wish. In v2 GlassFish distributes the app client and the library JARs
in a single, generated app client JAR file. GlassFish signs that JAR,
by default using the default cert from the keystore. If you don't want
end-users to be prompted to trust that cert you can yourself sign the
generated app client JAR after you deploy the app containing the client,
using your own cert that either has a trusted certificate authority or
is one that your users will be comfortable trusting. The same is true,
by the way, for the signed appserv-jwsacc.jar file - you can create a
signed copy using your own cert in the directory I mentioned before. If
you do this after you install GlassFish on that system but before that
system is asked to respond to a Java Web Start launch request, GlassFish
will find and use the copy you created when it looks for the signed file.
GlassFish v3 (once app client support becomes available after the "v3
prelude" release) might work differently. For a number of reasons we
are looking at identifying each JAR file individually in the generated
JNLP document that describes the client and the JARs it needs.
(Remember v2 uses a single generated app client JAR which contains the
actual app client JAR and any library JARs.) If we do that then
GlassFish might *not* sign all those individual JARs itself, or perhaps
it would sign automatically only the JARs that are not already signed.
That way the Java Web Start security model could be in force on each of
the JARs separately which is much closer to the normal Java Web Start
approach. Because Java Web Start prompts the user about whether to
trust each different cert used to sign JARs (that is, unless the cert
has a trusted CA chain) in that case you might want to sign the JARs
yourself, using your own cert.
Sorry for the long answer but I thought it was worth highlighting how
this might be changing for v3.
- Tim
>
> Thanks!
> John
>
> Reference:
> http://java.sun.com/developer/technicalArticles/J2EE/jws-glassfish/part4.html#1
> http://blogs.sun.com/quinn/resource/signedJarsUserWriteup.html