DOCUMENTO DE CONSULTA III

Este documento muestra cmo configurar tomcat y struts para aceptar peticiones mediante
Secure Sockets Layer (SSL).

SSL en Tomcat
1. Introduccin
En este tutorial se describe cmo configurar Tomcat para acceder a las aplicaciones web
empleando HTTP sobre SSL. Vamos a utilizar la tcnica sencilla, que es la que se describe
en http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html.Consiste en utilizar la
herramienta keytool, distribuida con el kit de desarrollo de Java, para generar un certificado
autofirmado del servidor. Tambin ser necesario cambiar la configuracin del fichero
server.xml para activar un conector que permitir acceder a Tomcat a travs de https.

2. Software necesario
La herramienta keytool se encuentra en el directorio bin de la instalacin j2sdk. Si estamos
usando una versin anterior a la 1.4, debemos descargar la extensin
de http://java.sun.com/products/jsse/ e incluir los jars en el directorio
$JAVA_HOME/jre/lib/ext. Para los usuarios de una versin igual o superior a la 1.4, no es
necesario descargar nada porque sta utilidad ya viene incluida.

3. Configurando el server.xml
Lo nico que tenemos que hacer es descomentar la parte del siguiente elemento Connector:
<!-- Define a SSL HTTP/1.1 Connector on port 8443 -->
<!-<Connector port="8443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" />
-->
Con esto conseguimos activar el uso de SSL en el puerto 8443. No se solicita certificado al
cliente durante el establecimiento de la conexin SSL (clientAuth = false), por tanto, no es
necesario cambiar nada en el navegador web que usemos, aunque si hay que crear el almacn
de claves en el servidor.

4. Creando el almacn de claves y un certificado autofirmado

Abrimos una consola y ejecutamos:
%JAVA_HOME%\bin\keytool genkey alias tomcat keyalg RSA

Nos pedir una serie de datos para configurar el certificado. Lo primero que nos pide es la
contrasea para el almacn de claves:

La clave por defecto utilizada por Tomcat es changeit y es la que introduciremos. Si

queremos usar cualquier otra clave, lo nico que tenemos que hacer es aadir al Connector el
parmetro keystorePass especificando la clave a usar.
<Connector port="8443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystorePass=mi_clave/>

A continuacin nos pide nuestro nombre, el nombre de nuestra unidad de organizacin, el

nombre de nuestra organizacin, la ciudad o localidad, el estado o provincia, y el cdigo del
pas. Nos pregunta si los datos introducidos son correctos e introducimos si.

A continuacin nos pide la contrasea clave para <tomcat>. Aunque nos permite introducir
una distinta, siempre debemos poner la misma contrasea aqu que la que tenemos en
nuestro almacn de claves (Nos da la opcin de pulsar INTRO para este efecto).
Nota: Esto se indica en la ayuda de Tomcat en http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html. Tomcat
lanzara un java.io.IOException: Cannot recover key si no usaramos la misma clave

Y ya hemos terminado, el proceso nos ha creado un archivo .keystore en el home del usuario:

C:\Documents and Settings\user en sistemas Windows XP

C:\Winnt\Profiles\user en sistemas multi-usuario Windows NT
C:\Windows\Profiles\user en sistemas multi-usuario Windows 95/98
C:\Windows en sistemas de un slo usuario Windows 95/98
Tomcat utiliza por defecto este .keystore para buscar los certificados (el que se encuentra en
el directorio home del usuario). Si quisiramos utilizar un almacn situado en otra ubicacin,
nicamente debemos aadir al Connector el parmetro keystoreFile especificando la ruta
absoluta al fichero, o una ruta relativa resuelta a partir del
%CATALINA_BASE%.
Suponiendo que mi fichero se encuentra en C:\keyStores\.mykeystore:
<Connector port="8443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile=C:\keyStores\.mykeystore/>
Suponiendo que mi %CATALINA_BASE% apunta a C:\servidores\tomcat y mi fichero se
encuentra en C:\servidores\tomcat\keystores\.mykeystore
<Connector port="8443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile=\keyStores\.mykeystore/>
Ahora, arrancamos tomcat y probamos en el navegador https://localhost:8443 para ver si
funciona:

