Cómo configurar Apache con soporte SSL/TLS.

Autor: Joel Barrios Dueñas
Correo electrónico: darkshram en gmail punto com
Sitio de Red: http://www.alcancelibre.org/
Jabber ID: darkshram@jabber.org

Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.1

© 1999-2007 Joel Barrios Dueñas. Usted es libre de copiar, distribuir y comunicar públicamente la obra y hacer obras derivadas bajo las condiciones siguientes: a) Debe reconocer y citar al autor original. b) No puede utilizar esta obra para fines comerciales (incluyendo su publicación, a través de cualquier medio, por entidades con fines de lucro). c) Si altera o transforma esta obra, o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta. Al reutilizar o distribuir la obra, tiene que dejar bien claro los términos de la licencia de esta obra. Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular de los derechos de autor. Los derechos derivados de usos legítimos u otras limitaciones no se ven afectados por lo anterior. Licencia completa en castellano. La información contenida en este documento y los derivados de éste se proporcionan tal cual son y los autores no asumirán responsabilidad alguna si el usuario o lector hace mal uso de éstos.

Introducción.

Acerca de HTTPS.

HTTPS es la versión segura del protocolo HTTP, inventada en 1996 por Netscape Communications Corporation. No es un protocolo separado de HTTP. Se trata de una combinación de este último con un mecanismo de transporte SSL o TLS, garantizando una protección razonable durante la comunicación cliente-servidor. Es ampliamente utilizado en la red mundial (WWW o World Wide Web) para comunicaciones como transacciones bancarias y pago de bienes y servicios.

El servicio utiliza el puerto 443 por TCP para realizar las comunicaciones (la comunicación normal para HTTP utiliza el 80 por TCP). El esquema URI (Uniform Resource Identifier o Identificador Uniforme de Recursos) es, comparando sintaxis, idéntico al de HTTP (http:), utilizándose como «https:» seguido del subconjunto denominado URL (Uniform Resource Locator o Localizador Uniforme de Recursos). Ejemplo: https://www.dominio.org/

URL: http://es.wikipedia.org/wiki/HTTPS y http://wp.netscape.com/eng/ssl3/draft302.txt

Acerca de RSA.

RSA, acrónimo de los apellidos de sus autores, Ron Rivest, Adi Shamir y Len Adleman, es un algoritmo para el ciframiento de claves públicas que fue publicado en 1977, patentado en EE.UU. en 1983 por el el Instituto Tecnológico de Michigan (MIT). RSA es utilizado ampliamente en todo el mundo para los protocolos destinados para el comercio electrónico.

URL: http://es.wikipedia.org/wiki/RSA

Acerca de Triple DES.

Triple DES, o TDES, es un algoritmo que realiza un triple cifrado DES, desarrollado por IBM en 1978. Su origen tuvo como finalidad el agrandar la longitud de una clave sin necesidad de cambiar el algoritmo de ciframiento, lo cual lo hace más seguro que el algoritmo DES, obligando a un atacante el tener que triplicar el número de operaciones para poder hacer daño. A pesar de que actualmente está siendo reemplazado por el algoritmo AES (Advanced Encryption Standard, también conocido como Rijndael), sigue siendo estándar para las tarjetas de crédito y operaciones de comercio electrónico.

URL: http://es.wikipedia.org/wiki/Triple_DES

Acerca de X.509.

X.509 es un estándar ITU-T (estandarización de Telecomunicaciones de la International Telecommunication Union ) para infraestructura de claves públicas (PKI, o Public Key Infrastructure). Entre otras cosas, establece los estándares para certificados de claves públicas y un algoritmo para validación de ruta de certificación. Este último se encarga de verificar que la ruta de un certificado sea válida bajo una infraestructura de clave pública determinada. Es decir, desde el certificado inicial, pasando por certificados intermedios, hasta el certificado de confianza emitido por una Autoridad Certificadora (CA, o Certification Authority).

URL: http://es.wikipedia.org/wiki/X.509

Acerca de OpenSSL.

OpenSSL es una implementación libre, de código abierto, de los protocolos SSL (Secure Sockets Layer o Nivel de Zócalo Seguro) y TLS (Transport Layer Security, o Seguridad para Nivel de Transporte). Está basado sobre el extinto proyecto SSLeay, iniciado por Eric Young y Tim Hudson, hasta que éstos comenzaron a trabajar para la división de seguridad de EMC Corporation.

