Infraestructuras de clave pblica.

Ildefonso Gonzlez
iggayo@eui.upm.es

Objetivo de la Prctica
Poner en prctica algunos de los conceptos vistos en la teora relativos a la seguridad proporcionada
por las firmas digitales, que implica el uso de una infraestructura de clave pblica. Se instalar un
certificado digital para poder activar el protocolo SSL en un servidor.

Requisitos
Ser necesario el revisar y tener frescos todos los conocimientos adquiridos en la teora, as como
haber repasado los conceptos relacionados con la firma digital.

Resultado
Se obtiene como resultado de la prctica una infraestructura de clave pblica necesaria para
establecer confianza entre los usuarios de comunicaciones digitales. Se aprender a realizar todo el
proceso de adquisicin e instalacin de certificados digitales para poder activar SSL.
Adicionalmente, se configurar el servidor Apache para trabajar de manera segura.

Introduccin
El uso de la criptografa de clave pblica como herramienta de identificacin a travs de la firma
digital tiene la limitacin de que este protocolo slo identifica a una clave, no a una entidad fsica
concreta. Este ltimo caso slo se puede abordar a travs de una infraestructura de clave pblica. El
primer principio de funcionamiento de esta infraestructura es la confianza. Una persona que vaya a
utilizar las comunicaciones digitales debe establecer una confianza inicial en alguien para
posteriormente trasladar esa confianza a travs de las entidades en las que se confa. Una entidad en
la que se pueda confiar va a ser una Autoridad de Certificacin (CA) y su labor ser la de certificar
la identidad de sus suscriptores por medio de certificados digitales expedidos (firmados) por la CA.
El protocolo que vamos a utilizar es SSL (Secure Socket Layer), pensado para el uso criptogrfico
en Internet. La herramienta que usaremos ser openssl incrustada en el software del servidor
Apache.

Descripcin y resumen de las tareas

Se proponen dos escenarios de actuacin.

Escenario A
Imaginemos la empresa La Toledana que ofrece a sus empleados y clientes el sitio
http://www.latoledana.com/Consultas, donde mediante un nombre de usuario y contrasea es
posible, para los empleados, consultar saldos, rdenes, estados de cuenta, etc., y, para los clientes,
observar el estado de sus pedidos, su saldo, pagos, historial de compras, etc. Establece, adems,
control de acceso por direccin IP.
La realizacin prctica en el laboratorio ser la siguiente: Dos mquinas, identificadas por un
nmero i y por su direccin IP, debern comunicar entre s de manera segura. En cada mquina se
crear la carpeta D:\EUI_Portables\xamppN\Apache\Consultas donde se depositan documentos
y archivos a los cuales slo se podr acceder desde la mquina colateral. El control de acceso a esta
2

carpeta se realizar mediante usuario/contrasea y direccin IP. El tipo de autenticacin ser

Basic. El nombre del dominio que se mostrar al solicitar autorizacin para acceder a la carpeta
ser Servidori. El resto de las carpetas debe ser inaccesible.
Trabajos a realizar:
Crear un fichero de contraseas y dar de alta a los usuarios autorizados; configurar adecuadamente
el archivo httpd.conf; comprobar el funcionamiento. Entregar la configuracin obtenida.

Escenario B
Queriendo establecer un entorno ms seguro, "La Toledana" desea montar su aplicacin Web en un
sitio seguro con https: los datos gozaran de mayor privacidad y, adems, tendra ms seguridad en
cuanto a identificacin de los usuarios al hacer uso de certificados digitales. Para hacer ms rentable
la instalacin del sitio seguro quiere convertirse ella misma en Autoridad Certificadora: emitira un
certificado raz y generara certificados para los usuarios.
Los usuarios son perezosos y siguen haciendo uso del acceso por http en vez de https, por lo que
se decide implementar las modificaciones necesarias para redireccionar, automticamente, los
accesos por http a la pgina segura https:://www.latoledana.com/Publico y, en ese momento, se
pedir que se muestre un certificado digital aceptable. Adems, slo se desea permitir el acceso
desde determinadas direcciones IP.
La realizacin prctica de este escenario ser la siguiente: Dos mquinas, identificadas por un
nmero i y por su direccin IP, utilizarn certificados digitales para comunicar de manera segura
entre s. En cada mquina se crear una Autoridad Certificadora, denominada testCAi que expedir
los certificados para su propio servidor y para el cliente de la mquina colateral.
Trabajos a realizar:

Creacin del certificado raz de la CA (entregar el certificado en formato texto).

Creacin del certificado de servidor (entregar el certificado, en formato texto).

Creacin del certificado de cliente (entregar el certificado, en formato texto).

Instalacin de los certificados.

Implementar la redireccin de D:\EUI_Portables\xamppN\Apache\Consultas\ a la pgina

segura D:\ EUI_Portables\xamppN\Apache\Publico\.

Configurar el archivo httpd.conf y comprobar el funcionamiento. Presentar la configuracin

obtenida.

PRESTE ATENCIN
1.

2.

Dado que las mquinas del laboratorio sern utilizadas por personas distintas, la configuracin
de Apache, propia de cada alumno, se salvar en un medio extraible y se cargar al inicio de la
prctica.
En el archivo httpd.conf existen muchsimas lneas comentadas. Eliminen esas lneas y
3

3.

qudense slo con las efectivas.

El valor i que permite identificar las CAs y servidores de las diferentes mquinas, estar
formado por el nmero aula, (3 4 para el grupo de maana, 5 6 para el grupo de tarde) y del
nmero de la mquina en el laboratorio.

Instalacin de Apache
En todas las mquinas aparecer ya disponible el servidor Apache en la carpeta xamppN, de
D:\EUI_Portables, por lo que queda obviada la tarea de instalacin. Debern verificar, sin embargo,
que dentro de la carpeta Apache estn los los subdirectorios Consultas, demoCA y Publico y,
dentro de la carpeta demoCA, las carpetas certs y private. Caso de que no sea as debern crearlos.
Se pasara, pues, al apartado de configuracin.

Configuracin del servidor

Bsicamente, las directivas de configuracin del servidor residen dentro de dos archivos:
httpd.conf, archivo de configuracin principal que se encuentra dentro de la carpeta conf en
el directorio de instalacin de Apache. En el Anexo A se puede encontrar informacin relativa a
la estructura y directivas de configuracin de este archivo y en el Anexo B un ejemplo de
configuracin del mismo.
.htaccess que se puede ubicar en cualquier directorio que se encuentre mapeado dentro del
servidor.
Muchas de estas directivas de configuracin pueden ir tanto dentro de httpd.conf como dentro
de .htaccess. Los valores de las directivas que se encuentran dentro de .htaccess prevalecen
frente a los valores de configuracin especificados dentro de httpd.conf, a no ser que la
directiva AllowOverride lo impida.

Creacin de la Autoridad Certificadora

Se proceder a crear la Autoridad Cerificadora (CA), que expedir los certificados digitales. Para
ello se har uso de la interfaz XCA. Aparecer disponible en el escritorio,
ETSISI\A.T.C.\Implantacin y Gestion de la Seguridad de la Informacin\xca.exe.

Utilizacin de la interfaz XCA

Segn se ha indicado, la interfaz interfaz XCA est ya disponible en las mquinas del laboratorio. Si
se
quiere
disponer
de
ella
en
otra
ubicacin
se
puede
descargar
de
http://sourceforge.net/projects/xca/. La instalacin es inmediata y no ofrece ningn problema.
En la carpeta de instalacin de XCA existen varios archivos de ayuda para el manejo de la
herramienta.
Documentacin
adicional
de
inters
puede
encontrarse
en
http://tldp.org/HOWTO/SSLCertificatesHOWTO/ y en http://xca.sourceforge.net/.
El manejo de la aplicacin es sencillo. Empezaremos creando una base de datos, protegida con una
contrasea, que contendr los objetos de seguridad (certificados, claves, etc.) que guardaremos en
\Apache\demoCA\private.
Seguidamente, procederemos a la creacin del certificado raz de la CA. Este ser un certificado
autofirmado (el firmante y el sujeto son la misma entidad) picando en la pestaa Certificates
New Certificate. La propia aplicacin dispone de plantillas (Templates) para la generacin de los
diversos tipos de certificados. Seleccionamos [default]CA y picamos Apply all.

En la pestaa Sujeto se introducen los datos relativos a la CAi: Internal name (demoCAi);
countryName (ES); stateOrProvinceName (CAM); localityName (Madrid); organizationName

(ATC); organizationalUnitName (Puestoi); commonName (testCAi). No es necesario incluir el

