#/usr/java/jdk1.6.0_12/bin/java -version
2. Next, we are going to install tomcat in /usr directory. Go to /usr directory, and type
following commands.
# ln –s apache-tomcat-6.0.2 tomcat
1
© April 2007, Kefa Rabah, Global Open Versity, Vancouver Canada
export JAVA_HOME=/usr/java/jdk1.6.0_12
export CATALINA_HOME=/usr/tomcat
export PATH=$JAVA_HOME/bin:$CATALINA_HOME/bin:$PATH
5. Before we begin, we will need to ensure that CATALINA_HOME and JAVA_HOME are correctly
set. To do this, we open a terminal and type the following:
# echo $CATALINA_HOME
# echo $JAVA_HOME
6. If everything is fine, you can start Tomcat with the following command.
# $CATALINA_HOME/bin/startup.sh
7. To test that Tomcat is running, from another computer, go to graphical desktop, open a Web
browser, and type in following URL: http://xxx.xxx.xxx.xxx:8080, where xxx.xxx.xxx.xxx is
the your computer’s IP address or domain name. or you can also use http://localhost:8080. If
everything is fine, you should be able to see a web page such as this.
# $CATALINA_HOME/bin/shutdown.sh
/usr/tomcat
/webapps
/testapache
2
© April 2007, Kefa Rabah, Global Open Versity, Vancouver Canada
/WEB-INF
/classes
/lib
<%@page contentType="text/html"%>
<%@page pageEncoding="UTF-8"%>
<html>
<head><title>JSP Test Page</title></head>
<body>
<h1>Hello World!</h1>
<%-- <jsp:useBean id="beanInstanceName" scope="session"
class="beanPackage.BeanClassName" /> --%>
<%-- <jsp:getProperty name="beanInstanceName" property="propertyName" /> --%>
</body>
</html>
To test you index page, open a web browser, and type in following URL:
http://localhost:8080/testapache/. If everything is fine, you should be able to see a hello world
web page.
Part 4: Creating Self-Signed Certificate & SSL Configuration for Secure Webserver
1. Create a new keystore containing a self-signed certificate by executing the following (these
are Windows commands):
]# cd $JAVA_HOME/bin
]# kytool -genkey -alias tomcat -keyalg RSA
Linux always stores the key in the logged in user default home directory, if location is not
specified.
Alternatively, you can choose to store your keys in a specific location, e.g.,:
for example:
And specify a password value of "changeit". When asked what is your first and last name?
(enter your client server's DNS, e.g.,: server01.my-domain.com or www.my-domain.com,
localhost, or IP address that you will use in browser or an application to connect to the
server.).
Fill in the rest of the prompts as you see fit. At the end when you’re asked to verify, make sure
that the CN value is set to your client server's DNS.
3
© April 2007, Kefa Rabah, Global Open Versity, Vancouver Canada
At the end when prompted for the password for alias <tomcat>, hit enter to keep the password
the same as that of the keystore password.
1. Export the tomcat cert (to be imported into the jdk's default keystore):
2. Import the exported cert into the jdk keystore (modify keystore path to your cacerts
location) – You must be root to perform this operation:
Alternatively, If you’re interested in acquiring a third party SSL Certificate then, you need to mail
this info to your chosen Certificate Authority (CA), e.g., VeriSign, Thawte or RSA, then proceed
as below.
Now you have a file called certreq.csr that you can submit to the Certificate Authority (look at
the documentation of the Certificate Authority website on how to do this). In return you get a
Certificate or a number of Certificates.
2. Now you have to import those certificates into a keystore file that you have previously
created.
4
© April 2007, Kefa Rabah, Global Open Versity, Vancouver Canada
2. Restart Tomcat and test your web server: https://localhost:8443, or in this case we’re using
our FQDN:
If all goes well you will be asked if you want to proceed using the Security Certificate. Click Yes, and
you should be in business, and you should see the usual Tomcat splash page. Henceforth, you should be
able to access any web application supported by Tomcat via SSL.
NOTE: If you’re behind a router don’t forget to open its port to 8443 (or 433)!
5
© April 2007, Kefa Rabah, Global Open Versity, Vancouver Canada
parties. It is an example of a trusted third party. CAs are characteristic of many public key
infrastructure (PKI) schemes
A CA issues digital certificates that contain a public key and the identity of the owner. The
matching private key is not similarly made available publicly for security reason and should only
be known by only-and-only the owner and nobody else, and is kept secret by the end user who
generated the key pair. The certificate is also an attestation by the CA that the public key
contained in the certificate belongs to the person, organization, server or other entity noted in
the certificate. A CA's obligation in such schemes is to verify an applicant's credentials, so that
users and relying parties can trust the information in the CA's certificates. CAs use a variety of
standards and tests to do so. A Registration Authority (RA) is required to validate the CA.
If the user trusts the CA and can verify the CA's signature, then he can also verify that a certain
public key does indeed belong to whoever is identified in the certificate –thereby completing the
confidential and non-repudiation of the respective transaction.
-----------------------
Kefa Rabah is the Founder and CIO, of Serengeti Systems Group Inc. Kefa is knowledgeable in
several field of Science & Technology, IT Security Compliance and Project Management, and
Renewable Energy Systems. He is also the founder of Global Open Versity, a Center of Excellence
in online eLearning.
6
© April 2007, Kefa Rabah, Global Open Versity, Vancouver Canada