Perfecto, ya tenemos habilitada la configuracin SSL en nuestro tomcat.

Struts: Comunicaciones seguras (SSL)

Es posible que nuestra aplicacin web requiera comunicaciones seguras. Para ello se utiliza
https como protocolo de transporte en lugar del conocido http; es decir se cifran las
comunicaciones a nivel de la capa de transporte mediante Secure Sockets Layer (SSL).
Como es lgico, cifrar las comunicaciones requiere ms recursos (tiempo de cifrar / descifrar,
mensajes ms pesados), y normalmente las aplicaciones no necesitan comunicaciones
seguras ms que en algunas acciones. Por tanto construir toda la aplicacin bajo https no es
tan eficiente como delimitar zonas no seguras (transporte http) y zonas seguras
(transporte htpps) dentro de la misma aplicacin.
Para ello utilizaremos un plug-in de cdigo abierto, la extensin de Struts SSL Extension
(SSLEXT).

La distribucin, sslext.jar y sslext.tld, consiste en una clase para la inicializacin,

SecurePlugIn, una clase para el procesado de peticiones, SecureRequestProcessor, y
una clase para los mapeos de actions, SecureActionMapping.
Necesita Java Secure Socket Extension (JSSE) que se distribuye con el JDK 1.4 o
posteriores.
Lgicamente es necesario que el servidor de aplicaciones que estemos utilizando tenga
habilitado SSL.

Paso a Paso
Para utilizar la extensin por tanto, debemos

incluir sslext.jar y sslext.tld en nuestra aplicacin

[struts-config.xml] - Personalizar los mapeos de las clases actio

<action-mappings type="org.apache.struts.config.SecureActionConfig">

[struts-config.xml] - Personalizar el procesador de peticiones

<controller processorClass="org.apache.struts.action.SecureRequestProcessor" />

[struts-config.xml] - Declarar el plug-in

<plug-in className="org.apache.struts.action.SecurePlugIn">
<set-property property="httpPort" value="80"/>
<set-property property="httpsPort" value="8443"/>
<set-property property="enable" value="true"/>
<set-property property="addSession" value="true"/>
</plug-in>

[struts-config.xml] - Marcar las acciones seguras mediante la propiedad secure a TRUE

<action path="/inicio*" type="es.mec.accionesintegradas.control.actions.InicioAction"

parameter="inicio{1}" >
<! Obligamos a esta accin a utilizar https : segura >

<set-property property="secure" value="true"/>

<forward name="success" path="/iniciaLogin{1}.mec" />
</action>

[struts-config.xml] - Marcamos las acciones no seguras mediante la propiedad secure a

FALSE

<action path="/salir*" type="es.mec.accionesintegradas.control.actions.LogoutAction"

parameter="logout{1}">
<! Obligamos a esta accin a utilizar http : NO segura >
<set-property property="secure" value="false"/>
<forward name="success" path="/iniciaLogin{1}.mec" />
</action>

Si queremos especificar que una pgina JSP sea segura (o no segura) :

<%@ taglib uri="http://www.ebuilt.com/taglib" prefix="sslext"%>

<sslext:pageScheme secure="true"/>

Crtico: Cambio http <-> https

Realizar un cambio de http a https y viceversa implica cambiar el protocolo de transporte y el
puerto de comunicacin (8080 a 8443 443). Puede influir en los CortaFuegos de los sistemas
de comunicaciones de la empresa (hay que habilitar esos puertos tambin!). Internamente es
importante saber que internamente este cambio de protocolo implica realizar un redirect.
Finalmente cambiar de una comunicacin segura a no segura puede exponer datos crticos
seguros a un usuario malicioso que suplante la personalidad del usuario legtimo. Normalmente
una vez que se establece una conexin segura no se debe volver a una no segura.