campo emailAddress. Picando en Generate a new key se genera la clave para la CA. Se usar para la

CA una clave RSA de 2048 bits. En la pestaa Extensions comprobaremos que el certificado que se
6

est creando es para una CA y verificamos el periodo de validez del certificado, modificndolo si lo
creemos necesario. Con la pestaa Key Usage elegimos la aplicacin de la clave de la CA:
Certificate Sign y CRL Sign. Finalmente, en la pestaa Netscape elegimos los valores SSL CA,
S/MIME CA, Object Signing CA. Picando en Aceptar tendremos creado el certificado.
Una vez creado el certificado, se puede mostrar en pantalla el contenido del certificado o enviarlo a
un fichero de texto. Para ello se abre una ventana de comandos; ir al directorio bin de Apache,
ejecutar openssl y despus:
OpenSSL> x509 in certificado.crt text noout
OpenSSL> x509 -in certificado.crt text out certificado.txt

Con la Autoridad Certificadora testCAi creada se generarn los certificados de servidor y cliente.

Generacin de certificados firmados por testCAi

Creacin del certificado para un servidor
En el proceso se genera la pareja de claves pblica/secreta del servidor, se crea la peticin de
certificado digital para la clave pblica y despus se firma esa peticin por la CA.

Abrimos la base datos (si no estuviera ya abierta) y picamos la pestaa Certificate signing requests
New Request. En la pantalla seleccionamos el Template [default]HTTPS_server y picamos en
Apply all.
En la pestaa Sujeto introducimos los datos relativos al servidor. Internal name (demoserveri) (el
campo Internal name se usa slo internamente y no aparece en el certificado resultante; sirve a
efectos de identificar el certificado en la base de datos); countryName (ES); stateOrProvinceName
(CAM); localityName (Madrid); organizationName (LABATC); organizationalUnitName (Puestoi);
commonName (Direccin IP de la mquina i). Picando en el botn Generate a new key se crea la
pareja de claves del servidor; elegimos una clave RSA de 1024 bits.
En la pantalla Extensions comprobamos que el tipo sea End Entity y que en el certificado aparezca
el identificador de clave del servidor (Subject Key Identifier). Pasamos a la pestaa Key usage

donde indicaremos la aplicacin de la clave: Digital Signature, Key Encipherment, Data

Encipherment, Key Agreement. En la pestaa Netscape seleccionamos SSL Server. Picamos en

Aceptar y se tendr creada la peticin de certificado (que posteriormente ser firmada por la CA).
Creada la peticin se procede, seguidamente, a firmarla. Seleccionando esta peticin, con el botn
derecho del ratn seleccionamos Sign para firmar esta peticin, es decir, crear el certificado
propiamente dicho. Teniendo activadas las casillas Sign this Certificate signing request, Copy
extensions from the request y Use this certificate for signing, (aparecer el nombre de la CA que
firma) el certificado se crear simplemente con picar en Aceptar.
En la pantalla principal de XCA veremos el certificado de la CA y, colgando de l, el certificado del
servidor.
Creacin del certificado para un cliente
Para la creacin del certificado del cliente se seguirn los mismos pasos que para la creacin del
certificado de servidor, usando, en este caso, el Template [default]HTTPS_client. En este caso es
interesante completar, en la pestaa Sujeto, el campo emailAddress con la direccin de correo que
se quiera utilizar para la realizacin de las prcticas. En la pestaa Key usage seleccionar Digital
8

Signature, Key Encipherment, Data Encipherment. En la pestaa Netscape seleccionar SSL Client,
S/MIME.
Dado que la CA de la mquina i (j) deber firmar el certificado del cliente de la mquina j (i), tenga
en cuenta las siguientes consideraciones:
La mquina i crear la peticin de certificado para el cliente i, que ser firmada por la CA
implementada en la mquina j. En consecuencia, deber exportarse la peticin de certificado del
cliente i y ponerlo a disposicin de la CAj.
Esta peticin de certificado deber importarse a la base de datos donde est la clave de la CAj.
La CAj firma la peticin de certificado del cliente i.
Se exporta el certificado creado y se pone a disposicin del cliente i, con lo cual ste dispone de
un certificado digital expedido por la CAj.
El cliente i importa el certificado a su base de datos.
Lo indicado para el cliente i es aplicable, igualmente, al cliente j. Una vez creados los certificados
pasaramos al apartado Instalacin de Certificados en el navegador.

Instalacin de certificados en el navegador

Una vez creados los certificados, es necesario crear los formatos adecuados de los mismos para que
se puedan instalar en el navegador y puedan ser verificados. De acuerdo con la estructura definida
para la prctica, el navegador de la mquina i deber tener instalado:

El certificado digital de la CAj.

El certificado del cliente i (recuerde que ste es un certificado expedido por la CAj).

Para que el navegador pueda manejar el certificado de cliente, ste deber estar en formato pkcs12.
Los certificados del servidor i y de la CAi debern poder ser accedidos por Apache, si bien no es
necesaria su instalacin en el navegador. La cumplimentacin de las directivas de Apache
SSLCertificateFile, SSLCertificateKeyFile y SSLCACertificateFile permite que
el servidor pueda manejar el certificado del servidor, la clave del servidor y el certificado de la CA.
9

