tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ken Sims" <KS...@msjcorp.com>
Subject RE: SSL Certificate configuration
Date Tue, 09 Nov 2004 18:42:41 GMT
I'm not an old-hand in this arena myself -- I don't know how to get TC
to log anything that would indicate how it locates/loads the certificate
on startup.

I think that's a good approach though ... From the perspective of a
client browser navigating to a resource via https, both the CA and
Server certs are in the chain of trust (and perhaps other
intermediaries).  So, if neither has been encountered before, you might
legitimately and correctly be seeing details for not only the server's
cert but also that of the CA.  So, yes, it'd be nice to see it from the
server's perspective.


-----Original Message-----
From: Robert Cole [mailto:robert.cole@db.com] 
Sent: Tuesday, November 09, 2004 7:50 AM
To: Tomcat Users List
Cc: Tomcat Users List
Subject: RE: SSL Certificate configuration



Thanks Ken. That looks exactly like what I did. I suppose the only
difference is that our OpenSSL is on Linux and the keystore and Tomcat
is on Wintel. I could understand if the certificate didn't work at all
(i.e. some dodgy characters when copying/ftping information) but its not
that.

Is there a debug switch that I could use when starting the container to
get information on what Tomcat is actually using? I.e. the keystore,
certificate alias etc?

Thanks for all of the suggestions so far, please keep them coming.

Rob Cole

+44 (0)20 754 51117



 

                      "Ken  Sims"

                      <KSims@msjcorp.co        To:       "Tomcat Users
List" <tomcat-user@jakarta.apache.org>

                      m>                       cc:

                                               Subject:  RE: SSL
Certificate configuration

                      09/11/2004 15:36

                      Please respond to

                      "Tomcat Users

                      List"

 

 





The steps you list worked for me.  ... That makes me think that we used
keytool or OpenSSL differently somehow.  I'm attaching a batch (DOS)
script that I used to set myself up for testing.  Note that I'm not
using the default locations and file names for the keystore and
truststore (some adjustment is in order either in this snippet or in
your server.xml SSL connector setup).

@echo off
cd \openssl\bin
md ca_cert
md server_cert
md client_cert
md C:\server_truststore
md C:\server_keystore
md client_truststore
md client_keystore
echo *************************************
echo *                                   *
echo *  Enter Info for CA Certificate    *
echo *                                   *
echo *************************************
openssl req -new -newkey rsa:1024 -nodes -out ca_cert\ca.csr -keyout
ca_cert\ca.key openssl x509 -trustout -signkey ca_cert\ca.key -days 365
-req -in ca_cert\ca.csr -out ca_cert\ca.pem copy ca_cert\ca.pem
ca_cert\ca.cer keytool -import -keystore C:\server_truststore\cacerts
-file ca_cert\ca.cer -alias my_ca -storepass changeit -keypass  changeit
echo "02" > ca_cert\ca.srl echo *************************************
echo *                                   *
echo * Enter Info for Server Certificate *
echo *                                   *
echo * IMPORTANT: use the server's       *
echo * IP address for  the common name   *
echo *                                   *
echo *************************************
keytool -genkey -alias my_server -keyalg RSA -keysize 1024 -keystore
c:\server_keystore\keystore -storetype JKS -storepass  changeit -keypass
changeit keytool -certreq -keyalg RSA -alias my_server -file
server_cert\server.csr -keystore c:\server_keystore\keystore  -storepass
changeit -keypass changeit openssl x509 -CA ca_cert\ca.pem -CAkey
ca_cert\ca.key -CAserial ca_cert\ca.srl -req -in server_cert\server.csr
-out server_cert\server.cer -days 365 keytool -import -alias my_ca
-keystore C:\server_keystore\keystore -trustcacerts -file ca_cert\ca.cer
-storepass changeit  -keypass changeit keytool -import -alias my_server
-keystore C:\server_keystore\keystore -trustcacerts -file
server_cert\server.cer  -storepass changeit -keypass changeit

-----Original Message-----
From: Robert Cole [mailto:robert.cole@db.com]
Sent: Tuesday, November 09, 2004 6:59 AM
To: Tomcat Users List
Cc: 'Tomcat Users List'
Subject: RE: SSL Certificate configuration



There is a password specified, I just didn't fancy including it in a
publically available mail archive. It is specified at the keystore
creation and also specified in the connector. Sorry for any confustion
this may have caused.






                      "Hubble,

                      Christopher"                To:       "'Tomcat
Users List'" <tomcat-user@jakarta.apache.org>

                      <CHRISTOPHER.L.HUBBL        cc:

                      E@saic.com>                 Subject:  RE: SSL
Certificate configuration



                      09/11/2004 13:53

                      Please respond to

                      "Tomcat Users List"









It doesn't matter what your keystore is named(at least in windows).  I
usually use a keystore convention of appname.ks  Haven't had a problem
with it.  Robert, are you using a password for your keystore?  I've
never tried it without a password.

Chris

-----Original Message-----
From: David Goodenough [mailto:david.goodenough@btconnect.com]
Sent: Tuesday, November 09, 2004 7:23 AM
To: tomcat-user@jakarta.apache.org
Subject: Re: SSL Certificate configuration


Maybe its different on Windows, I only use Linux.  Certainly on Linux
the file is called .keystore, and of course as that is a hidden file one
could create keystore files till the sky turned yellow before Tomcat
would take any notice of them, i.e. it would use whatever was in the
.keystore file.

David

