Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.1

© 1999-2011 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.tld/

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).

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 anfitrión virtual.

El paquete mod_ssl instala el archivo /etc/httpd/conf.d/ssl.conf, mismo que no es necesario modificar, puesto que se utilizarán archivos 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 5 o 6, o bien Red Hat Enterprise Linux 5 o 6, ejecute lo siguiente:

yum -y install mod_ssl

Procedimientos.

Generando firma digital y certificado.

Acceda al sistema como el usuario root.

Acceda al directorio /etc/pki/tls/.

cd /etc/pki/tls

En caso de que existieran previamente, debe eliminar los archivos certs/dominio.tld.crt, certs/dominio.tld.crs, private/dominio.tld.key y private/dominio.tld.pem.

rm -f certs/dominio.tld.crt private/dominio.tld.key
rm -f certs/dominio.tld.csr private/dominio.tld.pem 

Se debe crear una clave con algoritmo RSA de 2048 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. se solicitará una clave de acceso para asignar a la firma digital, por lo que se recomienda utilizar una muy buena clave de acceso, la cual, mientras más complicada y difícil sea, mejor.

openssl genrsa -des3 -out private/dominio.tld.key 2048

Si se utiliza este archivo (dominio.tld.key) para la configuración del anfitrión 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 firma digital. 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 más conveniente generar una firma digital RSA, la cual permita iniciar normalmente y sin interacción alguna, al servicio httpd.

openssl rsa -in private/dominio.tld.key -out private/dominio.tld.pem

El archivo dominio.tld.pem será el que se especifique más adelante como valor del parámetro SSLCertificateKeyFile en la configuración de Apache.

A continuación, genere el archivo CSR (Certificate Signing Request), el cual es el archivo de solicitud 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 (para ser utilizado como el archivo dominio.tld.crt) firmado por dicha autoridad certificadora.

openssl req -new -key private/dominio.tld.key -out certs/dominio.tld.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. Debe ser el nombre con el que se accederá hacia el servidor, y dicho nombre deberá estar resuelto en un DNS. SI lo desea, puede utilizar también *.dominio.tld.
• Dirección de correo electrónico válida del administrador del sistema.
• De manera opcional se puede añadir otra clave de acceso y nuevamente el nombre de la empresa. Poco recomendado, a menos que quiera ingresar ésta cada vez que se inicie o reinicie el servicio httpd.

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]:Empresa, S.A. de C.V.
Organizational Unit Name (eg, section) []:Direccion Comercial
Common Name (eg, your name or your server's hostname) []:*.dominio.tld
Email Address []:webmaster@dominio.tld

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

Si requiere un certificado auto-firmado, en lugar de un certificado firmado por un RA, puede generarse éste utilizando el archivo de petición CSR (dominio.tld.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).

Con la finalidad de que sólo el usuario root pueda acceder a los archivos creados, se deben cambiar los permisos de éstos a sólo lectura para root.

chmod 400 private/dominio.tld.key private/dominio.tld.pem
chmod 400 certs/dominio.tld.csr certs/dominio.tld.crt

Configuración simple de Apache para un solo dominio.

Edite el archivo /etc/httpd/conf.d/ssl.conf:

vim /etc/httpd/conf.d/ssl.conf

Localice lo siguiente:

#   Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate.  If
# the certificate is encrypted, then you will be prompted for a
# pass phrase.  Note that a kill -HUP will prompt again.  A new
# certificate can be generated using the genkey(1) command.
SSLCertificateFile /etc/pki/tls/certs/localhost.crt

#   Server Private Key:
#   If the key is not combined with the certificate, use this
#   directive to point at the key file.  Keep in mind that if
#   you've both a RSA and a DSA private key you can configure
#   both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

Cambie localhost.crt y localhost.key, por dominio.tld.crt y dominio.tld.pem:

#   Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate.  If
# the certificate is encrypted, then you will be prompted for a
# pass phrase.  Note that a kill -HUP will prompt again.  A new
# certificate can be generated using the genkey(1) command.
SSLCertificateFile /etc/pki/tls/certs/dominio.tld.crt

#   Server Private Key:
#   If the key is not combined with the certificate, use this
#   directive to point at the key file.  Keep in mind that if
#   you've both a RSA and a DSA private key you can configure
#   both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /etc/pki/tls/private/dominio.tld.pem

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

service httpd restart

Lo anterior deberá de proceder sin solicitar la clave de acceso de la firma digital (la que asignó cuando se creo dominio.tld.key). En caso contrario, significa que estableció dominio.tld.key como valor del parámetro SSLCertificateKeyFile en la configuración de Apache.

Configuración de Apache para múltiples dominios.

Omita el procedimiento anterior.

Es importante resaltar que cada dominio deberá contar con su propia dirección IP, pues el protocolo HTTPS impedirá utilizar más de un certificado por dirección IP.

El primer paso consiste en crear la estructura de directorios para el anfitrión virtual.

mkdir -p /var/www/dominio.tld/{cgi-bin,html,logs,etc}

De todos directorios creados, sólo /var/www/dominio.tld/html, /var/www/dominio.tld/etc y /var/www/dominio.tld/cgi-bin pueden pertenecer a un usuario sin privilegios, quien administrará este anfitrión virtual.

Crear el archivo /etc/httpd/conf.d/dominio.conf:

vim /etc/httpd/conf.d/dominio.conf

Adaptar la siguiente plantilla como contenido de este archivo, donde a.b.c.d corresponde a una dirección IP, y dominio.tld corresponde al nombre de dominio a configurar para el anfitrión virtual:

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

NameVirtualHost a.b.c.d:443
	<VirtualHost a.b.c.d:443>
		ServerAdmin webmaster@dominio.tld
		DocumentRoot /var/www/dominio.tld/html
		ServerName www.dominio.tld
		ScriptAlias /cgi-bin/ /var/www/dominio.tld/cgi-bin/
		<Directory "/var/www/dominio.tld/cgi-bin">
			SSLOptions +StdEnvVars
		</Directory>
		SSLEngine on
		SSLProtocol all -SSLv2
		SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
		SSLCertificateFile /etc/pki/tls/certs/dominio.tld.crt
		SSLCertificateKeyFile /etc/pki/tls/private/dominio.tld.pem
		SetEnvIf User-Agent ".*MSIE.*" \
			nokeepalive ssl-unclean-shutdown \
			downgrade-1.0 force-response-1.0
		CustomLog logs/dominio.tld-ssl_request_log \
			"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
		Errorlog logs/dominio.tld-ssl_error_log
		TransferLog logs/dominio.tld-ssl_access_log
		LogLevel warn
	</VirtualHost>

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

service httpd restart

Lo anterior deberá de proceder sin solicitar la clave de acceso de la firma digital (la que asignó cuando se creo dominio.tld.key). En caso contrario, significa que estableció dominio.tld.key como valor del parámetro SSLCertificateKeyFile en la configuración de Apache.

Comprobación.

Sólo basta dirigir cualquier navegador HTTP hacia https://www.dominio.tld/ 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, es necesario abrir, además del puerto 80 por TCP (HTTP), el puerto 443 por TCP (HTTPS).

Si utiliza Shorewall, edite el archivo /etc/shorewall/rules:

vim /etc/shorewall/rules

Las reglas corresponderían a algo similar a lo siguiente:

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

Al terminar de configurar las reglas para Shorewall, reinicie el muro cortafuegos, ejecutando el siguiente mandato:

service shorewall restart