Re: Using SSL CA certificates

[Dave Smith <sa...@home.com>]

Craig,

> Now we come to the part of this procedure that I still don't completely
> understand. Once the CA issues a server certificate, I believe I use
keytool
> -import to install it, replacing the existing self-signed certificate.
> However, I'm not quite sure how to correctly install the CA's root
> certificate, and convince Tomcat to pass it along to the client with my
> server certificate.

The good news is you don't have to. Look in  <java-home>/lib/security.
You'll see a file called "cacerts". Just as you might expect, this file
contains
root certs for all the big players. Keytool knows all about it.
Read the documentation for Keytool very carefully. It is all spelled out.
A less confusing way to figure this stuff out is to read
"Java Cryptography" by Johnathan Knudsen.

> I tried to figure out how Tomcat actually locates the server key pair and
> the corresponding X.509 certificate, but so far I haven't managed to
locate
> the relevant source code. Does Tomcat and/or JSSE use the "tomcat" alias
to
> locate the correct certificate? Or does it simply look for a certificate
> with the correct common name (which in this case would be the
> fully-qualified DNS name of the server)?
>
> And how does Tomcat/JSSE generate the certificate trust chain? Does it
> simply search the keystore for certificates that have the correct
> distinguished names?

I don't know the specific answers to these two questions, but the cert chain
is held in your keystore. there is no other place in the java scheme of
things for it to live. I think you are correct about the cert name
being the FQDN. Actually the company which sells you the cert usually
has info on some of this, they will not purposely sell you a worthless
cert.


Good Luck,

Dave

----- Original Message -----
From: "Craig Richardson" <cr...@axent.com>
To: <to...@jakarta.apache.org>
Sent: Tuesday, November 28, 2000 9:44 AM
Subject: RE: Using SSL CA certificates


> "Lacerda, Wellington (AFIS)" wrote:
>
> > How can I use a C.A. real certificate with Tomcat SSL ? I want to add a
> test
> > certificate from Verisign.
> > Can you explain that with some detail, please ?
> >
>
> Craig McClanahan replied:
>
> > The detailed steps are documented in comments in the
> > "conf/server.xml" file for whichever version of Tomcat
> > you are using (3.2 or 4.0 only -- 3.1 doesn't support SSL).
>
> I've read the comments in server.xml, but there just wasn't enough
> information there to answer all of my questions. The documentation in
> server.xml contains just a few sentences, so I don't think anyone will
mind
> if I quote all of it here:
>
>     Uncomment this for SSL support.
>     You _need_ to set up a server certificate if you want this
>     to work, and you need JSSE.
>     1. Add JSSE jars to CLASSPATH
>     2. Edit java.home/jre/lib/security/java.security
>        Add:
>        security.provider.2=com.sun.net.ssl.internal.ssl.Provider
>     3. Do: keytool -genkey -alias tomcat -keyalg RSA
>        RSA is essential to work with Netscape and IIS.
>        Use "changeit" as password. ( or add keypass attribute )
>        You don't need to sign the certificate.
>
>        You can set parameter keystore and keypass if you want
>        to change the default ( user.home/.keystore with changeit )
>
> The description of step 2 isn't quite accurate. You do need to add the
JSSE
> security provider to the list, but it doesn't have to be the second entry.
> For example, here is the relevant section from my own copy of
java.security:
>
>     security.provider.1=sun.security.provider.Sun
>     security.provider.2=com.sun.rsajca.Provider
>     security.provider.3=com.sun.net.ssl.internal.ssl.Provider
>
> I also had trouble with step 3. It may be worth noting that keytool will
ask
> for your first and last name. Because you are trying to create a server
> certificate, and not a personal certificate, I believe you should ignore
> this and substitute the fully qualified DNS name of your web server.
>
> It's true that you don't need to sign the certificate that this keytool
> command will generate, because it's already a self-signed certificate.
> However, no client's browser ought to trust a self-signed server
> certificate. In order to get SSL to work properly, you'd want to replace
> this self-signed certificate with a proper server certificate that has
been
> signed by a trusted CA.
>
> Clearly the first step would be to generate a certificate request. Here I
> ran into a second problem. My version of keytool won't generate a
> certificate request if the subject's distinguished name contains any
quoted
> strings. When I generated my server key pair, I had included a comma in
the
> organization name. This caused a quoted string to be inserted into the
> distinguished name, and as a result keytool gave the following error:
>
>     keytool error: java.io.IOException: AVA parse, quoted stirngs NYI
>
> In order to get keytool to work properly, I had to create a new key pair.
> This time I entered an organization name that didn't include that pesky
> comma, and keytool worked properly.
>
> Now we come to the part of this procedure that I still don't completely
> understand. Once the CA issues a server certificate, I believe I use
keytool
> -import to install it, replacing the existing self-signed certificate.
> However, I'm not quite sure how to correctly install the CA's root
> certificate, and convince Tomcat to pass it along to the client with my
> server certificate.
>
> I tried to figure out how Tomcat actually locates the server key pair and
> the corresponding X.509 certificate, but so far I haven't managed to
locate
> the relevant source code. Does Tomcat and/or JSSE use the "tomcat" alias
to
> locate the correct certificate? Or does it simply look for a certificate
> with the correct common name (which in this case would be the
> fully-qualified DNS name of the server)?
>
> And how does Tomcat/JSSE generate the certificate trust chain? Does it
> simply search the keystore for certificates that have the correct
> distinguished names?
>
> Can anyone shed some light on this?
>
> Thanks!
> Craig Richardson