La opcin Export de la interfaz XCA, permite exportar cualquier certificado o clave presente en la
base de datos, a los formatos PEM, DER, pkcs12, etc. (hay que tener en cuenta que, tanto Apache
como los navegadores, no pueden acceder a la base de datos donde se encuentran las claves y
certificados y, en consecuencia, deben ser exportados).
En resumen, las operaciones a realizar son las siguientes:
Para Apache necesitaremos exportar, desde la mquina i, la clave del servidor i (formato PEM,
extensin .pem, carpeta \Apache\demoCA\private); el certificado del servidor i (formato
PEM, extensin .crt, carpeta \Apache\demoCA\certs) y el certificado de la CAi (formato
PEM, extensin .crt, carpeta \Apache\demoCA\certs)
Para el navegador, deberemos exportar, desde la mquina i, el certificado del cliente i (formato
PKCS #12, extensin .p12, carpeta \Apache\demoCA\private).
Lo indicado para la mquina i sera igualmente de aplicacin para la mquina j.
Para la incorporacin al navegador se procedera como sigue:
Internet Explorer
Acceder a Herramientas Opciones de Internet Contenido Certificados. Seleccionar la
pestaa de Entidades emisoras de certificados de raz de confianza (si es un certificado de CA)
Personal (si es un certificado de cliente), y pulsar sobre Importar. Seleccionar el archivo que
contiene el cetificado e importarlo.
Mozilla Firefox
Acceder a Herramientas Opciones Avanzado Certificados Ver certificados. Seleccionar
la pestaa de Autoridades (si es un certificado de CA) Sus certificados (si es un certificado de
cliente), y pulsar sobre Importar. Seleccionar el archivo que contiene el cetificado e importarlo.
Por ltimo, es necesario recordar que el navegador de la mquina i (j) debe tener instalado el
certificado de la la CA implementada en la mquina j (i).

10

Configuracin del Servidor Apache

Se deber configurar del servidor Apache para trabajar en los escenarios que se han definido. En los
anexos A y B se puede encontrar referencias para la configuracin de Apache.
Configuracin escenario A.
Cerrar todo tipo de acceso.
Permitir el acceso al usuario user (y) desde direcciones IP. Para ello:
o

Crear el fichero de usuarios autorizados. Autenticacin Basic.

Definir las directivas en el servidor para la autenticacin de usuarios y el nombre de dominio

que presentar en el cuadro de dilogo de acceso.

Configuracin escenario B.
Configurar Apache para utilizar los certificados
Cargar el modulo correspondiente al paquete SSL.
Indicar la escucha por el puerto seguro 443 (puerto seguro para comunicaciones SSL).
Comentar lneas siguientes:
# Secure (SSL/TLS) connections
Include conf/extra/httpd-ssl.conf
#Virtual hosts
Include conf/extra/httpd-vhosts.conf

Declarar el virtualhost en el archivo de configuracin con las directivas correspondientes.

Incluir la directiva para la verificacin del certificado de cliente en el virtualhost que se defina.
Copiar los archivos de claves y certificados, definidos al declarar el host virtual en los directorios
indicados.
Implementar las modificaciones necesarias para redireccionar, automticamente, los accesos por
http a \Apache\Publico.
Reiniciar el servidor Apache con la nueva configuracin

11

Anexo A: El archivo httpd.conf

1. Estructura
El archivo httpd.conf es el archivo principal de configuracin de Apache. En el archivo se
encuentran todos los parmetros de funcionamiento de Apache. Algunos parmetros son generales
para la instalacin y funcionamiento de Apache. Las secciones ms importantes son:

<Directory> y <Files>, junto con sus contrapartes, <DirectoryMatch> y <FilesMatch> que

aceptan expresiones regulares, aplican sus directivas a reas del sistema de archivos.
Las directivas incluidas en una seccin <Directory> se aplican al directorio del sistema de
archivos especificado y a sus subdirectorios. El mismo resultado puede obtenerse usando
.htaccess.Debe cerrarse con </Directory>.
En cambio, las directivas incluidas en una seccin <Files> se aplicarn a cualquier archivo
cuyo nombre se especifique, sin tener en cuenta en qu directorio se encuentra. Debe cerrarse
con <Files>. Las directivas usadas en esta seccin se aplicarn a cualquier objeto con un
nombre base (ltimo componente del nombre de archivo) que coincida con el nombre de
archivo especificado.
El argumento filename puede incluir un nombre de archivo, o una cadena de caracteres
comodn, donde ? equivale a cualquier carcter individual, y * equivale a cualquier secuencia
de caracteres. Tambin pueden usarse expresiones regulares extendidas, con la ventaja de que
tambin se puede usar el carcter ~. Por ejemplo:
<Files ~ "\.(gif|jpe?g|png)$">

equivaldra a la mayora de los formatos grficos de Internet.

A diferencia de las secciones <Directory> y <Location>, las secciones <Files> pueden usarse
dentro de los archivos .htaccess. Esto permite controlar el acceso archivo a archivo.

2. Parmetros globales y directivas de funcionamiento.

Parmetros globales
Todos estos parmetros que se establecen dentro de esta seccin son globales para el
funcionamiento del servidor, por lo que no admiten estar dentro de ninguna directiva.
ServerRoot: especifica la ubicacin del directorio raz donde se encuentra instalado Apache, a
partir del cual se crea el rbol de directorios. Por ejemplo:
ServerRoot "C:/Apache"

Listen: esta directiva permite especificar qu puerto se utilizar para atender las peticiones. Por

defecto se utiliza el puerto 80 (www) y el puerto 443, correspondiente a SSL

Listen 80
Listen 443

12

Tambin permite especificar qu direcciones IP atender; por defecto todas. Para atender dos
direcciones IP distintas, con distintos puertos, se utilizara:
Listen 192.168.255.5:80
Listen 192.168.255.8:8080

LoadModule: Directiva que sirve para cargar mdulos que incluyen distintas funcionalidades. La

sintaxis es:
LoadModule nombreModulo ubicacionArchivo

En el archivo httpd.conf basta con descomentar la lnea correspondiente al mdulo que se quiera
activar.
Directivas de funcionamiento
Esta es la seccin principal de configuracin del servidor; en ella se pueden podemos encontrar las
siguientes opciones:
ServerAdmin: especifica la direccin de correo electrnico del administrador; esta direccin

aparece en los mensajes de error, para permitir al usuario notificar un error al administrador. No
puede estar dentro de ninguna seccin.
ServerName: especifica el nombre y el puerto que el servidor utiliza para identificarse;

normalmente se determina automticamente, pero es recomendable especificarlo explcitamente

para que no haya problemas al iniciar el servidor. Si el servidor no tiene un nombre de dominio, se
recomienda poner su direccin IP. No puede estar dentro de ninguna seccin.
Sintaxis: ServerName direccionIP:Puerto

DocumentRoot: la carpeta raz que se ubica en el servidor, desde la que se servirn los

documentos. Por defecto, todas las peticiones, tendrn como raz esta carpeta, a no ser que se
utilicen Alias. Al instalar el servidor, este parmetro tiene, por defecto, el valor
C:/Apache/htdocs. No puede estar dentro de ninguna seccin. Por ejemplo:
DocumentRoot "C:/Apache/htdocs"

Indexes: si se incluye esta opcin, todo aquel que teclee slo el nombre de dominio obtendr un

listado de los archivos disponibles, en lugar de la pgina principal. Por defecto, Apache establece la
opcin Indexes para el directorio htdocs, (directorio raz del servidor).
DirectoryIndex: especifica el archivo por defecto que se buscar y mostrar en cada directorio,
caso de que no se especifique ninguno. Por defecto es index.html. En esta directiva se pueden

especificar ms de un archivo.
DirectoryIndex archivo1 archivo 2 archivo 3

El orden con el que se especifica el nombre de archivo determinar la prioridad a la hora de decidir
qu archivo es el que se muestra.

13

Esta directiva se puede encontrar fuera de cualquier seccin, dentro de una seccin o dentro de un
archivo .htaccess.
AccessFileName: Cuando se procesa una peticin, el servidor busca el primer archivo de
configuracin en cada directorio de la ruta al documento para conocer la configuracin del mismo.
Este archivo permite configurar el comportamiento de cada uno de los directorios individualmente. Por
ejemplo, con:
AccessFileName .acl

Antes de presentar el documento /usr/local/web/index.html, el servidor leer las directivas en:

/.acl /usr/.acl
/usr/local/.acl
/usr/local/web/.acl.
No puede estar dentro de ninguna seccin. El nombre de archivo que se especifica por defecto es
.htaccess.
El efecto de las directivas indicadas en estos archivos queda condicionado por la directiva
AllowOverride, que indica qu directivas, de las indicadas, prevalecen. Se puede deshabilitar el
efecto de AccessFileName con la directiva:
<Directory />
AllowOverride None
</Directory>

14

Seguridad en Apache.
Autenticacin, autorizacin y control de accesos con Apache.
Cuando un servidor Apache recibe una peticin de una pgina Web, antes de devolver el resultado,
lleva a cabo varias acciones para verificar que la peticin est autorizada. Estas acciones se pueden
agrupar en tres tipos: Autenticacin, Autorizacin y Control de Accesos.
Autenticacin es el proceso por el cual se verifica la identidad de una persona. De una forma
simple, este proceso se puede llevar a cabo mediante un nombre de usuario y una contrasea, pero
se pueden utilizar otros mtodos para validar la identidad de una entidad, como son el uso de
certificados, tarjetas, etc. Los dos tipos de autenticacin disponibles en Apache son:
Autenticacin bsica. Es el mtodo ms simple. Cuando se solicita un recurso protegido por
este tipo, Apache enva una cabecera Authentication Required notificando al cliente que
se deben introducir sus credenciales, normalmente nombre de usuario y contrasea. La
transferencia de las contraseas se har en claro, por lo que no debera usarse para la
transferencia de datos sensibles a menos que se utilice mod_ssl. Este proceso se repite en cada
peticin an cuando se trate del mismo cliente. El mdulo implicado es mod_auth_basic.
Autenticacin por resumen. Para evitar la transmisin en claro de las contraseas se dispone
del tipo Digest, de forma que lo que el cliente enva es un resumen, ejecutado con MD5, de la
contrasea de usuario. El mdulo implicado es mod_auth_digest.
En Apache la autenticacin puede estar gestionada por distintos mdulos, dependiendo de la forma
de implementacin: gestionando ficheros con listas de usuarios/grupos y contraseas (cifradas),
mediante base de datos, etc.
Autorizacin es el proceso por el cual se verifica que un usuario con una identidad conocida, tiene
acceso al recurso solicitado. Para llevar a cabo esta accin, se suelen utilizar listas de permisos en
las cuales se enumeran cada una de las acciones que puede realizar un usuario, o las que no puede
hacer. Normalmente, para simplificar la gestin de estos ficheros, los usuarios se suelen unir en
grupos proporcionando los permisos al grupo.
En Apache la autorizacin de acceso a recursos es gestionada o bien mediante la directiva
<Directory> en el fichero principal de configuracin, o bien mediante la configuracin de la
carpeta a travs de archivos .htaccess.
Control de acceso es el proceso por el cual se verifica que la mquina desde la que se ha hecho la
peticin, tiene acceso al recurso. Los controles de acceso se utilizan para limitar y controlar las
mquinas que tienen acceso a un recurso independientemente del usuario que accede, ya que estos
controles se llevan a cabo antes de que se realice el proceso de autenticacin.
En Apache, el control de acceso se puede llevar a cabo mediante las directivas contenidas en
secciones <Directory> <Files> y <Location>, o a travs de archivos .htaccess para
controlar una carpeta especifica. Si se planifica usar archivos .htaccess para configurar las tres
caractersticas citadas (autentificacin, autorizacin y control de acceso), es necesario tener la
directiva:
AllowOverride AuthConfig

15

para as permitir el uso de las distintas directivas de autenticacin.

Por

supuesto,

deber
mod_authz_core.

asegurarse

que

se

cargan

los

mdulos

mod_authn_core

Mdulos y directivas relacionadas

Hay tres tipos de mdulos involucrados en el proceso de autenticacin y autorizacin.
Generalmente se necesitar escoger, al menos, un mdulo de cada grupo.

Tipos de autenticacin (ver la directiva AuthType)

o mod_auth_basic
o mod_auth_digest

Proveedor de autenticacin
o mod_authn_anon
o mod_authn_dbd
o mod_authn_dbm
o mod_authn_file
o mod_authnz_ldap
o mod_authn_socache

Autorizacin (ver la directiva Require)

o mod_authnz_ldap
o mod_authz_dbd
o mod_authn_dbm
o mod_authz_groupfile
o mod_authn_host
o mod_authz_owner
o mod_authz_user

Adems de estos mdulos, intervienen mod_authn_core y mod_authz_core. Estos mdulos

implementan directivas omunes a todos los mdulos de autenticacin.
El mdulo mod_authnz_ldap pertenece tanto al grupo de proveedor de autenticacin como de
autorizacin. El mdulo mod_authz_host proporciona autorizacin y control de acceso basado
en el nombre del host del cliente, su direccin IP u otras caractersticas de la peticin del cliente,
pero no es parte del sistema proveedor de autenticacin.
Para configurar el servidor Apache para que sea capaz de autenticar a los usuarios y verificar la
autorizacin del mismo al recurso solicitado, es necesario realizar las siguientes acciones:
1.
2.
3.

1.

Crear un fichero con usuarios

Crear un fichero con grupos (si es necesario)
Definir las directivas en el archivo de configuracin o mediante un archivo .htaccess o
en la seccin <Directory>

Dependiendo del tipo de autenticacin se emplea htpasswd (Basic) htdigest (Digest)

que vienen con Apache, normalmente, en el directorio bin. La sintaxis en cada caso es la
siguiente:

16

htpasswd -c ruta/passwords Carlos

htdigest -c ruta/digest dominio Carlos

Con el flag -c se crea un archivo nuevo (passwords en un caso, digest en el otro), por lo
que slo se deber poner la primera vez que se crea el archivo, de lo contrario lo borrar. Para
aadir el usuario Daniel al archivo existente:
htpasswd ruta/passwords Daniel

En los archivos de usuarios de Apache, cada lnea especifica un nombre de usuario separado de
dos puntos, seguido del resumen de la contrasea con MD5.
2.

El formato del archivo de grupos es muy simple y se puede crear manualmente En estos
archivos, en cada lnea se especifica un grupo escribiendo el nombre del grupo seguido de dos
puntos, y a continuacin separado por espacios, los nombres de los usuarios que pertenecen al
grupo.
Por ejemplo, en el archivo groups se define un grupo usuariosAutenticados al que
pertenecen Carlos, Daniel y Tom. Para ello se escribe la siguiente lnea:
usuariosAutenticados: Carlos Daniel Tom

Es recomendable que tanto los archivos de usuarios como los de grupos, se encuentren
almacenados fuera de los directorios publicados, para que de esta forma nadie pueda
descargarlos. Asimismo, slo el usuario root debera estar autorizado a escribir en l, mientras
que solo el usuario que ejecuta el servicio Web, debera estar autorizado para leerlo.
3.

La configuracin del servidor para que pida contraseas y decirle qu usuarios estn
autorizados se puede hacer, o bien editando el archivo httpd.conf o creando un
archivo.htaccess. En ello estn involucradas las siguientes directivas:
AuthUserFile: siver para especificar la ruta donde se almacenar el archivo de usuarios.
AuthGroupFile: sirve para especificar la ruta donde se almacenar el archivo de grupos.
AuthType: selecciona el tipo de autenticacin de que se utilizar para autenticar a un usuario.
Puede variar por directorio. Los valores posibles son Basic y Digest.
AuthName: especifica el nombre del dominio que se muestra al solicitar autorizacin para
acceder a un directorio. La cadena de caracteres que se especifique como valor de AuthName

ser lo que aparecer en el cuadro de dilogo de acceso. Este nombre de dominio se muestra al
cliente para que el usuario sepa qu nombre de usuario y contrasea ha de introducir.
AuthName toma solamente un argumento; si el nombre de dominio contiene algn espacio,
debe escribirse entre comillas. Para que funcione correctamente, esta directiva debe usarse
junto con las directivas AuthType y Require, y con directivas como AuthUserFile y
AuthGroupFile. Por ejemplo:
AuthName "Top Secret"

17

En este ejemplo, una vez que un cliente ha sido autenticado en el rea "Top Secret",
automticamente enviar la misma contrasea para cualquier rea del mismo servidor que est
marcada como perteneciente al dominio "Top Secret".
En la versin XAMPP 1.8.3 (que incluye Apache 2.4.4) se utiliza ya la directiva Require. Esta
directiva puede referenciarse, dentro del fichero httpd.conf, en una seccin <Directory>, <Files>
y <Location> as como en los archivos .htaccess para controlar el acceso a partes concretas del
servidor, basndose en el nombre del host del cliente, su direccin IP u otras caractersticas de la
peticin del cliente.
<Directory />
AllowOverride none
Require all denied
</Directory>

Por eso, cuando el usuario quiere permitir el acceso a un directorio (por ejemplo en un alias) debe
utilizarse esa misma directiva. Por ejemplo
<Directory />
AllowOverride none
Require all granted
</Directory>
Require all

Proporciona una funcionalidad idntica a la de las anteriores directivas Allow from all y Deny
from all. Puede tomar dos argumentos granted o denied. Por ejemplo:
Require all granted

Se permite al acceso incondiconalmente.

Require all denied

Se deniega incondicioalmente el acceso.

Require user usuario

Se permite accede al recurso solamente al usuario indicado.

Require group grupo

Solamente pueden accede al recurso los usuarios pertenecientes al grupo indicado.

Require valid-user

Permite el acceso a todos los usuarios identificados (han introducido correctamente su contrasea).
El hecho de que esta directiva est incluida en el archivo, hace que las dems no tengan efecto.
Require ip A.B.C.D

Pueden acceder los clientes en la direccin IP especificada.

18

Require host nombre_de_dominio

El resultado de la directiva Require puede negarse con el uso de la opcin not. Cuando se niega
la directive Require sta solo puede fallar o devolver un resultado neutro y, por tanto, nunca puede
autorizar una peticin independientemente.
En el siguiente ejemplo, se autoriza a los usuarios pertenecientes a los grupos alpha y beta
excepto aquellos que pertenezcan tambin al grupo reject.
<Directory /www/docs>
<RequireAll>
Require group alpha beta
Require not group reject
</RequireAll>
</Directory>

La directiva <RequireAll> </RequireAll> se utiliza para englobar un grupo de

directivas de autorizacin de las cuales ninguna debe fallar y, al menos, una debe tener xito.
La directiva <RequireAny> </RequireAny> se utiliza para englobar un grupo de
directivas de autorizacin de las cuales una debe tener xito.
La directiva <RequireNone> </RequireNone> se utiliza para englobar un grupo de
directivas de autorizacin de las cuales ninguna debe tener xito.
Estas directivas (<RequireAll>, <RequireAny> y <RequireNone>) pueden combinarse unas
con otras y con la directiva <Require> para obtener lgicas de autorizacin ms complejas.
En general, las directivas de restricciones de acceso se aplican a todos los mtodos de acceso (GET,
PUT, POST, etc). Es posible restringir algunos mtodos dejando otros sin restringir incluyendo las
directivas en una seccin <Limit>.
Para el control de acceso, primero, se configura lo que debe hacer el servidor "por defecto", es decir
para cualquier URL con la que se acceda a l y no sabe qu pgina mostrar. Hay que tener en cuenta
que, por defecto, el acceso de Apache a <Directory /> es Require all granted. Esto significa
que Apache servir cualquier archivo que se corresponda con una URL. Debe modificarse este
comportamiento con un bloque del siguiente tipo:
<Directory />
AllowOverride None

Require all denied

</Directory>

Despus se dan permisos o restringe el acceso a la carpeta de la que cuelgan todas nuestras pginas
y por ltimo se irn dando o quitando permisos a subcarpetas o a archivos concretos que no
queremos que se vean.

Ejemplos:

19

Por ejemplo, si se quiere proteger el directorio C:\Apache\Consultas se pueden usar las

siguientes directivas:
AuthType Basic
AuthName "Mi Servidor"
AuthBasicProvider file
AuthUserFile /ruta/passwords
AuthGroupFile /ruta/groups
Require group usuariosAutenticados/Require user Carlos

stas pueden ir en el archivo C:\Apache\Consultas\.htacces o en la seccin <Directory

C:\Apache\Consultas>
- Con AuthType Basic se estar protegiendo la carpeta Consultas con autenticacin
bsica, es decir que la clave que el usuario introduzca, se transmitir en claro por la Web.
- Con AuthName "Mi Servidor" se asociar esa carpeta con el dominio "Mi
Servidor", nombre con el que lo identificar el cliente.
- La lnea AuthBasicProvider file en este caso sera opcional, dado que file es el
valor por defecto para esta directiva. Se necesitar esta directiva si se escoge un origen
diferente para la autenticacin, tal como mod_authn_dbd, mod_authn_dbm
mod_authnz_ldap.
- Con AuthUserFile /ruta/passwords y AuthGroupFile /ruta/groups se definir
la ubicacin tanto de los archivos de usuarios que se crearon con htpasswd como los

archivos de grupos. Si se tiene un gran nmero de usuarios, puede ser ms conveniente

manejar los datos de los usuarios en una base de datos. El mdulo mod_authn_dbm
proporciona la directiva AuthDBMUserFile. Estos archivos pueden ser manejados con el
programa dbmmanage.
- Con Require group usuariosAutenticados/Require user Carlos se autorizar
el acceso al contenido de esta carpeta a todos los usuarios que forman parte del grupo
usuariosAutenticados o solamente al usuario Carlos.
Con el siguiente cdigo, hacemos visible el directorio del que cuelgan todas nuestras pginas:
<Directory "C:/MiWeb">
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>

Si ahora ponemos en el navegador http://dirIP_del_ServidorWeb nos mostrar la pgina que

hayamos indicado en el parmetro DirectoryIndex, normalmente index.html y que debe estar
guardada en C:/MiWeb (el valor del parmetro DocumentRoot).
Las propiedades que se pueden definir para cada carpeta son las siguientes:
Options, son opciones del servidor disponibles para la carpeta a la que se refiere. Valores

habituales:

20

o Indexes, si en la carpeta no hay un fichero index.html, se mostrar en el navegador de

quien quiera acceder a nuestras pginas un ndice con todos los ficheros guardados en la
carpeta a la que intenta acceder.
o FollowSymLinks, el servidor seguir enlaces simblicos a esta carpeta (alias de esa
carpeta). Es decir, permitimos que este directorio, tenga otros nombres diferentes al real en
nuestro ordenador, y an as los navegadores de los equipos que intenten acceder a nuestra
pgina, lo entendern.
AllowOverride, permite decidir qu directivas de las incluidas en los ficheros .htaccess se
van a utilizar. No usamos estos ficheros y le damos el valor None.
Con el siguiente cdigo, se permite el acceso a una carpeta denominada contenidos publicos
situada dentro de la carpeta C:\MiWeb:
<Directory "C:/MiWeb/contenidos publicos">
Options Indexes FollowSymLinks
AllowOverride None

Require all granted

</Directory>

Con las siguientes lneas se prohibe el acceso a una carpeta llamada contenidos personales
situada dentro de la carpeta C:\MiWeb:
<Directory "C:/MiWeb/contenidos personales">
Options Indexes FollowSymLinks
AllowOverride None

Require all denied

</Directory>

Si se quiere prohibir el acceso excepto a ciertas direcciones IP, se deber poner despus de la
directiva de Require all denied, una directiva Require all granted con las direcciones
IP desde las cuales dejamos acceder a nuestras pginas:
.......

Require all denied

Require ip 192.168.1.25
</Directory>

Si estamos dentro de un dominio DNS, podremos dar permiso a todo un dominio o a algn equipo
dentro de este dominio:
.......

Require all denied

Require host micentro.es
</Directory>

Si se quiere prohibir el acceso a un archivo (p. ej: prohibido.htm) en una carpeta

determinada, se deber poner un grupo <FILES..>.... </FILES> entre las etiquetas que determinan
las directivas para el directorio en cuestin:
<Directory ".....">
<FILES prohibido.htm>
Require all denied
</FILES>
AllowOverride FileInfo

21

Require all granted

</Directory>

Si se quiere prohibir el acceso a un fichero (p. ej: prohibido.htm) en todo nuestro espacio
Web, se deber poner un grupo <FILES..>.... </FILES> pero fuera de las etiquetas de directorio:
<FILES prohibido.htm>

Require all denied

</FILES>

Si lo que se quiere es prohibir el acceso a un tipo de ficheros (p. ej: todos los .htm), pondremos
el grupo <FILES..>.... </FILES> de la siguiente manera:
<FILES *.htm>

Require all denied

</FILES>

22

Anexo B: httpd.conf (Ejemplo)

#
ThreadsPerChild 250
MaxRequestsPerChild

ServerRoot "C:/Apache"
Listen 80
Listen 443
LoadModule access_compat_module modules/mod_access_compat.so
LoadModule actions_module modules/mod_actions.so
LoadModule alias_module modules/mod_alias.so
LoadModule asis_module modules/mod_asis.so
LoadModule allowmethods_module modules/mod_allowmethods.so
LoadModule auth_basic_module modules/mod_auth_basic.so
#LoadModule auth_digest_module modules/mod_auth_digest.so
#LoadModule auth_form_module modules/mod_auth_form.so
#LoadModule authn_anon_module modules/mod_authn_anon.so
LoadModule authn_core_module modules/mod_authn_core.so
#LoadModule authn_dbd_module modules/mod_authn_dbd.so
LoadModule authn_dbm_module modules/mod_authn_dbm.so
LoadModule authn_file_module modules/mod_authn_file.so
#LoadModule authn_socache_module modules/mod_authn_socache.so
#LoadModule authnz_fcgi_module modules/mod_authnz_fcgi.so
#LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
LoadModule authz_core_module modules/mod_authz_core.so
#LoadModule authz_dbd_module modules/mod_authz_dbd.so
LoadModule authz_dbm_module modules/mod_authz_dbm.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_host_module modules/mod_authz_host.so
#LoadModule authz_owner_module modules/mod_authz_owner.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule autoindex_module modules/mod_autoindex.so
#LoadModule buffer_module modules/mod_buffer.so
#LoadModule cache_module modules/mod_cache.so
#LoadModule cache_disk_module modules/mod_cache_disk.so
#LoadModule cache_socache_module modules/mod_cache_socache.so
#LoadModule cern_meta_module modules/mod_cern_meta.so
LoadModule cgi_module modules/mod_cgi.so
#LoadModule charset_lite_module modules/mod_charset_lite.so
#LoadModule data_module modules/mod_data.so
#LoadModule dav_module modules/mod_dav.so
#LoadModule dav_fs_module modules/mod_dav_fs.so
LoadModule dav_lock_module modules/mod_dav_lock.so
#LoadModule dbd_module modules/mod_dbd.so
#LoadModule deflate_module modules/mod_deflate.so
LoadModule dir_module modules/mod_dir.so
#LoadModule dumpio_module modules/mod_dumpio.so
LoadModule env_module modules/mod_env.so
#LoadModule expires_module modules/mod_expires.so
#LoadModule ext_filter_module modules/mod_ext_filter.so
#LoadModule file_cache_module modules/mod_file_cache.so
#LoadModule filter_module modules/mod_filter.so
#LoadModule headers_module modules/mod_headers.so
#LoadModule heartbeat_module modules/mod_heartbeat.so
#LoadModule heartmonitor_module modules/mod_heartmonitor.so
#LoadModule ident_module modules/mod_ident.so
LoadModule imagemap_module modules/mod_imagemap.so

23

LoadModule include_module modules/mod_include.so

#LoadModule info_module modules/mod_info.so
LoadModule isapi_module modules/mod_isapi.so
#LoadModule lbmethod_bybusyness_module modules/mod_lbmethod_bybusyness.so
#LoadModule lbmethod_byrequests_module modules/mod_lbmethod_byrequests.so
#LoadModule lbmethod_bytraffic_module modules/mod_lbmethod_bytraffic.so
#LoadModule lbmethod_heartbeat_module modules/mod_lbmethod_heartbeat.so
#LoadModule ldap_module modules/mod_ldap.so
#LoadModule logio_module modules/mod_logio.so
LoadModule log_config_module modules/mod_log_config.so
#LoadModule log_debug_module modules/mod_log_debug.so
#LoadModule log_forensic_module modules/mod_log_forensic.so
#LoadModule lua_module modules/mod_lua.so
LoadModule cache_disk_module modules/mod_cache_disk.so
#LoadModule macro_module modules/mod_macro.so
LoadModule mime_module modules/mod_mime.so
#LoadModule mime_magic_module modules/mod_mime_magic.so
LoadModule negotiation_module modules/mod_negotiation.so
#LoadModule proxy_module modules/mod_proxy.so
#LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
#LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
#LoadModule proxy_connect_module modules/mod_proxy_connect.so
#LoadModule proxy_express_module modules/mod_proxy_express.so
#LoadModule proxy_fcgi_module modules/mod_proxy_fcgi.so
#LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
#LoadModule proxy_html_module modules/mod_proxy_html.so
#LoadModule proxy_http_module modules/mod_proxy_http.so
#LoadModule proxy_scgi_module modules/mod_proxy_scgi.so
#LoadModule proxy_wstunnel_module modules/mod_proxy_wstunnel.so
#LoadModule ratelimit_module modules/mod_ratelimit.so
#LoadModule reflector_module modules/mod_reflector.so
#LoadModule remoteip_module modules/mod_remoteip.so
#LoadModule request_module modules/mod_request.so
#LoadModule reqtimeout_module modules/mod_reqtimeout.so
#LoadModule rewrite_module modules/mod_rewrite.so
#LoadModule sed_module modules/mod_sed.so
#LoadModule session_module modules/mod_session.so
#LoadModule session_cookie_module modules/mod_session_cookie.so
#LoadModule session_crypto_module modules/mod_session_crypto.so
#LoadModule session_dbd_module modules/mod_session_dbd.so
LoadModule setenvif_module modules/mod_setenvif.so
#LoadModule slotmem_plain_module modules/mod_slotmem_plain.so
#LoadModule slotmem_shm_module modules/mod_slotmem_shm.so
#LoadModule socache_dbm_module modules/mod_socache_dbm.so
#LoadModule socache_memcache_module modules/mod_socache_memcache.so
LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
#LoadModule speling_module modules/mod_speling.so
LoadModule ssl_module modules/mod_ssl.so
#LoadModule status_module modules/mod_status.so
#LoadModule substitute_module modules/mod_substitute.so
#LoadModule unique_id_module modules/mod_unique_id.so
LoadModule userdir_module modules/mod_userdir.so
#LoadModule usertrack_module modules/mod_usertrack.so
#LoadModule version_module modules/mod_version.so
LoadModule vhost_alias_module modules/mod_vhost_alias.so
#LoadModule watchdog_module modules/mod_watchdog.so
#LoadModule xml2enc_module modules/mod_xml2enc.so
#
ServerAdmin admin@eui.upm.es
#
ServerName ggg.eui.upm.es
#

24

<Directory />
AllowOverride None
Require all denied
</Directory>
DocumentRoot "C:/Apache/Publico"
<Directory "C:/Apache/Publico">
Options Indexes FollowSymLinks
AllowOverride None
AuthName "Mi servidor"
AuthType Basic
AuthBasicProvider file
AuthUserFile c:/Apache/passwords
<RequireAll>
Require user Pepe
Require ip 80.34.199.52
Require ip 138.100.154.160
</RequireAll>
</Directory>
#
<IfModule dir_module>
DirectoryIndex index.html
</IfModule>
#
<FilesMatch "^\.ht">
Require all denied
</FilesMatch>
#
ErrorLog logs/error.log
#
LogLevel warn
<IfModule log_config_module>
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\""combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
<IfModule logio_module>
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O"
combinedio
</IfModule>
CustomLog logs/access.log common
</IfModule>
<IfModule alias_module>
ScriptAlias /cgi-bin/ "C:/Apache/cgi-bin/"
ScriptAlias /php/ "C:/php"
</IfModule>
<Directory "C:/Apache/cgi-bin">
AllowOverride None
Options None
Require all granted
</Directory>
DefaultType text/plain
<IfModule mime_module>
TypesConfig conf/mime.types

25

AddType application/x-compress .Z
AddType application/x-gzip .gz .tgz
Addtype application/x-httpd-php .php
Action application/x-httpd-php "/php/php-cgi-exe
</IfModule>
# Secure (SSL/TLS) connections
#Include conf/extra/httpd-ssl.conf
#
<IfModule ssl_module>
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
SSLMutex default
SSLSessionCache none
ErrorLog logs/SSL.log
LogLevel info
</IfModule>
NameVirtualHost ggg.eui.upm.es:443
<VirtualHost ggg.eui.upm.es:443>
ServerAdmin sdmin@eui.upm.es
DocumentRoot "C:/Apache/Publico"
ServerName gayo.eui.upm.es
ScriptAlias /cgi-bin/ "C:/Apache/cgi-bin/"
SSLEngine On
SSLCertificateFile C:/Apache/demoCA/certs/certservidor.crt
SSLCertificateKeyFile C:/Apache/demoCA/servidor.pem
SSLCACertificateFile C:/Apache/demoCA/cacert.crt
SSLVerifyClient require
<Directory "C:/Apache/Publico">
Options Indexes
AllowOverride None
Require ip 80.34.199.52
Require ip 138.100.154.160
</Directory>
</VirtualHost>

26

Anexo E: Muestra en formato texto del certificado raz cacert.pem

Certificate:
Data:
Version: 3 (0x2)
Serial Number:
a0:6b:57:f5:11:ed:0a:97
Signature Algorithm: dsaWithSHA1
Issuer: C=ES, ST=CAM, L=Madrid, O=EUI, OU=ATC, CN=testCA
Validity
Issuer y
Not Before: Jan 19 12:24:11 2009 GMT
Subject
Not After : Jan 19 12:24:11 2010 GMT
coinciden
Subject: C=ES, ST=CAM, L=Madrid, O=EUI, OU=ATC, CN=testCA
Subject Public Key Info:
Public Key Algorithm: dsaEncryption
DSA Public Key:
pub:
00:b9:25:dc:d5:c0:88:19:30:3f:0d:5b:2f:ef:25:
72:00:e3:cb:2e:33:53:e3:93:2f:a9:82:62:ed:bd:
05:33:d3:ce:4a:e1:e7:eb:a1:8b:16:31:90:f7:01:
a5:89:4a:25:9a:eb:c4:50:f4:f1:ab:5c:5b:46:9b:
a6:f8:5f:2d:7c:3e:dc:4e:94:24:14:0b:5c:ac:db:
56:dd:c3:54:cb:de:49:b0:f3:0d:b5:a1:59:10:d8:
c6:5a:4b:06:ef:fd:15:39:cc:f7:c3:b1:b7:c8:52:
f0:9a:70:49:8b:27:5f:01:81:17:de:0c:58:cf:8f:
85:81:6c:ab:6d:c7:ec:d6:5c:ea:b6:1a:e2:2e:c4:
04:ce:65:72:2e:0e:35:3b:c6:f1:60:43:9f:ba:2e:
cc:76:2a:e0:76:a9:95:cd:77:e0:5a:4b:c9:e0:40:
02:2f:ed:a9:dc:0e:4d:c7:bd:7a:17:77:61:f9:f3:
6a:19:ca:d7:d4:e3:04:51:da:51:d7:1c:eb:59:31:
13:39:4f:34:14:31:22:57:5e:ff:14:98:7e:79:47:
2e:37:9d:fa:25:1d:a1:f6:50:db:ec:ba:7f:8c:0c:
74:1e:b4:cc:49:0b:98:c4:51:40:9f:ba:d5:38:aa:
4c:52:ff:af:3b:7f:60:33:b7:32:d9:55:a8:64:fe:
35:d3
P:
00:c2:03:b7:62:7a:7f:df:b2:d0:f7:0f:3f:e8:f4:
76:87:21:a0:e8:68:05:1a:27:de:4b:5a:03:81:96:
66:ab:2e:85:7d:c1:1f:be:17:63:12:d5:28:f9:27:
3e:e6:30:29:94:8f:ae:15:d5:d9:b6:99:9d:18:1c:
b7:be:98:55:57:77:de:7c:23:9a:c1:43:23:c2:0c:
db:32:a6:87:cc:a0:c5:54:54:e2:a0:18:71:b8:c6:
3b:46:40:bc:86:c3:aa:fb:c0:b4:db:58:09:f8:ef:
47:6f:55:89:2f:a4:d0:77:3b:57:4d:b7:f9:14:b1:
03:54:a8:3b:76:55:52:54:7b:76:af:90:ed:63:60:
c8:3b:04:b0:e3:8b:e5:d4:68:86:2f:5b:26:3a:9f:
3a:6a:07:05:f4:8f:ca:1a:80:cb:14:7b:8e:e0:12:
8d:fb:6b:97:16:b2:7c:ad:64:08:a6:61:35:c5:80:
2f:18:1f:89:80:0d:cb:2b:b3:ec:76:d7:61:48:31:
b2:ce:e9:08:68:c0:0d:bd:39:af:60:ae:f8:85:35:
32:5d:8c:9a:6b:c5:1a:f4:79:6d:dd:63:67:2b:9e:
ba:dc:77:41:98:32:c2:c3:8c:e3:3c:d2:91:7a:7f:
8e:c3:2d:58:28:45:87:29:5a:d0:4f:7d:a6:03:61:
43:6b
Q:
00:f3:7b:bb:ae:04:39:3e:87:17:f1:02:0a:04:de:
d7:b1:69:d3:5a:45
G:
00:95:9e:01:11:d1:3d:7d:eb:7b:4b:43:1f:06:3b:
16:ee:19:ad:fc:c5:94:15:0f:58:2e:08:5b:58:78:

27

80:f7:72:dd:78:d7:cf:2f:44:b0:b9:02:2d:36:20:
a2:66:67:2f:ee:ff:c1:d3:67:b2:6c:b4:e3:fc:98:
15:77:5b:77:0f:b1:3d:f1:7b:dd:59:77:e0:ed:ee:
fc:d2:23:94:d7:56:f5:2a:a5:ed:a2:f7:cc:e7:9c:
02:5a:a0:8d:69:a4:4e:0e:3a:6a:dc:1a:fe:31:81:
fa:78:3b:30:ce:49:ab:2f:6c:db:27:e3:dd:ae:10:
1e:5b:d9:79:01:e8:e5:94:01:3c:11:44:6a:45:91:
f2:c3:e2:96:11:05:5d:9b:49:54:a6:a0:c2:7a:3c:
7a:aa:64:61:44:75:a2:9d:00:98:d5:59:91:c5:67:
f0:b4:05:23:aa:44:a7:52:94:0f:a7:63:17:a6:fc:
3b:ef:0c:92:7b:f1:36:23:cd:54:29:b4:8c:e9:18:
35:6c:2e:a3:cb:2e:87:3d:d9:1f:b4:0d:82:71:fa:
41:f5:1b:fa:10:e1:02:7e:7f:58:05:f8:f4:83:d0:
a6:df:7f:bf:e6:66:33:1a:8d:57:08:6f:73:66:81:
5e:8f:7d:96:4a:2a:19:52:e0:c3:be:f7:8e:85:ac:
c6:df
X509v3 extensions:
X509v3 Basic Constraints: critical
Seccin [ v3_ca ]
CA:TRUE
X509v3 Subject Key Identifier:
9F:56:61:06:C9:DA:7A:50:8B:59:06:C8:F8:12:F7:22:F2:30:31:97
X509v3 Authority Key Identifier:
keyid:9F:56:61:06:C9:DA:7A:50:8B:59:06:C8:F8:12:F7:22:F2:30:31:97
DirName:/C=ES/ST=CAM/L=Madrid/O=EUI/OU=ATC/CN=testCA
serial:A0:6B:57:F5:11:ED:0A:97
X509v3 Key Usage:
Certificate Sign, CRL Sign
Signature Algorithm: dsaWithSHA1
30:2e:02:15:00:ca:dd:c8:83:95:aa:fc:b5:cb:77:e0:9c:48:
6e:07:8b:59:bc:4e:a9:02:15:00:94:76:f6:c8:07:5e:6d:0c:
49:79:88:39:90:98:42:88:3c:22:91:d7
-----BEGIN CERTIFICATE----MIIFRDCCBQKgAwIBAgIJAKBrV/UR7QqXMAkGByqGSM44BAMwWTELMAkGA1UEBhMC
RVMxDDAKBgNVBAgTA0NBTTEPMA0GA1UEBxMGTWFkcmlkMQwwCgYDVQQKEwNFVUkx
DDAKBgNVBAsTA0FUQzEPMA0GA1UEAxMGdGVzdENBMB4XDTA5MDExOTEyMjQxMVoX
DTEwMDExOTEyMjQxMVowWTELMAkGA1UEBhMCRVMxDDAKBgNVBAgTA0NBTTEPMA0G
A1UEBxMGTWFkcmlkMQwwCgYDVQQKEwNFVUkxDDAKBgNVBAsTA0FUQzEPMA0GA1UE
AxMGdGVzdENBMIIDPDCCAi4GByqGSM44BAEwggIhAoIBAQDCA7dien/fstD3Dz/o
9HaHIaDoaAUaJ95LWgOBlmarLoV9wR++F2MS1Sj5Jz7mMCmUj64V1dm2mZ0YHLe+
mFVXd958I5rBQyPCDNsypofMoMVUVOKgGHG4xjtGQLyGw6r7wLTbWAn470dvVYkv
pNB3O1dNt/kUsQNUqDt2VVJUe3avkO1jYMg7BLDji+XUaIYvWyY6nzpqBwX0j8oa
gMsUe47gEo37a5cWsnytZAimYTXFgC8YH4mADcsrs+x212FIMbLO6QhowA29Oa9g
rviFNTJdjJprxRr0eW3dY2crnrrcd0GYMsLDjOM80pF6f47DLVgoRYcpWtBPfaYD
YUNrAhUA83u7rgQ5PocX8QIKBN7XsWnTWkUCggEBAJWeARHRPX3re0tDHwY7Fu4Z
rfzFlBUPWC4IW1h4gPdy3XjXzy9EsLkCLTYgomZnL+7/wdNnsmy04/yYFXdbdw+x
PfF73Vl34O3u/NIjlNdW9Sql7aL3zOecAlqgjWmkTg46atwa/jGB+ng7MM5Jqy9s
2yfj3a4QHlvZeQHo5ZQBPBFEakWR8sPilhEFXZtJVKagwno8eqpkYUR1op0AmNVZ
kcVn8LQFI6pEp1KUD6djF6b8O+8MknvxNiPNVCm0jOkYNWwuo8suhz3ZH7QNgnH6
QfUb+hDhAn5/WAX49IPQpt9/v+ZmMxqNVwhvc2aBXo99lkoqGVLgw773joWsxt8D
ggEGAAKCAQEAuSXc1cCIGTA/DVsv7yVyAOPLLjNT45MvqYJi7b0FM9POSuHn66GL
FjGQ9wGliUolmuvEUPTxq1xbRpum+F8tfD7cTpQkFAtcrNtW3cNUy95JsPMNtaFZ
ENjGWksG7/0VOcz3w7G3yFLwmnBJiydfAYEX3gxYz4+FgWyrbcfs1lzqthriLsQE
zmVyLg41O8bxYEOfui7MdirgdqmVzXfgWkvJ4EACL+2p3A5Nx716F3dh+fNqGcrX
1OMEUdpR1xzrWTETOU80FDEiV17/FJh+eUcuN536JR2h9lDb7Lp/jAx0HrTMSQuY
xFFAn7rVOKpMUv+vO39gM7cy2VWoZP4106OBzjCByzAPBgNVHRMBAf8EBTADAQH/
MB0GA1UdDgQWBBSfVmEGydp6UItZBsj4Evci8jAxlzCBiwYDVR0jBIGDMIGAgBSf
VmEGydp6UItZBsj4Evci8jAxl6FdpFswWTELMAkGA1UEBhMCRVMxDDAKBgNVBAgT
A0NBTTEPMA0GA1UEBxMGTWFkcmlkMQwwCgYDVQQKEwNFVUkxDDAKBgNVBAsTA0FU
QzEPMA0GA1UEAxMGdGVzdENBggkAoGtX9RHtCpcwCwYDVR0PBAQDAgEGMAkGByqG
SM44BAMDMQAwLgIVAMrdyIOVqvy1y3fgnEhuB4tZvE6pAhUAlHb2yAdebQxJeYg5
kJhCiDwikdc=
-----END CERTIFICATE-----

28

Anexo F: Muestra en formato texto del certificado certservidor.pem

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 6 (0x6)
Signature Algorithm: dsaWithSHA1
Issuer: C=ES, ST=CAM, L=Madrid, O=EUI, OU=ATC, CN=testCA
Validity
Not Before: Jan 19 12:25:31 2009 GMT
Not After : Jan 19 12:25:31 2010 GMT
Subject: C=ES, ST=CAM, L=Madrid, O=EUI, OU=ATC, CN=gayo.eui.upm.es
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:c6:0b:9f:ef:d7:1a:13:e0:96:78:e8:36:3d:6b:
61:f6:be:c2:fc:e4:c2:68:b6:7d:2b:3c:ea:14:f6:
86:4d:49:6b:c6:76:9e:c3:72:75:bc:85:23:9c:77:
4f:b2:2c:a2:b4:aa:fa:9a:64:b1:25:80:46:17:c2:
f5:d7:d8:28:66:2f:92:f7:d6:f9:93:13:90:39:23:
7a:3b:98:21:84:ee:62:64:ec:97:51:b1:45:ff:41:
6b:90:9c:b8:53:5c:e2:ac:85:e4:dd:07:62:d6:a5:
18:0f:6f:35:e3:5e:9f:5d:7b:69:22:fa:52:38:ca:
f9:89:38:04:ec:8d:9e:88:e1
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Authority Key Identifier:
keyid:9F:56:61:06:C9:DA:7A:50:8B:59:06:C8:F8:12:F7:22:F2:30:31:97
DirName:/C=ES/ST=CAM/L=Madrid/O=EUI/OU=ATC/CN=testCA
serial:A0:6B:57:F5:11:ED:0A:97
X509v3 Subject Key Identifier:
28:16:44:FA:4D:19:5D:0C:95:C4:98:19:53:CB:F4:7C:68:73:B5:5F
X509v3 Key Usage:
Digital Signature, Key Encipherment, Data Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
Signature Algorithm: dsaWithSHA1
30:2d:02:15:00:d8:ca:40:c7:42:1f:01:12:d0:d8:1a:73:5e:
57:75:ae:5a:d7:24:70:02:14:73:ef:8d:2b:e5:11:99:3f:8a:
31:c6:f5:f9:9d:97:61:68:bf:02:25
-----BEGIN CERTIFICATE----MIICuDCCAnegAwIBAgIBBjAJBgcqhkjOOAQDMFkxCzAJBgNVBAYTAkVTMQwwCgYD
VQQIEwNDQU0xDzANBgNVBAcTBk1hZHJpZDEMMAoGA1UEChMDRVVJMQwwCgYDVQQL
EwNBVEMxDzANBgNVBAMTBnRlc3RDQTAeFw0wOTAxMTkxMjI1MzFaFw0xMDAxMTkx
MjI1MzFaMGIxCzAJBgNVBAYTAkVTMQwwCgYDVQQIEwNDQU0xDzANBgNVBAcTBk1h
ZHJpZDEMMAoGA1UEChMDRVVJMQwwCgYDVQQLEwNBVEMxGDAWBgNVBAMTD2dheW8u
ZXVpLnVwbS5lczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxguf79caE+CW
eOg2PWth9r7C/OTCaLZ9KzzqFPaGTUlrxnaew3J1vIUjnHdPsiyitKr6mmSxJYBG
F8L119goZi+S99b5kxOQOSN6O5ghhO5iZOyXUbFF/0FrkJy4U1zirIXk3Qdi1qUY
D281416fXXtpIvpSOMr5iTgE7I2eiOECAwEAAaOB4DCB3TAMBgNVHRMBAf8EAjAA
MIGLBgNVHSMEgYMwgYCAFJ9WYQbJ2npQi1kGyPgS9yLyMDGXoV2kWzBZMQswCQYD
VQQGEwJFUzEMMAoGA1UECBMDQ0FNMQ8wDQYDVQQHEwZNYWRyaWQxDDAKBgNVBAoT
A0VVSTEMMAoGA1UECxMDQVRDMQ8wDQYDVQQDEwZ0ZXN0Q0GCCQCga1f1Ee0KlzAd
BgNVHQ4EFgQUKBZE+k0ZXQyVxJgZU8v0fGhztV8wCwYDVR0PBAQDAgSwMBMGA1Ud
JQQMMAoGCCsGAQUFBwMBMAkGByqGSM44BAMDMAAwLQIVANjKQMdCHwES0Ngac15X
da5a1yRwAhRz740r5RGZP4oxxvX5nZdhaL8CJQ==
-----END CERTIFICATE-----

29

Anexo H: Muestra en formato texto del certificado certcliente.pem

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 7 (0x7)
Signature Algorithm: dsaWithSHA1
Issuer: C=ES, ST=CAM, L=Madrid, O=EUI, OU=ATC, CN=testCA
Validity
Not Before: Jan 21 11:47:27 2009 GMT
Not After : Jan 21 11:47:27 2010 GMT
Subject: C=ES, ST=CAM, L=Madrid, O=ATC, OU=Laboratorio,
CN=138.100.154.160
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:f7:fd:3b:92:19:c6:50:9b:c9:2f:2d:37:3b:2f:
e4:40:9b:47:46:15:e3:46:e1:a5:2f:45:3e:19:c2:
a6:f5:d8:0a:6b:7d:37:c9:90:82:67:7d:e5:78:4f:
b3:75:71:8d:ce:3b:56:cf:95:d1:32:16:33:07:50:
ec:53:f9:63:e4:b9:73:68:8e:ae:e3:18:de:25:e6:
17:84:f1:18:d0:f2:2e:28:cf:df:f0:3d:b4:48:7d:
ae:41:60:80:88:60:fb:e7:ab:e8:3f:0e:c3:a8:4a:
d2:a6:2c:8c:48:e0:13:c0:c3:ec:c9:50:02:9f:74:
24:a7:44:6b:89:82:03:1e:d5
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Authority Key Identifier:
keyid:9F:56:61:06:C9:DA:7A:50:8B:59:06:C8:F8:12:F7:22:F2:30:31:97
DirName:/C=ES/ST=CAM/L=Madrid/O=EUI/OU=ATC/CN=testCA
serial:A0:6B:57:F5:11:ED:0A:97
X509v3 Subject Key Identifier:
58:A4:99:CA:82:14:45:C2:9D:C5:4E:F9:D3:60:DA:15:C2:F2:40:6F
X509v3 Key Usage:
Digital Signature, Key Encipherment, Data Encipherment
Signature Algorithm: dsaWithSHA1
30:2d:02:14:1f:ee:77:ac:ea:32:60:20:8c:e9:b4:ea:6e:0e:
77:8a:d9:68:32:5d:02:15:00:e4:cb:03:9e:d8:f2:d8:8b:e0:
f1:e3:72:a4:8c:cf:05:69:b3:31:89
-----BEGIN CERTIFICATE----MIICvTCCAnygAwIBAgIBBzAJBgcqhkjOOAQDMFkxCzAJBgNVBAYTAkVTMQwwCgYD
VQQIEwNDQU0xDzANBgNVBAcTBk1hZHJpZDEMMAoGA1UEChMDRVVJMQwwCgYDVQQL
EwNBVEMxDzANBgNVBAMTBnRlc3RDQTAeFw0wOTAxMjExMTQ3MjdaFw0xMDAxMjEx
MTQ3MjdaMGoxCzAJBgNVBAYTAkVTMQwwCgYDVQQIEwNDQU0xDzANBgNVBAcTBk1h
ZHJpZDEMMAoGA1UEChMDQVRDMRQwEgYDVQQLEwtMYWJvcmF0b3JpbzEYMBYGA1UE
AxMPMTM4LjEwMC4xNTQuMTYwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQD3
/TuSGcZQm8kvLTc7L+RAm0dGFeNG4aUvRT4Zwqb12AprfTfJkIJnfeV4T7N1cY3O
O1bPldEyFjMHUOxT+WPkuXNojq7jGN4l5heE8RjQ8i4oz9/wPbRIfa5BYICIYPvn
q+g/DsOoStKmLIxI4BPAw+zJUAKfdCSnRGuJggMe1QIDAQABo4HdMIHaMAkGA1Ud
EwQCMAAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwgYsGA1UdIwSBgzCBgIAUn1ZhBsna
elCLWQbI+BL3IvIwMZehXaRbMFkxCzAJBgNVBAYTAkVTMQwwCgYDVQQIEwNDQU0x
DzANBgNVBAcTBk1hZHJpZDEMMAoGA1UEChMDRVVJMQwwCgYDVQQLEwNBVEMxDzAN
BgNVBAMTBnRlc3RDQYIJAKBrV/UR7QqXMB0GA1UdDgQWBBRYpJnKghRFwp3FTvnT
YNoVwvJAbzALBgNVHQ8EBAMCBLAwCQYHKoZIzjgEAwMwADAtAhQf7nes6jJgIIzp
tOpuDneK2WgyXQIVAOTLA57Y8tiL4PHjcqSMzwVpszGJ
-----END CERTIFICATE-----

30