Software Architecture, Architects and Opinions: Aug 25, 2012

Setting the server certificate

Create a server certificate for Tomcat and setup in the server. Refer my earlier post for details on how a certificate can be obtained.
Double check whether the Root cert needs to be imported in trustcacerts. it might be safe to do:

keytool -import -trustcacerts -alias <ca-cert-alias> -file <ca-cert-filename>

Tomcat Connector configuration in server.xml.

<Connector

executor="tomcatThreadPool"

port="9443"

protocol="HTTP/1.1"

connectionTimeout="20000"

redirectPort="8443"

acceptCount="100"

maxKeepAliveRequests="15"

keystoreFile="eclipse-workspace/security-utils/resources/manojkeystore.jks"

keystorePass=""

keyAlias="manojscepcertificate"

keyPass=""

SSLEnabled="true"

scheme="https"

secure="true"/>

Some of the attributes are the same as those of the basic HTTP connector, such as executor, protocol, connectionTimeout, maxKeepAliveRequests, and acceptCount. Note that although this connector will be used for HTTPS connections, you still set protocol to HTTP/1.1; other attributes will specify that this is an SSL-enabled connection.
The TCP/IP port that users specify as the secure connection port is 9443. Be sure that you set the value of the redirectPort attribute of your non-SSL connectors to this value to ensure that users that require a secure connection are redirected to the secure port, even if they initially start at the non-secure port.
The SSLEnabled attribute specifies that SSL is enabled for this connector.
The secure attribute ensures that a call to request.isSecure() from the connecting client always returns true. The default value of this attribute is false.
The scheme attribute ensures that a call to request.getScheme() from the connecting client always returns https when clients use this connector. The default value of this attribute is http.
The keystoreFile attribute specifies the name of the file that contains the server's private key and public certificate used in the SSL handshake, encryption, and decryption. You use an alias and password to access this information.
The keyAlias and keystorePass attributes specify the alias (and password) used to access the keystore specified by the keystoreFile attribute.
keyPass specified the password for the key entry in the JKS. Usually this is not set or set to be the same as the keystore password.

If the key entry was set programmatically then this password is set and has to be specified.

Limiting SSL Usage

Enabling SSL in Tomcat's server.xml file causes all files to be run both as secure and insecure pages, which can cause unnecessary server load. You can choose which applications offer SSL connections on a per-application basis by adding the following <security-constraint> element to the application's WEB-INF/web.xml file:

<security-constraint>

<web-resource-collection>

<web-resource-name>YourAppsName</web-resource-name>

<url-pattern>/*</url-pattern>

</web-resource-collection>

<user-data-constraint>

<transport-guarantee>CONFIDENTIAL</transport-guarantee>

</user-data-constraint>

</security-constraint>

This configuration allows you to set SSL options for all an application's pages in one place. For example, to disable SSL for all your application's pages, change "CONFIDENTIAL" to "NONE".

Specifying Implementation

If you have configured connectors for both APR and JSSE, Tomcat will use APR by default if you have installed the native libraries. You can force it to use JSSE by modifying a Connector's "protocol" attribute as follows:

If you want to force APR, you can do so with a similar edit:

Verification

Verify if tomcat is now showing the SSL cert. On my local server, the url is https://localhost:9443/SampleApp/services/SampleWebServiceImplPort?wsdl

SSL Cipher Strength

<TODO> Add more details about Cipher strengths and testing etc. Maybe another blog post about tools.

Note

Note: Using name-based virtual hosts on a secured connection can be problematic. This is a design limitation of the SSL protocol itself. The SSL handshake, where the client browser accepts the server certificate, must occur before the HTTP request is accessed. As a result, the request information containing the virtual host name cannot be determined prior to authentication, and it is therefore not possible to assign multiple certificates to a single IP address. If all virtual hosts on a single IP address need to authenticate against the same certificate, the addition of multiple virtual hosts should not interfere with normal SSL operations on the server. Be aware, however, that most client browsers will compare the server's domain name against the domain name listed in the certificate, if any (applicable primarily to official, CA-signed certificates). If the domain names do not match, these browsers will display a warning to the client user. In general, only address-based virtual hosts are commonly used with SSL in a production environment.

For details refer: http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html

Setting Up a Server Certificate

http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Security10.html

Tomcat SSL configuration

http://www.mulesoft.com/tomcat-ssl

http://techtracer.com/2007/09/12/setting-up-ssl-on-tomcat-in-3-easy-steps/