Chris,
thank you for your reply.
And thank you so much for taking the time and trouble to explain all this to me.
I really don't know much about JNDI. I don't even know where and how it is
configured.
But, I am going to try your suggestions, and see if it works out.
If you want, I could keep you posted on this.
Thanks again.
Regards
Stephen
> Date: Thu, 19 Nov 2009 15:22:07 -0500
> From: ch...@christopherschultz.net
> To: marr...@hotmail.com
> CC: users@tomcat.apache.org
> Subject: Re: Importing CERTIFICATE into Java Keystore
>
> -----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
>
_________________________________________________________________
Windows Live: Keep your friends up to date with what you do online.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010
