LINUX distribution

The configurations were tested on the following environment, for others, check working path, and available tested release.
See our best practices to install services and keep them up to date.

fedora-release-6-4 

tomcat5-5.5.17-6jpp.2
java-1.6.0-sun-compat-1.6.0-1jpp # non default jpackage for SUN
jdk-6-linux-i586.bin # non default SUN package
java-1.6.0-sun-jce-policy-1.6.0-1jpp # unlimited strength for certificate keys

jpackage-utils-1.7.3-1jpp.2.fc6
rpmdevtools-5.3-1.fc6

fedora-release-5-5  

tomcat5-5.5.15-1jpp_6fc
java-1.5.0-sun-1.5.0.09-1jpp # non default jpackage for SUN
jdk-1_5_0_09-linux-i586.bin # non default SUN package
jce_policy-1_5_0.zip # unlimited strength for certificate keys

jpackage-utils-1.6.6-1jpp_2rh
rpmdevtools-5.2-1.fc5

SUN

For licensing reasons JAVA SUN is not installed by default in Red Hat Fedora distros. When installed, check it is activated using alternatives features.

Be Careful The SUN JAVA packages should be installed with sources, then built and compiled. Otherwise you could have broken fedora configurations. Also do not forget to enable illimited strength for cryptography.

Useful information On November 13, 2006, Sun announced that all of the Java source code will be released entirely under the GNU General Public License, by March 2007. Following their promise, Sun released the complete source code of the Class library under GPL on May 8, 2007, except some limited parts that were licensed by Sun from 3rd parties who did not want their code to be released under an open-source license.

If you are in a hurry check this quick and dirty

mortbay.org

This is another java web server. Some of the features of the following package are usefull for misc certificate format conversion to JKS (Java Keys store)

org.mortbay.jetty.jar

Put this jar in your classpath (or in /opt).

PERMISSIONS

Check file permissions on path /usr/local/java/jre/lib/security
This is the default location for the JKS store cacerts containing default certification authorities (CA) certificates.

Check file permissions and context on path /etc/tomcat5

The file server.xml contains java key store configurations for each related connector.
The file tomcat5.conf allows to set JAVA_OPTS (i.e: default key store location -Djavax.net.ssl.trustStore)

Handy Hint It is wise tu run tomcat in a chroot environment. It is out of the scope of this document to describe how. But keep in mind that when you copy (or mount --bind) your directories and files, you should keep permissions and SELinux context. The recommended chroot path for tomcat5 is "/var/tomcat5/chroot"

SELINUX context

Although java & tomcat run in unconfined context, some of the associated applications may run in SELinux context like httpd or Mysql. Therefore most of the tuning is on the side of applications using SELinux to open appropiate rights
i.e. Allow httpd to use AJP connectors to tomcat

Check following default context for tomcat directories

Others security features

Be Careful Remember that with certificates, acceptance is controlled by the Certification authorities (CA) certificates you store in your CA path (i.e: /usr/local/java/jre/lib/security/). A default bundle file of CA certs in a java keys store is located at "/usr/local/java/jre/lib/security/cacert" (default password changeit). Also remember that if your java keys store is stolen, one can impersonate your host over the internet. Especially if you use all purposes certificates.

Enabling SSL

You need to attach certificates and related stuff to the tomcat connectors. That is you have to perform the following steps:

1. Obtain a certificate for your host
   • Check the DNS naming scheme of your hosts and services
   • Adopt an external naming scheme, or define one for your OSI names osiNames
   • Check your host name, it defaults to your FQDN (ie:host.example.com)hostname
     • Configure virtual host name if desired virtualHostname
     • Update DNS or DNSSEC accordingly
   • Prepare a PKCS10 certificate request or go to an online certification enrollment
     • Choose between self signed certificates or certificates from an external CA
     • Use openssl command line keytoolCli or CA web form
     • Always enter your FQDN host name as CN (Common name) ie:host.example.com fillingDN
     • Check that you request a certificate for client and server authentication purposes certsPurpose
   • Retrieve your signed certificate certRetrieve
     • Check it is in PEM format (base 64 encoded) and convert it if necessary
     • Verify your certificate purpose certVerify
     • check the content of your signed certificate certCheck
   • Get your associated certificate key keyRetrieve
