-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Stephen,
On 11/19/2009 2:42 AM, Stephen . wrote:
> My JAVA folder has 3 different locations which contain the command "KEYTOOL"
>
> I don't even know which of them is supposed to hold the certificate.
None of those hold any certificates: they are just programs that operate
on files called "keystores". A keystore is a specially-formatted file
that contains one or more certificates and keys. You can create a new
one or use an existing one.
Typically, your JVM has a system-level keystore installed that contains
all of the special top-level certificates from the big guys like
VeriSign and Thawte. That allows your JVM to trust certificates "signed"
by those certificate authorities. X.509 (which is what all this stuff is
defined as) is built on a "tree of trust" where a small number of
implicitly-trusted entities (VeriSign, Thawte, etc.) are allowed to
dictate who is and who is not trusted on the web via these certificates.
It's a great racket.
> Yesterday, just to be on the safe side, I imported my certificate into
> ALL 3 locations (under 3 different aliases)
The real question was which keystore you were operating on. From the
'keytool' manual page:
"
Each keytool command has a -keystore option for specifying the name and
location of the persistent keystore file for the keystore managed by
keytool. The keystore is by default stored in a file named .keystore
in the user's home directory, as determined by the "user.home" system
property.
"
So, do you have a file in ~/.keystore? If so, it's likely to be the
place where all the certificates you are (re-)importing are going. You
need to configure this keystore to be the one that is used for your JNDI
connection. How are you configuring your JNDI resource? Please post the
configuration (minus any passwords, of course) and tell us where that
configuration appears.
> Then I found yet another command online which says that, it's not enough
> to import the certificate into keystore. It needs to be imported
> directly into the CACERT file.
That sounds like malarkey.
> To make matters even worse, I found yet another "advice" in Tomcat's
> documentation, saying : before importing the certificate, you need to
> first import a so-called TRUST CHAIN.
That may be possible. See... the big guys like VeriSign don't have just
a single certificate/key that they use to sign your certificate(s): they
have dozens. That is, in the tree of trust, there are many branches.
There are many reasons for that which I won't go into, here. Basically,
VeriSign's top-level cert (and they have more than one) trusts
VeriSign's mid-level certs, which in turn trust VeriSign's lowest-level
cert, which trusts you.
If you want the JVM to trust your certificate, you need to provide your
certificate (duh!) plus the 2 intervening ("chain") certificates to
bridge the chain of trust from your cert to the top-level VeriSign cert
that ships with the JVM.
> In some places, it says you need this trust chain if the certificate was
> applied for by yourself.
That statement is a bit ambiguous.
> is it:
> *keytool -import -file tomcatCert.crt -trustcacerts
> -alias tomcat -keystore c:/apps/jdk/jre/lib/security/cacerts -storepass
> changeit*
>
> or is it : * keytool -import -alias root -keystore
> <your_keystore_filename> -trustcacerts -file
> <filename_of_the_chain_certificate>*
It's both, or neither :)
Usually, you don't want to modify the keystore that came with the JVM
(that's c:/apps/jdk/jre/lib/security/cacerts). Why? Because if you
upgrade your JVM, then you're trusted certs will appear to vanish
because the new JVM ships with a new cacerts file which doesn't include
your changes.
What would be best is something like this (the \s in here are a
*NIX-style "command continues on the next line" convention... they are
not intended to be actually entered on the command line, but indicate
that you shouldn't press ENTER at the end of each line of text):
keytool -import \
-file chain-1-cert.crt \
-trustcacerts \
-alias chain-1 \
-keystore path\to\my\keystore
(then enter the password when prompted)
This will import one of the chain certificates you may need to import
for whoever signed your certificate. Who did sign it, by the way? Repeat
that command for each chain certificate you have to import.
Now, import your own certificate:
keytool -import \
-file your-cert.crt \
-trustcacerts \
-alias my-jndi-certificate \
-keystore path\to\my\keystore
(then enter the password when prompted)
This should get all your necessary certificates in one place: the file
indicated by path\to\my\keystore. Please let us know where you intend to
place this file.
Now, to actually /use/ that keystore depends on how you are configuring
your JNDI resource. Once we see that, we can help you point your
configuration at this file.
> And what is the difference between *KEYSTORE* and *CACERT *????
A keystore is just a file full of keys and certificates. The "cacerts"
file is a keystore that ships with the JVM and contains the top-level
certificates implicitly trusted by the JVM. It's name is "cacerts"
because it contains the certificates of the "certificate authorities"
(VeriSign, Thawte, etc.) so it's really "CA certs" or just "cacerts"
because holding down shift to type caps is sometimes just too much work.
Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAksFqO8ACgkQ9CaO5/Lv0PD4iACghI7dKc8OM0LocG2pNcH9YlC4
dAcAniXPZrxU8umajUibS/piatJgo7gV
=yOkm
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
