2

i was successfully to take my webapplication on https from http. Actually i have doubts about the roles of two files that came across during this transition phase. I can see two key files one is .keystore and another is CAKey.pem. I specifically want to know the at what point of time they come in to picture. In server.xml i find a entry of atrributes keystoreFile(for which value is location of keystore) and keystorePass(value for which is password i had given during generation of .keystore file) while in ApplicationConfig.xml i find a two attributes i.e openSSLLocation(against which i can see the value of openssl directory) and second attribute is password (against which value is what i had given the value of password during generation of CAKey.pem file).

Want to know specifically what these file contain and play role in SSL?

Edit i went thru the link which bruno pinted out. I also went thru another informative link link i.e http://www.verisign.com/ssl/ssl-information-center/how-ssl-security-works/. Now my understanding after going thru thhese two links is kestore file contains the details of SSL certificate (if we use authorized CA like verisign they provide 128 bit encryption which probably default key store brovided by java keytool command certificates does not). On the basis of this certificate containing private key, encryption happens. Right? As pointed in versign link , at last digital signature is also issued as acknowledgement. Not sure Does this certificate has any purpose or just acknowledgement as pointed in link? Files like CACert.pem, CAKey.pem are related to digital certificates?

Edit 2

here are the steps I followed for SSL

1) Download Win32OpenSSL_Light-0_9_8t from http://www.slproweb.com/products/Win32OpenSSL.html and install

2) In the OpenSSL installation directory, create subdirectory private. The Certificate Authority's private key will be stored here. In the OpenSSL installation directory, create subdirectory newcerts. New certificates signed by the CA will be stored here. In the OpenSSL installation directory, create an empty file named index.txt. OpenSSL keeps its signed certificates database in that file. From the subdirectory bin/PEM/demoCA of the OpenSSL installation directory, copy the file serial to the OpenSSL installation directory. Open the copied serial file and edit it to read 00 and save. Each new CA-signed certificate's serial number is taken from this file's content, which is incremented each time a certificate is signed.

3) In openssl.cfg .Did the following changes dir = c:/openssl <-- This is the OpenSSL installation directory certificate = $dir/private/cacert.pem #crl = $dir/crl.pem

4) Create Self-signed Certificate with command cd /d "%OPENSSL_HOME%" openssl req -new -x509 -days 2000 -keyout private\CAKey.pem -out private\CACert.pem -config bin\openssl.cnf

5)Convert the certificate PEM file to a DER encoded file cd /d "%OPENSSL_HOME%" openssl x509 -in private\CACert.pem -out private\CACert.cer -outform DER This command creates file CACert.cer in the private subdirectory.

6) Modify Java Root Certificates

cd %JAVA_HOME% keytool -import -keystore jre\lib\security\cacerts -alias AppOpenSSLCert -file %OPENSSL_HOME%\private\cacert.cer

This adds our self-signed CA certificate to Java's trusted CA certificates, which are kept in file jre\lib\security\cacerts in the Java JDK installation directory. Our self-signed CA certificate was stored under the alias AppOpenSSLCert.

As per documentation it should have worked(i.e i tried hitting the URL with https) but it did not work . To make it work I had to run one more command i.e

7) C:\Program Files\Java\jdk1.6.0_23>keytool -genkey -alias tomcat -keyalg RSA which generated .keystore file((which will have SSL certificate which will be send when client makes https request and client matches this certificates in truststore and private key)

Finally i made changes in server.xml and it worked keystoreFile="c:/.keystore" keystorePass="changeit"

Thats why whole confusion came to my mind. If we are using certificates pointed by .keystore file generated in 7th step,what is the purpose of steps i did from 1 to 6(CAKey.pem and CACert.pem files). Whatever i understood regarding SSL, i think i should not mention .keystore(generated in step 7)in server.xml but some other keystore probably generated somewhere during step 1-6 but not sure what is the file name and where it is generated?

Last question in the verisign link. it talks about two certicates i.e SSL certificate and digital certificate. Where SSL certificate and digital certificate fit in above scenario?

M Sach
  • 33,416
  • 76
  • 221
  • 314

2 Answers2

4

From a Java point of view, you should first try to understand the difference between keystore and truststore (both of which are keystores used for different purposes).

There is no default keystore in the JSSE, but some applications use $HOME/.keystore by default: this is what contains your certificate, for which you have the private key.

In contrast, the truststore determines which remote certificates you're willing to trust. It contains a number of CA certificates to which a certification path can be established when encountering a new certificate. If there is such a path (and provided the certificate isn't revoked if this is activated), this (a priori) unknown certificate is accepted as trusted.

It sounds like the procedure you've used consisted of created your own Certification Authority, hence you'll end up with a CA certificate file and its private key (which is likely to be that CAkey.pem file). This should only be used to issue new certificates with this CA.

if we use authorized CA like verisign they provide 128 bit encryption which probably default key store brovided by java keytool command certificates does not).

It's not the certificate that's used to choose the encryption key size, it's the cipher suite. (The era of SGC certificates is over.)

During the SSL/TLS handshake, the server certificate is used to authenticate the server (to ensure that the client is communicating with the server it wanted to talk to) and to negotiate a set of shared symmetric keys (depending on the cipher suite): those are the ones used for the encryption.

