EL Rincón de Tux

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.

Este documento requiere la lectura y comprensión previa de cualquiera de los siguientes temas:

Acerca de LDAP en modo SSL/TLS.

El inicio de la operación StartTLS en un servidor LDAP, establece la comunicación TLS (Transport Layer Security, o Seguridad para Nivel de Transporte) a través del mismo puerto 389 por TCP. Provee confidencialidad en el transporte de datos e protección de la integridad de datos. Durante la negociación, el servidor envía su certificado con estructura X.509 para verificar su identidad. Opcionalmente puede establecerse la comunicación. La conexión a través del puerto 389 y 636 difiere en lo siguiente:

1. Al realizar la conexión por puerto 636, tanto el cliente como el servidor establecen TLS antes de que se transfiera cualquier otro dato, sin utilizar la operación StatTLS.
2. La conexión a través de puerto 636 debe cerrarse al terminar TLS.

URL: http://en.wikipedia.org/wiki/LDAP

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 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/

Procedimientos.

Generando clave y certificado.

cd /etc/openldap/cacerts

La creación de la llave y certificado para OpenLDAP requiere utilizar una clave con algoritmo RSA de 1024 octetos y estructura x509. En el ejemplo a continuación, se establece una validez por 730 días (dos años) para el certificado creado.

openssl req -x509 -nodes -newkey rsa:1024
-days 730 -out slapd.crt -keyout slapd.key

Lo anterior solicitará se ingresen varios datos:

La salida devuelta sería similar a la siguiente:

Generating a 1024 bit RSA private key
................++++++
.++++++
writing new private key to 'dovecot.key'
-----
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) []:
midominio.org
Email Address []:webmaster@midominio.org

El certificado solo será válido cuando el servidor LDAP sea invocado con el nombre definido en el campo Common Name. Es decir, solo podrá utilizarlo cuando se defina midominio.org como servidor LDAP con soporte SSL/TLS. No funcionará si se invoca al servidor como, por mencionar un ejemplo, directorio.midominio.org.

Es indispensable que todos los ficheros de claves y certificados tengan permisos de acceso de solo lectura para el usuario ldap:

chown ldap.ldap /etc/openldap/cacerts/slapd.*
chmod 400 /etc/openldap/cacerts/slapd.*

Parámetros de /etc/openldap/slapd.conf.

Se deben descomentar los parámetros TLSCACertificateFile, TLSCertificateFile y TLSCertificateKeyFile establecendo las rutas hacia el certificado y clave. Opcionalmente se puede descomentar la directiva referral para indicar el URI (Uniform Resource Identifier o Identificador Uniforme de Recursos) del servicio de directorio superior como ldaps en lugar de ldap.

TLSCACertificateFile /etc/openldap/cacerts/slapd.crt
TLSCertificateFile /etc/openldap/cacerts/slapd.crt
TLSCertificateKeyFile /etc/openldap/cacerts/slapd.key
referral	ldaps://midominio.org

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

service ldap restart

Comprobación.

Configure cualquier cliente LDAP para utilizar SSL en el puerto 636. Tras aceptar el certificado, en el caso de que éste no haya sido firmado por un RA (Registration Authority o Autoridad de Registro), servidor LDAP deberá permitir completar la conexión y realizar cualquier tipo de consulta y/o manipulación de registros.

Configuración de GNOME Evolution.

Se debe establecer el mismo nombre del servidor utilizado para crear el certificado, y conexión por SSL.

Configuración LDAP, GNOME Evolution.

Configuración de Mozilla Thunderbird.

Se debe establecer el mismo nombre del servidor utilizado para crear el certificado, y conexión por SSL.

Configuración LDAP, Mozilla Thunderbird.

Configuración LDAP Browser.

Se debe establecer el mismo nombre del servidor utilizado para crear el certificado, y conexión por SSL.

Configuración LDAP Browser.

Configuración LDAP Administration Tool.

Se debe establecer el mismo nombre del servidor utilizado para crear el certificado, y conexión por SSL.

Configuración LDAP Administration Tool.

Modificaciones necesarias en el muro cortafuegos.

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

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	389,636
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

Última Edición lunes, abril 09 2007 @ 02:42 CDT