On Thursday 11 November 2004 11:47, Robert Cole wrote:
> Hi David,
>
> I'm unfortunately on a Wintel server and the OS has problems with 
> files named with a preceding.
>
> My connector references the 'keystore' and accessing the keystore via 
> keytool. I've tried it with the .keystore name as an early solution 
> but it didn't make any difference. If the .keystore name is mandatory 
> I can try
it
> again, but it still doesn't explain where the self-signed certificate 
> is coming from.
>
> Thanks,
>
> Rob Cole
>
> +44 (0)20 754 51117
>
>
>
>
>                       David Goodenough
>                       <david.goodenough@btc        To:
> tomcat-user@jakarta.apache.org onnect.com>                  cc:
>                                                    Subject:  Re: SSL 
> Certificate configuration 09/11/2004 11:33
>                       Please respond to
>                       "Tomcat Users List"
>
> On Thursday 11 November 2004 11:04, Robert Cole wrote:
> > Hi,
> >
> > I'm having some fun and games getting Tomcat 5.0.19 to use a 
> > non-self signed certificate. I've done the following:
> >
> > 1) Using Keytool, generated a new key pair using the genkey switch, 
> > into a new keystore 2) Generated a CSR using the new keystore 
> > created above
3)
> > Using OpenSSL, where I've created a certificate authority to sign my

> > CSRs, I've then generated a signed certificate valid for 365 days,
signed
> > by my root authority 4) I've then imported the Root CA into the 
> > keystore created in 1
> > 5) Then I've imported the new, signed certificate into the keystore 
> > from 1 6) I've then enabled by HTTPS connector in server.xml, with 
> > the keystore entry pointing to the keystore from 1. I bounced Tomcat

> > afterwards
> >
> > I can then connect to Tomcat on port 8443 but when I examine the 
> > certificate it is a self signed certificate that expired after 3 
> > months. There is no evidence of the signed certificate.
> >
> > So far I have:
> >
> > 1) Removed the keystore file to check that Tomcat is picking up the 
> > correct file. It is as I get loads of errors in the std.out file 2) 
> > Listed the contents of the keystore. I can see in the following 
> > order, the root CA certificate, the generated keypair and then the 
> > signed certificate. 3) I made a copy of the keystore, changed the 
> > configuration to use the copy and then fired Tomcat up again. I 
> > finally managed to
shut
> > Tomcat down again after a large number of errors flooded the log 
> > file.
4)
> > I've used the Keytool export and printcert switches to check that 
> > the signed certificate in the keystore is the right one, and it is.
> >
> > So, my question is, how is tomcat using a self signed SSL 
> > certificate, and where could it be getting it from? Is there a way 
> > to force Tomcat to use a certain certificate from a keystore?
> >
> > I'm now very, very stuck and would appreciate some help. Are there 
> > any switches I can use to get more information from Tomcat on what 
> > it is using, certificate wise?
> >
> > For reference, the connector config looks like this:
> >
> >     <Connector port="8443"
> >                maxThreads="150" minSpareThreads="25"
maxSpareThreads="75"
> >                enableLookups="false" disableUploadTimeout="true"
> >                acceptCount="100" debug="0" scheme="https"
secure="true"
> >                clientAuth="false" sslProtocol="TLS"
> >                keystoreFile="D:\db\certificates\keystore"
> >                keystorePass="" />
> >
> > My keystore:
> >
> > D:\db\certificates>keytool -keystore keystore -list
>
> should that not be ".keystore", not "keystore"?
>
> David
>
> > Enter keystore password:
> >
> > Keystore type: jks
> > Keystore provider: SUN
> >
> > Your keystore contains 3 entries
> >
> > rootca, Nov 9, 2004, trustedCertEntry,
> > Certificate fingerprint (MD5): 
> > 7B:CD:2C:5D:AE:79:8A:86:D5:70:25:56:3D:0D:D1:AC mis1_key, Nov 9, 
> > 2004, keyEntry, Certificate fingerprint (MD5): 
> > BB:6A:10:C7:1C:DC:A2:AE:BD:77:C3:6F:50:B6:50:C1 mis1_cert, Nov 9,
2004,
> > trustedCertEntry,
> > Certificate fingerprint (MD5): 
> > 63:A4:57:A1:3E:B9:72:67:14:21:88:F3:3A:90:C5:5A
> >
> > The certificate that should be used is the mis1_cert certificate. 
> > From the printcert:
> >
> > D:\db\certificates>keytool -keystore keystore -printcert -file 
> > test.crt -v Owner: CN=mis1, OU=gmPrice, O=Deutsche Bank, L=London, 
> > ST=England, C=UK Issuer: EMAILADDRESS=robert.cole@db.com, 
> > CN=gmPrice, OU=Shared Technology, O=Deutsche Bank, L=London, 
> > ST=England, C=UK Serial number: 8 Valid from: Tue Nov 09 09:26:01 
> > GMT 2004 until: Wed Nov 09 09:26:01 GMT 2005 Certificate
fingerprints:
> >          MD5:  63:A4:57:A1:3E:B9:72:67:14:21:88:F3:3A:90:C5:5A
> >          SHA1: 
> > C7:AA:85:F7:7E:92:AC:E6:77:8B:44:F4:B2:7F:33:11:A7:DC:57:A3
> >
> >
> >
> > Rob Cole
> >
> >
> >
> >
> > --
> >
> > This e-mail may contain confidential and/or privileged information. 
> > If you are not the intended recipient (or have received this e-mail 
> > in
> > error) please notify the sender immediately and destroy this e-mail.
Any
> > unauthorized copying, disclosure or distribution of the material in
this
> > e-mail is strictly forbidden.
> >
> >
> >
> > --------------------------------------------------------------------
> > -
> > To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>
>
>
>
>
> --
>
> This e-mail may contain confidential and/or privileged information. If

> you are not the intended recipient (or have received this e-mail in
> error) please notify the sender immediately and destroy this e-mail. 
> Any unauthorized copying, disclosure or distribution of the material 
> in this e-mail is strictly forbidden.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org







--

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org







--

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message