If you want to generate a certificate with keytool for a specific key size, use -keysize 2048 (for example). Note that this is the size of the key in the certificate, not the size of the symmetric keys used for the encryption itself.

More or less the same command with keytool can be used to generate a CSR to send to a commercial CA. Whether you use a commercial CA or your own will make no difference w.r.t. the encryption strength. The difference is that no one will recognise your own certificates by default, so you will have to import it in your clients explicitly. The certificates are mainly useful for verifying the identity of the remote entity you're communicating with.

(You may also be interested in the discussions in this question.)

EDIT:

You've mixed two completely different procedures.

  1. Creating your own CA.

What you've done with OpenSSL is generate your own Certification Authority (CA). Hence, you get CAcert.pem and CAkey.pem which are the CA certificate and its private key (used for issuing new certificates with this CA). If you go down that route, all you'll need to do is to import CAcert.pem as a trusted CA certificate in your clients, and the certificates you issue with it will be trusted. You may also be interested in OpenSSL's CA.pl, which is a script that wraps many of the procedures you may have done more manually.

OpenSSL can't deal with JKS files, and this procedure isn't very useful without a few extra steps. From here, you could either:

  • Generate a key+cert for your server using OpenSSL (CA.pl should help). From a Java point of view, it's easier to export it in PKCS#12 format (.p12 file): you'll then be able to use that file directly from Java as a keystore of type PKCS12 (keystoreType="PKCS12" in your configuration).
  • Generate a CSR with keytool via -certreq, issue a certificate using OpenSSL (again, CA.pl should help), re-import this certificate into your keystore (via keytool) and use that JKS store.
  1. Using a self-signed certificate for this server directly.

This is probably the easiest if you only have one server.

In this case, follow the procedure described in this answer and import the certificate exported with -export into your client's truststore (or into your browser).

Last question in the verisign link. it talks about two certicates i.e SSL certificate and digital certificate. Where SSL certificate and digital certificate fit in above scenario?

Not sure, really. I can't find where it talks about "digital certificate". Strictly speaking there is no such thing as an "SSL certificate", although the expression more or less always means "X.509 certificate used for SSL/TLS".

You can use X.509 certificates for other purposes than SSL/TLS and use SSL/TLS with other types of certificates. The most common is X.509 with SSL/TLS.

"Digital certificate" could also encompass a wider category, for example OpenPGP certificates can also be used for SSL/TLS (see this answer, for example). There are also Attribute Certificates, which don't even contain a public key (don't read about them until you've really understood what X.509 certificates are about, otherwise, you'll be more confused).

My guess though is that Verisign would use "SSL certificate" to mean X.509 certificates for use with SSL and perhaps "digital certificates" for X.509 certificates for other uses as well, such as e-mail signing/encryption. Both would be within the context of a PKI (established by Verisign).

Community
  • 1
  • 1
Bruno
  • 119,590
  • 31
  • 270
  • 376
  • Hi Bruno, I mentioned what i actually did and where confusion lies. It would very helpful if you can clarify this. Thanks for your patience – M Sach Mar 07 '12 at 05:39
  • Hi Bruno, i am waiting for your answer eagerly on edited part. I think it should really clear all doubts – M Sach Mar 08 '12 at 10:52
  • Now i start getting you. As per you new edited answer, looks like from step 1-6 , approach is creating my own CA. But in step 7 , i am creating the self signed certificate. So step 1-7 follows one approach while step 7 is a different approach altogether. RIGHT? Could you little bit elaborate what should be the 7th step if i go by Creating my own CA approach? – M Sach Mar 09 '12 at 18:31
  • If you create your own CA, I'd suggest using CA.pl. The (RSA) [examples](http://www.openssl.org/docs/apps/CA.pl.html#EXAMPLES) are short, but to the point. The 4 commands respectively create a CA, create a cert request (in particular creates a key-pair for your server cert), issue a cert from that request (the CA signs) and bundles the result in a PKCS#12 file. Make sure you set the Common Name of the server cert (when requesting) as the host name of the server. – Bruno Mar 09 '12 at 19:03
  • One last question if i just follow 7th step(not any other step) i.e keytool -genkey -alias tomcat -keyalg RSA which generated .keystore file and do the changes in server.xml keystoreFile="c:/.keystore" keystorePass="changeit".I am on self signed certificate approach and will be able to move my site on https.Is that correct? If yes when i hit the URL https url i get the warning Continue to this website (not recommended). I tried to import the .keystore file in certificate section of content TAB in IE. But it does not accept this format. – M Sach Mar 12 '12 at 06:06
  • Is there a way i can avoid this warning in self signed certificate approach? – M Sach Mar 12 '12 at 06:07
  • You should be able to export the certificate using `keytool -export` and import it explicitly into your browser. – Bruno Mar 12 '12 at 09:25
3

The keystore file is the one which would store the details of the certificates necessary to make the protocol secured. Certificates contain the information as to who is the source from which you are receiving the application data and to authenticate whether it is the intended party or not. (Source : http://techtracer.com/2007/09/12/setting-up-ssl-on-tomcat-in-3-easy-steps/ )

CAKey.pem contains the private key for the certificate of authentification

Bruno Fedrigo
  • 211
  • 1
  • 5