URL: http://www.openssl.org/

Acerca de mod_ssl.

Mod_ssl es un módulo para el servidor HTTP Apache, el cual provee soporte para SSL versiones 2 y 3 y TLS versión 1. Es una contribución de Ralf S. Engeschall, derivado del trabajo de Ben Laurie.

URL: http://www.apache-ssl.org/ y http://httpd.apache.org/docs/2.2/mod/mod_ssl.html

Requisitos.

Es necesario disponer de una dirección IP pública para cada sitio de red virtual que se quiera configurar con soporte SSL/TLS. Debido a la naturaleza de los protocolos SSL y TLS, no es posible utilizar múltiples sitios de red virtuales con soporte SSL/TLS utilizando una misma dirección IP. Cada certificado utilizado requerirá una dirección IP independiente en el sitio de red virtual.

El paquete mod_ssl instala el fichero /etc/httpd/conf.d/ssl.conf, mismo que no es necesario modificar, puesto que se utilizarán ficheros de inclusión, con extensión *.conf, dentro del directorio /etc/httpd/conf.d/, a fin de respetar la configuración predeterminada y podre contar con la misma, que es funcional, brindando un punto de retorno en el caso de que algo saliera mal.

Equipamiento lógico necesario.

Instalación a través de yum.

Si se utiliza de CentOS 4 o White Box Enterprise Linux 4, se ejecuta lo siguiente:

yum -y install mod_ssl

Instalación a través de Up2date

Si se utiliza de Red Hat™ Enterprise Linux 4, se ejecuta lo siguiente:

up2date -i mod_ssl

Procedimientos.

Acceda al sistema como el usuario root.

Se debe crear el directorio donde se almacenarán los certificados para todos los sitios SSL. El directorio, por motivos de seguridad, debe ser solamente accesible para el usuario root.

mkdir -m 0700 /etc/ssl

A fin de mantener cierta organización, y un directorio dedicado para cada sitio virtual SSL, es conveniente crear un directorio específico para almacenar los certificados de cada sitio virtual SSL. Igualmente, por motivos de seguridad, debe ser solamente accesible para el usuario root.

mkdir -m 0700 /etc/ssl/midominio.org

Acceder al directorio que se acaba de crear.

cd /etc/ssl/midominio.org

Generando clave y certificado.

Se debe crear una clave con algoritmo RSA de 1024 octetos y estructura x509, la cual se cifra utilizado Triple DES (Data Encryption Standard), almacenado en formato PEM de modo que sea interpretable como texto ASCII. En el proceso descrito a continuación, se utilizan 5 ficheros comprimidos con gzip, que se utilizan como semillas aleatorias que mejoran la seguridad de la clave creada (server.key).

openssl genrsa -des3 -rand fichero1.gz:fichero2.gz:fichero3.gz:fichero4.gz:fichero5.gz -out server.key 1024

Si se utiliza este fichero (server.key) para la configuración del sitio virtual, se requerirá de interacción del administrador cada vez que se tenga que iniciar, o reiniciar, el servicio httpd, ingresando la clave de acceso de la clave RSA. Este es el procedimiento más seguro, sin embargo, debido a que resultaría poco práctico tener que ingresar una clave de acceso cada vez que se inicie el servicio httpd, resulta conveniente generar una clave sin Triple DES, la cual permita iniciar normalmente, sin interacción alguna, al servicio httpd. A fin de que no se sacrifique demasiada seguridad, es un requisito indispensable que esta clave (fichero server.pem) solo sea accesible para root. Ésta es la razón por la cual se crea el directorio /etc/ssl/midominio.org con permiso de acceso solo para root.

openssl rsa -in server.key -out server.pem

Opcionalmente se genera un fichero de petición CSR (Certificate Signing Request) que se hace llegar a una RA (Registration Authority o Autoridad de Registro), como Verisign, quienes, tras el correspondiente pago, envían de vuelta un certificado (server.crt) firmado por dicha autoridad.

openssl req -new -key server.key -out server.csr

Lo anterior solicitará se ingresen varios datos:

•  Código de dos letras para el país.
•  Estado o provincia.
•  Ciudad.
•  Nombre de la empresa o razón social.
•  Unidad o sección.
•  Nombre del anfitrión.
•  Dirección de correo.
•  Opcionalmente se puede añadir otra clave de acceso y nuevamente el nombre de la empresa.

