Please tell me if the following set of statements taken together is
true.

When you initiate an HTTPS connection via the JDK, the SSL handshake
dance commences.  A certificate is offered up to the client by the
server endpoint of the connection.  The client must then determine
whether to trust the certificate.  It does so by looking in its
configured keystore, which is cacerts by default.  If the certificate
itself, or if the chain of other certificates that vouch for it, is in
this database, then the handshake completes and everyone is happy.  If
the certificate or its "vouchers" is not in the cacerts database, then
you get an exception.

Therefore, if I am getting a "no trusted certificate found" exception,
the problem MUST lie in the keystore/cacerts database configured for
the current VM.

(And finally, a corollary:)

There is one configured keystore per VM.  Its location may be set via a
system property whose name escapes me at the moment; I think it's
something like javax.net.ssl.keystore.  One cannot set a keystore per
connection or anything like that.

Yes?

I ask the question because we are seeing a certificate be accepted just
fine when we run on one server, and be rejected when run on another.
The code and runtime environments are identical.  The one thing I can't
vouch for is the trust store in both places.  However, I *can* vouch
for the fact that the certificate in question is vouched for by
Verisign, and I was under the impression that Verisign's stuff was
shipped by default as part of the JDK; hence no manual importing would
be needed.

(For whatever it's worth, this is on a JBoss 3.2.6/Tomcat setup; my
current working hypothesis is that setting the keystore on Tomcat
incorrectly sets the *VM wide* notion of where the keystore is, so that
an EJB later on--from which my HTTPS connection is initiating--is
referring to a rather anemic keystore.  This is just a wild hunch.)

Thanks,
Laird