2. Retrieve the Certification Authority certificate(s)CAcertsRetrieve
3. Update your Java Key Store with CA certificates CAcertsupdate
4. Update your Java Key Store with your signed certificate certUpdate
5. Retrieve the Certification Authority CRL (certificate revocation list) CRLcertsRetrieve
   • update certificate repository with CRLs in /etc/pki/tomcat.tls/crls CRLcertsStore
   • Setup a cron job to retrieve regularly updated CRLs CRLcertsCron
6. Decide if you want to keep default Certification authorities bundled file certsBundle
7. Update your SSL connector connectorSSL
8. Start or restart tomcat (command: service tomcat5 restart)
9. Check log files for errors (command: tail /var/log/tomcat5/catalina.out)
10. Check for proper SSL activation (with https: // virtual-host.example.com:8443)
    
    

---

Return to top of page topTomcatSSL

Adopt an external naming scheme, or define one for your OSI names

OSI stands for "Open Standards for Interconnection" from ISO / ITU
an OSI name is called a "Distinguished name" which is used in all OSI related technologies such as

• Certificates (X509)
• LDAP directories including Microsoft Active directory (X500)
• Military and aeronautical messaging systems (X400)

A "Distinguished name" (DN) is a collection of one or more of the following components

• CN Common name
• OU Organisation Unit
• O Organization
• C Country
• and many others like "gn givenname","sn surname","l location" ......

Example DN
DN: cn=My_full_FQDN_name,ou=Related_Organisation_Unit,ou=other_related_unit,o=Company_name,c=country

or with the alternate DC scheme mostly used in directories.

DN:cn=My_full_FQDN_name,ou=Related_Organisation_Unit,ou=other_related_unit,dc=example,c=com

Common meanings of OU are as follows:

• OU=Hosts
• OU=People # users
• OU=Services # Daemons

openOSI also uses in its naming scheme:

• OU=VirtualHosts
• OU=VirtualPeople # nicknames
• OU=PKI # Certification authorities

In principle you are free to use what you want as DN components value, unless you request a certification authority to certify these values. That is unless you intend a public use of these names to participate in an Internet of trust (similarly to the dns - Domain name system).

You MUST use a "Distinguished name" to generate a certificate request, see fillingDN

For additional information check the various OSI X500 and RFC

Useful Information There could be links between DNS and OSI naming scheme, especially when domain components are used for distinguished names. Some people stores DNS DB in an LDAP directory (like Microsoft optionally). Most people don't in order to keep loosely coupling between DNS and Directories. There is an interesting use of LDAP directories for certificates when storing these certificates and their revocation list (CRL) in the directories. Therefore you MAY imagine a scheme that facilitate directory searching for your certificate retrieval. That is unless you use a third part directory like openOSI (directory.opensosi.org). openOSI practice is to store your certificate in virtual OU unit according the openOSI naming scheme without relying on the distinguished name of the certificate. See certCheck, CAcertsRetrieve, and CRLcertsRetrieve

---

Return to top of page topTomcatSSL

Check your FQDN host name

---

Configure virtual host name if desired

Details about virtual hosting with tomcat is out of the scope of this document.

Be Careful By nature the SSL - TLS protocol doesn't support virtual hosting on the same port, unlike unencrypted http protocol. This is because the SSL connexion is checked before it's virtual name processing. If you want to enable SSL virtual hosts you should choose alternate "connector / port" (one for each virtualhost), see connectorSSL, or alternate network interface if present.

You configure the virtual hostname in /etc/tomcat5/server.xml within an "engine container element". The SSL behavior is defined inside "Connectors elements" building the "service definition element". In addition you should define a context in /etc/tomcat5/Catalina/virtual-host/ROOT.xml or /etc/tomcat5/Catalina/virtual-host/context_name.xml

Minimal example of /etc/tomcat5/server.xml with 2 virtual "host elements"

• Where ports 8443 and 8444 will be used for SSL virtual hosting
• Where example-host has a valid DNS configuration
  

You will find more details in tomcat doc

Minimal example of /etc/tomcat5/Catalina/virtual-host/ROOT.xml

Useful Information It is practical to have different SSL connector-ports, that allows you to apply differents policies on client certificate check i.e: clientAuth=true or clientAuth=want. Also note that clientAuth can be used in web.xml per application configuration file.

You will find more details in tomcat doc

---

Return to top of page topTomcatSSL

Use keytool to generate a certificate request virtual-host.csr

Generate the private key, inside a keystore virtual_host.jks, then the signing request
Check fillingDN to see how to include the DN in the command line instead of answering prompts
NOTE that embedding the DN in the command line is the only way to use the DC naming scheme (as shown in our example)

The outputs will be

1. a private key inside a keystore, with default password changeit, with RSA coding virtual-host.jks
2. a PKCS10 format certificate signing request named virtual-host.csr

Useful Information Unlike for openssl / httpd, private key inside a java key store (JKS), and the JKS itself have always passwords. These passwords MUST have the same value (you'll get errors if you have one for the private key and one different for the JKS). The default value is changeit. You MAY change it, but in this case you MUST update the configuration file server.xml (parameter keystorePass).

Be Careful You MAY have multiple certificates in a given java key store (JKS), but in that case you MUST update the configuration file server.xml (parameter keyalias).

To verify the content of the example java key store (JKS)
With default password changeit

To verify the content of your signing certificate request (CSR)

Because the request is in standard PKCS10 format, you could use many tools, including openssl, to check the request.

---

Return to top of page topTomcatSSL

Filling your certificate subject

This subject is bind to the cryptographic material of your certificate. Here is the real nature of a certificate. Therefore a certificate for tomcat should be bind to the virtual host running the service
see virtualHostname.

Assign your host name to common name component. ie: cn=virtual-host.example.com
The others, optional, parts of the subject are

1. Either a set of Organisation name and Country code_ ie: o=My_Organisation, c=US
2. Either a set of many DC Domain Components ie: "dc=example,dc=com" standing for example.com
3. Optionally you may have organisation units ie: ou=Finance or ou=hosts or ou=services
4. Optionally you may have additional cn as used by Microsoft naming scheme (cn=My_Name,cn=Users,..)

Finally you obtain your subject value called a Distinguished Name abreviated as DN

1. example 1: cn=virtual-host.example.com
2. example 2: cn=virtual-host.example.com,o=My_Organisation,c=US
3. example 3: cn=virtual-host.example.com,dc=example,dc=com
4. example 4: cn=example-host.example.com,ou=hosts,dc=example,dc=com
5. example 5: cn=virtual-host.example.com,ou=Virtualhosts,dc=example,dc=com

This is the OSI naming scheme, also used in LDAP directories (like Microsoft AD) and X400 mail systems. If your certificate is stored in an LDAP directory, it could be stored in the same DIT (Directory Information Tree) as the one of it's Distinguished name, or it could be stored under another DIT. Similarly your X400 O/R e-mail address could be the DN (except with DC components) or another.

openOSI stores the public signed certificates this way for class 1

• DIT is "ou=VirtualHosts,dc=openosi,dc=org"
• ObjectClass=top, ObjectClass=Device, ObjectClass=StrongAuthenticationUser
• cn=virtual-host.example.com - The cn value of certificate subject
• userCertificate="Binary form of your public certificate"

That is, if requesting an openOSI signed certificate, there is no need to fill something else than the common name as your host name, because openOSI will not certify additional information for its class 1 certification. Others parts like "o=My_Organisation, c=US" will be removed from the certificate unless you require a class 2 certificate (not available for now and subject to peer agreement).

Example of a keytool request embedding the DN
Where dn: cn=virtual-host.example.com,ou=Virtualhosts,dc=example,dc=com

Handy Hint If you choose to generate yourself a certificate request (CSR) using keytool or any other tools including openssl, Microsoft windows based tools it could be mandatory to fill all attributes like country, organisation, organisation unit, location .... We recommend you enter as few information as possible, entering blanks where appropriate, because a certification authority is supposed to verify all the requested attributes. This is not necessary for tomcat operations and is costly (however the CA could silently drop some of your unverified attributes). Many HOW TO on internet suggest you create self signed certificates which avoid this problem. We don't recommend this unless you have the ability to manage a complete secure PKI (Public Key Infrastructure) to handle secure storage, directories, renewals and revocations. openOSI offers you a free open source PKI infrastructure for class 1 / 2 certification.

Here is the keytool dialog

---

Return to top of page topTomcatSSL

Verify your certificate purpose: client/server authentication

• If you use an on line submission, choose the appropriate submission form
• If you generate your request use the appropriate template if available (no templates for keytool)

Key usage should be:

• Digital signature
• Key encipherment
• Data encipherment

Extended key usage should be (see RFC 3280):

• Server auth(include OID=1.3.6.1.5.5.7.3.1)
• client auth (include OID=1.3.6.1.5.5.7.3.2)

If you can't verify your certificate purpose, or if it's not included in your request, check the appropriate procedure with the Certification authority. The CA MAY insert the appropriate key usage and extended key usage in your signed certificate.

---

Return to top of page topTomcatSSL

Retrieve your signed certificate

You can retrieve your certificate from an on line certification authority or from an LDAP directory. In the later case you could only retrieve the public key, providing the private key was generated locally.

• For an on line retrieval go the appropriate URL of the certification authority
• For an LDAP retrieval, launch an LDAP query
  • i.e.: for openOSI LDAP directory use the following URI
    

    ldap://directory.openosi,org/ou=VirtualHost,dc=openosi,dc=org?userCertificate?one?cn=virtual-host.example.com

In that case the reply is a single x509 certificate without embedded CA certificates. Therefore you will have to download these CA CAcertsRetrieve, unless they already are in you default cacerts java key store.

For further use with keytool utility, the certificate could be either in DER (usually Microsoft file extension .der or .cer or .crt) or PEM format (usually linux notation .pem). DER (Distinguished Encoding Rules) is also known as Binary Encoding Format an encoding of ASN1 values; PEM (Privacy Enhanced Mail) is also known as BASE64 or printable encoding format following RFC1421. JAVA world and MICROSOFT prefers OSI standards as ASN1 and DER, when LINUX world prefers PEM RFC1421. Also note there is a slight difference between .cer and .der, but out of the scope of this document. Also note that mobile devices often use WTLS or X968 format derived from X509 certificates.

Depending on the certification authority (CA) you choose, a bundle of your certificate with corresponding CA certificates may be available in a so called PKCS7 format (file with Microsoft extension .p7c or .p7b). This bundle is also called a certificates chain

Openosi may provide directly a java key store (JKS), when the full request is submitted online, that is when the private key is generated by the openosi server (you do not have to paste a PKCS10 certificate request or submit a CSR sfile, see online procedure).

---

Return to top of page topTomcatSSL

Verify your certificate purpose

You may use several tools to edit your certificate, including Windows, providing the file have an appropriate file extension corresponding to its format(.crt, .cer, .der for DER format which is different from PEM). Conversion tools are out of the scope of this document.

When editing the certificate details under "Enhanced key usage" it should show
Server Authentication(1.3.6.1.5.5.7.3.1)
Client Authentication(1.3.6.1.5.5.7.3.2)
Secure Email(1.3.6.1.5.5.7.3.4) # this is optional but usefull for address book storage (which is intended for persons)

When editing the certificate details under "key usage" it should show
Digital Signature, Key Encipherment, Data Encipherment(b0)

There is an openssl command to verify the purpose
In the example the certificate file name is: virtual-host.example.com.pem using PEM format

Or with Certification authority certificate file name: virtual-hostCA.crt
Should answer as shown

Useful Information A certificate with no purpose (or Any Purpose : Yes) is a security risk. It could be misused if it is silently stolen from your host with its private key. It could allow anybody to impersonate you or any of your hosts daemons over the Internet. This risk is greater when you have not appropriate Public Key Infrastructure managing revocation lists of certificates. It's a good practice to limit the certificate to its main purpose. Be aware that silent defaults of most HOW TO over Internet build any purpose certificates

---

Return to top of page topTomcatSSL

check the content of your signed certificate for a correct cn

This cn should contain the FQDN of your host see virtualHostname
The subject (DN) could be slightly different of the request because the Certification authority has removed the attributes it can't verify under its current policy (namely a level of assurance of class 1, 2 ...). This policy is indicated as a certificate practice statement or CPS

You may use several tools to edit your certificate, including Windows, providing the file have an appropriate file extension corresponding to its format(.crt for DER format which is different from PEM). Conversion tools are out of the scope of this document.

When editing the certificate details under "Subject", it should show
The order is not important
DC = com
DC = example
OU = VirtualHosts
CN = virtual-host.example.com

When editing the certificate details with openssl command line, it should show:
In the example the certificate file name is: virtual-host.example.com.pem using PEM format

or
In the example the certificate file name is: virtual-host.example.com.crt using DER format

Note that DC and OU components MAY be empty. CN component MUST be present and reflect your fully qualified host name (or TOMCAT virtual host name)

---

Return to top of page topTomcatSSL

Get your associated certificate private key

Either locally or from the online enrollment

Locally, your private key is in your newly created Java Key Store see keytoolCli
From an on line certification authority, you probably retrieve a bundle of

• Your private key
• You signed certificate
• The Certification Authority certificate(s)

It comes in JAVA KEY STORE or PKCS12 format (with .p12 .pfx extension for MS Windows)
Althought Tomcat MAY use PKCS12 format (with keystoreType="PKCS12" in the SSL connector element), it is recommended to export all the components to JKS format (JAVA standard) for coherence with others Java applications.

To convert the PKCS12 bundle virtual-host.p12 to JKS virtual-host.jks
Provided org.mortbay.jetty.jar is installed in /opt

You can get org.mortbay.jetty.jar here

---

Return to top of page topTomcatSSL

Retrieve the Certification Authority certificate(s)

If you used the openOSI Certification Authority you will get the certificates on openosi web service .

• Intermediate CA certificate of class 1: openosiCA1-DC
• Root CA certificate of class 3: openosiCA3-EU

You can also check the openosi LDAP directory

For others CA check their documentation

---

Return to top of page topTomcatSSL

Update your Java Key Store with CA certificates

Either:

1. The default JKS cacerts for all trusted CA
2. The newly created JKS virtual_host.jks see keytoolcli
3. If you retreive a JKS from your CA (or convert PKCS12 to JKS), there is no need to update
   • You MAY extract the CA certificate from the virtual-host.jks JKS to put it in the default cacerts JKS. That is, if you want all your Java applications to trust the CA used for tomcat

How to update your virtual-host.jks with CA certificate single file
Where openosiCA3-EU.crt is the CA Root certificate in DER format returned by the CA
Where openosiCA1-DC.crt is the CA intermediate certificate in DER format returned by the CA
Replace where appropriate for others CA

How to update your virtual-host.jks with CA certificate bundle file
Where bundle file is in PKCS7 format (.p7b or .p7c extension)
Where bundle file name is openosiCA1-DC.p7b
Replace where appropriate for others CA

Your signed certificate and the CA certificates openosiCA1-DC and openosiCA3-EU are imported simultaneously.

How to extract the CA certificate from the JKS virtual-host.jks
Where openosiCA1-DC is the alias of openosi Intermediate CA of class 1
Where openosiCA3-EU is the alias of openosi Root CA of class 3
Where JKS password is mypasswd
Replace where appropriate for others CA

Then you can import these CA certificates in the Java JVM wide default CA file cacerts
Where default cacerts location is /usr/lib/jvm/java/jre/lib/security/cacerts
Where the cacerts jks password is changeit
Replace where appropriate for others CA

Useful information If the alias (arbitrary name you choose) does not exist in the keystore (no private key entry), keytool creates a trusted certificate entry with the specified alias, and associates it with the imported certificate. This is a general rule concerning CA certificates as well as external user's certificate.

Importing CA Avoid confusion about trustcacerts option of the keytool import command, it has nothing to do with import of a CA certificate file!

---

Return to top of page topTomcatSSL

Update your Java Key Store with your signed certificate

The process depends on the format of the signed certificate returned

• For a Java Key Store JKS bundle, there is nothing to do.
• For a PKCS7 bundle file see CAcertsupdate
• For a single file, import it in your JKS

How to update your virtual-host.jks
Where virtual-host.crt is the signed certificate returned by the CA
Could be PEM or DER format
Where virtual-host.jks is mypasswd
Where -trustcacerts option requires a check of trusted CA from cacerts JKS

When importing a certificate reply, the certificate reply is validated using trusted certificates from the current keystore, and if the -trustcacerts option was specified the certificate reply is also validated using the certificates from cacerts keystore file.

Be Careful If you don't specifies the virtual-host.jks keystore with -keystore option, the login user's default is used which is .keystore at home root ($HOME/.keystore). If you want it to be recognized by tomcat with default settings, this should be in the tomcat user's home directory (i.e: $CATALINA_HOME/.keystore, if $CATALINA_HOME is set as the tomcat user's home). Otherwise set the keystore location inside the SSL connector element with KEYSTOREFILE option. Double check this location if you use chrooted tomcat.

---

Return to top of page topTomcatSSL

Retrieve the Certification Authority CRL (certificate revocation list)

If you used the openOSI Certification authority you can retrieve the CRL for each CA certificate at the following URL
http://crl.openosi.org/pki/publicweb/webdist/certdist?cmd=crl&issuer=cn=opeosiCA1-DC,ou=pki,dc=openosi,dc=org
http://crl.openosi.org/pki/publicweb/webdist/certdist?cmd=crl&issuer=cn=opeosiCA3-FR,ou=pki,o=osi,c=fr

You can also check our LDAP directory

Otherwise you should check the value of "CRL Distribution points" in your certificate details, to get the appropriate URL.

---

Return to top of page topTomcatSSL

Update certificate repository with CRLs in /etc/pki/tomcat.tls/crls/ or /etc/tomcat5/tls/crls/

The support of Certificate revocation list (CRL) by tomcat is not currently "out of the box", although some documentation instructs to use the CRLFILES attibute inside the SSL connector definition with the location of the CRL file on your system (as of tomcat5.5.10). We don't recommands this tomcat undocumented feature, unless you know what you do. If you want a documented support of CRL in TOMCAT, use the APR (Apache Portable Runtime) to get openssl features. For more details check APR doc

Shortly
When APR is enabled, you will be able to use the following additional attributes inside your SSL Connector, see connectorSSL.

• SSLEngine="on"
• SSLCARevocationFile="Path to the CRL file"
• SSLCARevocationPath="Path to the CRL directory"

Useful Information On a Windows computer, APR is a dynamically linked library (DLL) that is installed automatically during a Tomcat installation if the user selects the Native option. You can check whether your system has the APR installed by looking for Tomcat/bin/tcnative-1.dll

openssl configuration

Warning If you use openssl for tomcat, it MAY not be an "out of the box" functionality on your system, due to APR (Apache Portable Runtime). You will also need to use a coherent SSL configuration in your SSL connector (PEM files instead of JKS). Also, there is an SELinux concern when using openssl certificates configuration. You MAY want to copy /etc/pki/tls/ to /etc/tomcat5/tls/ whith "system_u:object_r:etc_t" SELinux context instead of "system_u:object_r:cert_t".

When you get your CRL's files, you also need to create a symbolic link to the hash of your crls as with certificates. But before, you should convert the CRL files you retrieve to PEM format. CRL files are often provided in DER format to fit browsers needs.

Counvert crl from der format to pem format
This example is with openosi crl files names, replace as appropriate to feet your needs

Create the symbolic link to the hash
This example is with openosi crl files names, replace as appropriate to feet your needs

---

Return to top of page topTomcatSSL

Setup a cron job to retrieve regularly updated CRLs

Be Careful A Certificate revocation list is an important security feature. It allows checking for revoked certificates. When a certificate owner feels that a private key was compromised he revokes the certificate and get a new one.

Cron job example for openOSI
No need to update the hash (the subject name doesn't change)
replace as appropriate to feet your needs

---

Return to top of page topTomcatSSL

Decide if you want to keep default Certification authorities bundled file

Generally it is cacerts as indicated here CAcertsupdate

These external CA certificates are used for TLS authentication. From that point of view, the more you have, more likely you could authenticate a peer. But in confined environment, you may want to restrict the accepted CA (especially if you use certificate authentication)

Useful Information If your certification authority certificate is not by default in that bundle of your remote clients, they will be prompted to accept your CA certificate.

If you want a small cacerts JKS limited to few trust CA certificates, create your own cacerts (i.e: cacerts.trust )and replace the default one.

---

Return to top of page topTomcatSSL

Update your SSL connector in /etc/tomcat5/server.xml portSSL

You may define several connectors elements, sharing the same engine container, inside a service element.
Example with .

Minimal example of /etc/tomcat5/server.xml
Where 2 SSL connectors are defined on ports 8443 and port 8444

Default configuration

Without keystore attribute the default value is the cacerts system wide CA certificates bundle, and .keystore in the user home directory under which Tomcat is running, for tomcat certificate and key.

A more detailed example of SSL connector definition
Where tomcat certificate's JKS is /etc/tomcat5/virtual-host.jks, password mypasswd , see certUpdate
Where trusted CA certificates are in cacerts.trust password mypasswd , see certsBundle
Where tomcat alias name is virtual-host (multiple keys in the JKS) , see keytoolCli
Where CRL file is /etc/tomcat5/tls/crls/openosiCA1-DC.crl , see CRLcertsStore
Where we added UTF8 support for international URI encoding URIEncoding="UTF-8"

The same example with use of APR / openssl
Where tomcat certificate is in "/etc/tomcat5/tls/certs/virtual-host.pem" in PEM format
Where tomcat certificate key is in "/etc/tomcat5/tls/private/virtual-host.key" in PEM format
Where trusted CA chained file is "/etc/tomcat5/tls/certs/ca-bundle.crt" in PEM format
Where CRL directory is "/etc/tomcat5/tls/crls"

Handy hint It is easier, most of time, to setup the SSL connection at HTTPD level, then to forward an unencrypted local connection to tomcat with mod_proxy & AJP. Also note that SSL accelerator hardware exist for openssl.

You could use information extracted from certificates to authenticate clients, providing you trust their issuing certification authority (CA). This is a Single Sign On (SSO) solution, where no additional identification, username or passwords are required from the client. The authorization level still rely on client applications.

In the SSL connector you have to set the following attribute
Value "True" requires a client certificate
Value "Want" same as "True" but doesn't fail if no certificate is presented

For more information see tomcat documentation, which is quite poor.

Handy Hint Consider using CAS with X509 certificates for your authentication level. More information on CAS here, with certificates details here and a discussion here

REMINDER

• Always check if you want to keep default /usr/local/java/jre/lib/security/cacerts unchanged
• Avoid multiple keys in a JKS for tomcat service
• Use SSL over HTTPD instead of Tomcat using mod_proxy & AJP for forwarding
• Use CAS authentication with x509 certificates for your applications
• Self-signed certificate usage is discouraged unless for non production environments
• Rudimentary openssl PKI usage is discouraged unless for non production environments
• Keep your certification revocation lists (CRL) up to date
• LDAP directory is an identity repository, not an authentication nor an authorization service

and as usual
...

• Always check your trusted certification authorities (CA)
• Check the CA CPS (Certificate practice statement)to learn about the security policy
• Do not disable SELinux targeted
• Try to use -Multi categories security_ (MCS) to protect your files
• Use yum to update your packages
• Avoid to compile and install packages versions not supported / tested by your distro
• Have as many as possible linux box to handle separate services
• Use chrooted environments
• Keep Microsoft box out of Internet direct access
• Confine as much as possible RPC, XML-RPC and netbios
  ...