| Warning |
|---|
This page is the form of quick notes and needs to be rewritten as an article. |
Create Local Certificate
In this example we are generating a key called <your_cert_alias> and storing it in a brand new keystore called mywebservices.bin.
| Code Block | ||
|---|---|---|
| ||
su - serveradmin cd /opt/jre1.6.0_12/bin/ # Create a local Certificate keytool -genkey -alias <your_cert_alias> -keyalg RSA -keystore mywebservices.bin |
This information depends on your company. Note that when creating a cert for a website the first and last name will be the website url.
| Code Block |
|---|
Enter keystore password: mypassword What is your first and last name? [Unknown]: mywebservice.myapp.mycompany.com What is the name of your organizational unit? [Unknown]: My Unit What is the name of your organization? [Unknown]: My Organization What is the name of your City or Locality? [Unknown]: My City What is the name of your State or Province? [Unknown]: My State What is the two-letter country code for this unit? [Unknown]: CA |
As a result, a brand new keystore file is generated. You can confirm this,
| Code Block | ||
|---|---|---|
| ||
keytool -keystore mywebservices.bin -list Enter keystore password: ****** Keystore type: jks Keystore provider: SUN Your keystore contains 1 entry mywebservices, Oct 8, 2009, keyEntry, Certificate fingerprint (MD5): 02:70:28:DE:A6:BC:0B:5E:3C:FB:BF:B3:68:8F:0F:32 |
The results show 1 entry with the alias name mywebservices which contains a single element, a self-signed certificate which is soley there to generate the CSR.
Generate the CSR (Certificate Service Request)
In this step we generate the request for the SSL certificate.
| Code Block | ||
|---|---|---|
| ||
# Generate the CSR (Certificate Service Request) keytool -certreq -keyalg RSA -alias mywebservices -file mywebservices.csr -keystore mywebservices.bin # It is important that the cert files be in the webapps directory mv mywebservices.* /opt/apache/tomcat.0/webapps/ |
Now submit your mywebservices.csr to the CA (Certificate Authority).
| Note |
|---|
There is usally a web form to fill out in this step as you upload the contents. One note here is that if you are creating a public website you should choose a cert type that supports an alias. As such your cert will then be able to support the base domain name and the base domain prefixed by www. For example, you generate the certificate with the name "mywebservice.myapp.mycompany.com" and as you fill in the form you should use "www.mywebservice.myapp.mycompany.com". |
Your CA will return a certificate (your keystore file signed by the CA). Depending on the signer they may use different names so it can be confusing. For example the Entrust CA calls your certificate the "Webserver Certificate" even though in this example we are putting this on an application server. In our example we are provided the CA signed certificate as plain text which we then store in a text file calling it mywebservices-signe.cer. Here is what the contents of the plain text might look like,
| Warning |
|---|
To fill in. |
Import The CA (Certificate Authority) Certificate(s)
At this point how many CA certificates need to be imported depend on the CA you use. Also, the CA certificates themselves are usually obtained from the respective Certificate Authority.
In a simple scenario, one certificate is returned which authenticates the CA's public key. This is a self-signed certificate (that is, a certificate from the CA authenticating its own public key). For example, here is what the chain looks like this from top to bottom.
- CA Self-Signed Certificate (often called the root certificate)
- Your Certificate Signed by the CA
In the case that multiple certs are returned, the CA is returning a chain of certificates which might look like this from top to bottom,
- CA (Root) Self-Signed Certificate (often called the root certificate)
- CA (A) Key (certificate signed by a CA (A), authenticating the public key of Key of B below in the chain)
- CA (B) Key (certificate signed by a CA (B), authenticating the public key of Key of C below in the chain)
- CA (C) Key (certificate signed by a CA (C), authenticating the public key of Key one below in the chain)
- .... (there can be more)....
- Your Certificate Signed by the CA
Here is an example of what the Entrust CA returned chain looks like from top to bottom,
- CA (Root) Entrust Self-Signed Certificate (often called the root certificate)
- CA (LB1) Key (certificate signed by a CA (Root), authenticating the public key of Key of 1 below in the chain) - Entrust calls this the Cross Certificate
- Your Certificate Signed by the CA
The key concept of the chain is that you must import all certs in the chain in order from top to bottom. You also should provide a unique alias per cert. This will allow you to update specific certs in the chain when they expire. Using the example of the Entrust CA we would need to import as follows.
| Code Block | ||
|---|---|---|
| ||
keytool -import -alias entrust-2048-root -keystore mywebservices.bin -trustcacerts -file <filename_of_the_chain_certificate> Certificate was added to keystore # This is the expected response keytool -import -alias entrust-L1B -keystore mywebservices.bin -trustcacerts -file <filename_of_the_chain_certificate> Certificate was added to keystore |
Take a look inside your keystore and you should see the newly added certs with their unique alias.
| Code Block | ||
|---|---|---|
| ||
keytool -keystore mywebservices.bin -list entrust-l1b, Oct 9, 2009, trustedCertEntry, Certificate fingerprint (MD5): C2:DF:86:BD:E4:8B:FF:26:4D:AE:6A:26:1D:7A:70:D9 entrust-2048-root, Oct 9, 2009, trustedCertEntry, Certificate fingerprint (MD5): CC:23:87:09:9B:09:3A:6F:5E:62:EB:F4:73:54:E9:28 pkiwebservices, Oct 8, 2009, keyEntry, Certificate fingerprint (MD5): 02:70:28:DE:A6:BC:0B:5E:3C:FB:BF:B3:68:8F:0F:32 |
Import Your Certificate (Signed Keystore File)
Finally you can import your new Certificate making sure to use the same alias on the initial generation, pkiwebservices as you are replacing the self-signed cert already in the keystore.
| Code Block | ||
|---|---|---|
| ||
keytool -import -alias mywebservices -keystore mywebservices.bin -trustcacerts -file <filename_of_the_chain_certificate> Certificate reply was installed in keystore # This is the expected response |
This action replaces the self-signed certificate with a proper signed certificate. This is considered the first and bottom chain in a chain of certificates.
Configure Tomcat to Use the SSL Certificate
The final step is to configure Tomcat to use SSL.
Resources
This is an abridged and modified version of the following articles,
http://techtracer.com/2007/09/12/setting-up-ssl-on-tomcat-in-3-easy-steps/
http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html
http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.htmlhttp://www.manpagez.com/man/1/keytool/ - section on Certificate Chains was helpful