La salida devuelta sería similar a la siguiente:

You are about to be asked to enter information that will be
incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or
a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:MX
State or Province Name (full name) [Berkshire]:Distrito Federal
Locality Name (eg, city) [Newbury]:Mexico
Organization Name (eg, company) [My Company Ltd]:
Mi empresa, S.A. de C.V.
Organizational Unit Name (eg, section) []:Direccion Comercial
Common Name (eg, your name or your server's hostname) []:
www.midominio.org
Email Address []:webmaster@midominio.org

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Si no se desea un certificado firmado por un RA, puede generarse uno certificado propio utilizando el fichero de petición CSR (server.csr). En el ejemplo a continuación, se crea un certificado con estructura X.509 en el que se establece una validez por 730 días (dos años).

openssl x509 -req -days 730 -in server.csr -signkey server.key -out server.crt

Con la finalidad de que solo el usuario root pueda acceder a los ficheros creados, se deben cambiar los permisos de éstos a solo lectura para root.

chmod 400 /etc/ssl/midominio.org/server.*

Configuración de Apache.

Crear la estructura de directorios para el sitio de red virtual.

mkdir -p /var/www/midominio.org/{cgi-bin,html,logs,etc,var}

De todos directorios creados, solo /var/www/midominio.org/html, /var/www/midominio.org/etc, /var/www/midominio.org/cgi-bin y /var/www/midominio.org/var pueden pertenecer al usuario, sin privilegios, que administrará éste sitio de red virtual. Por motivos de seguridad, y a fin de evitar que el servicio HTTPD no sea trastornado en caso de un borrado accidental de algún directorio, tanto /var/www/midominio.org/ como /var/www/midominio.org/logs, deben pertenecer al usuario root.

Crear el fichero /etc/httpd/conf.d/midominio.conf con el siguiente contenido, donde a.b.c.d corresponde a una dirección IP, y midominio.org corresponde al nombre de dominio a configurar para el sitio de red virtual:

### midominio.org ###
NameVirtualHost a.b.c.d:80
	<VirtualHost a.b.c.d:80>
		ServerAdmin webmaster@midominio.org
		DocumentRoot /var/www/midominio.org/html
		ServerName www.midominio.org
		ServerAlias midominio.org
		Redirect 301 / https://www.midominio.org/
		CustomLog /var/www/midominio.org/logs/access_log combined
		Errorlog /var/www/midominio.org/logs/error_log
	</VirtualHost>

NameVirtualHost a.b.c.d:443
	<VirtualHost a.b.c.d:443>
		ServerAdmin webmaster@midominio.org
		DocumentRoot /var/www/midominio.org/html
		ServerName www.midominio.org
		ScriptAlias /cgi-bin/ /var/www/midominio.org/cgi-bin/
		SSLEngine on
		SSLCertificateFile /etc/ssl/midominio.org/server.crt
		SSLCertificateKeyFile /etc/ssl/midominio.org/server.pem
		SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
		CustomLog /var/www/midominio.org/logs/ssl_request_log \
			"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x "%r" %b"
		CustomLog /var/www/midominio.org/logs/ssl_access_log combined
		Errorlog /var/www/midominio.org/logs/ssl_error_log
	</VirtualHost>

A fin de que surtan efecto los cambios, es necesario reiniciar el servicio httpd.

service httpd restart

Comprobación.

Solo basta dirigir cualquier navegador HTTP hacia https://www.midominio.org/ a fin de verificar que todo esté trabajando correctamente. Tras aceptar el certificado, en el caso de que éste no haya sido firmado por un RA, deberá poderse observar un signo en la barra de estado del navegador, el cual indica que se trata de una conexión segura.

Modificaciones necesarias en el muro cortafuegos.

Si se utiliza un cortafuegos con políticas estrictas, como por ejemplo Shorewall, es necesario abrir, además del puerto 80 por TCP (HTTP), el puerto 443 por TCP (HTTPS).

Las reglas para el fichero /etc/shorewall/rules de Shorewall correspondería a algo similar a lo siguiente:

#ACTION	SOURCE	DEST	PROTO 	DEST		SOURCE
#				PORT		PORT(S)1
ACCEPT	net	fw	tcp	80,443
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

Alcance Libre
http://www.alcancelibre.org/staticpages/index.php/como-apache-ssl