1

Infraestructuras de clave pública.

Ildefonso González iggayo@eui.upm.es

2

Objetivo de la Práctica Poner en práctica algunos de los conceptos vistos en la teoría relativos a la seguridad proporcionada por las firmas digitales, que implica el uso de una infraestructura de clave pública. 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 teoría, así como haber repasado los conceptos relacionados con la firma digital. Resultado Se obtiene como resultado de la práctica una infraestructura de clave pública necesaria para establecer confianza entre los usuarios de comunicaciones digitales. Se aprenderá a realizar todo el proceso de adquisición e instalación de certificados digitales para poder activar SSL. Adicionalmente, se configurará el servidor Apache para trabajar de manera segura. Introducción El uso de la criptografía de clave pública como herramienta de identificación a través de la firma digital tiene la limitación de que este protocolo sólo identifica a una clave, no a una entidad física concreta. Este último caso sólo se puede abordar a través de una infraestructura de clave pública. 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 través de las entidades en las que se confía. Una entidad en la que se pueda confiar va a ser una Autoridad de Certificación (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 criptográfico en Internet. La herramienta que usaremos será openssl incrustada en el software del servidor Apache. Descripción y resumen de las tareas Se proponen dos escenarios de actuación. 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 contraseña 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, además, control de acceso por dirección IP. La realización práctica en el laboratorio será la siguiente: Dos máquinas, identificadas por un número i y por su dirección IP, deberán comunicar entre sí de manera segura. En cada máquina se creará la carpeta D:\EUI_Portables\xamppN\Apache\Consultas donde se depositan documentos y archivos a los cuales sólo se podrá acceder desde la máquina colateral. El control de acceso a esta

3

carpeta se realizará mediante usuario/contraseña y dirección IP. El tipo de autenticación será Basic. El nombre del dominio que se mostrará al solicitar autorización para acceder a la carpeta será Servidori. El resto de las carpetas debe ser inaccesible. Trabajos a realizar: Crear un fichero de contraseñas y dar de alta a los usuarios autorizados; configurar adecuadamente el archivo httpd.conf; comprobar el funcionamiento. Entregar la configuración obtenida. Escenario B Queriendo establecer un entorno más seguro, "LaToledana" desea montar su aplicación Web en un sitio seguro con https: los datos gozarían de mayor privacidad y, además, tendría más seguridad en cuanto a identificación de los usuarios al hacer uso de certificados digitales. Para hacer más rentable la instalación del sitio seguro quiere convertirse ella misma en Autoridad Certificadora: emitiría un certificado raíz y generaría 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, automáticamente, los accesos por http a la página segura https:://www.latoledana.com/Publico y, en ese momento, se pedirá que se muestre un certificado digital aceptable. Además, sólo se desea permitir el acceso desde determinadas direcciones IP. La realización práctica de este escenario será la siguiente: Dos máquinas, identificadas por un número i y por su dirección IP, utilizarán certificados digitales para comunicar de manera segura entre sí. En cada máquina se creará una Autoridad Certificadora, denominada testCAi que expedirá los certificados para su propio servidor y para el cliente de la máquina colateral. Trabajos a realizar: Creación del certificado raíz de la CA (entregar el certificado en formato texto). Creación del certificado de servidor (entregar el certificado, en formato texto). Creación del certificado de cliente (entregar el certificado, en formato texto). Instalación de los certificados. Implementar la redirección de D:\EUI_Portables\xamppN\Apache\Consultas\ a la página

segura D:\EUI_Portables\xamppN\Apache\Publico\. Configurar el archivo httpd.conf y comprobar el funcionamiento. Presentar la configuración

obtenida. PRESTE ATENCIÓN

1. Dado que las máquinas del laboratorio serán utilizadas por personas distintas, la configuración

de Apache, propia de cada alumno, se salvará en un medio extraible y se cargará al inicio de la práctica.

2. En el archivo httpd.conf existen muchísimas líneas comentadas. Eliminen esas líneas y

4

quédense sólo con las efectivas. 3. El valor i que permite identificar las CAs y servidores de las diferentes máquinas, estará

formado por el número aula, (3 ó 4 para el grupo de mañana, 5 ó 6 para el grupo de tarde) y del número de la máquina en el laboratorio.

5

Instalación de Apache En todas las máquinas aparecerá disponible el servidor Apache en la carpeta xamppN, de yaD:\EUI_Portables, por lo que queda obviada la tarea de instalación. Deberán verificar, sin embargo, que dentro de la carpeta Apache están los los subdirectorios Consultas, demoCA y Publico y, dentro de la carpeta demoCA, las carpetas certs y private. Caso de que no sea así deberán crearlos. Se pasaría, pues, al apartado de configuración. Configuración del servidor Básicamente, las directivas de configuración del servidor residen dentro de dos archivos: httpd.conf, archivo de configuración principal que se encuentra dentro de la carpeta conf en

el directorio de instalación de Apache. En el Anexo A se puede encontrar información relativa a la estructura y directivas de configuración de este archivo y en el Anexo B un ejemplo de configuración del mismo.

.htaccess que se puede ubicar en cualquier directorio que se encuentre mapeado dentro del servidor.

Muchas de estas directivas de configuración 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 configuración especificados dentro de httpd.conf, a no ser que la directiva AllowOverride lo impida. Creación 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.\ImplantaciónyGestiondelaSeguridaddelaInformación\xca.exe. Utilización de la interfaz XCA Según se ha indicado, la interfaz interfaz XCA está ya disponible en las máquinas del laboratorio. Si se quiere disponer de ella en otra ubicación se puede descargar de http://sourceforge.net/projects/xca/. La instalación es inmediata y no ofrece ningún problema. En la carpeta de instalación de XCA existen varios archivos de ayuda para el manejo de la herramienta. Documentación adicional de interés puede encontrarse en http://tldp.org/HOWTO/SSL‐Certificates‐HOWTO/ y en http://xca.sourceforge.net/. El manejo de la aplicación es sencillo. Empezaremos creando una base de datos, protegida con una contraseña, que contendrá los objetos de seguridad (certificados, claves, etc.) que guardaremos en \Apache\demoCA\private. Seguidamente, procederemos a la creación del certificado raíz de la CA. Este será un certificado autofirmado (el firmante y el sujeto son la misma entidad) picando en la pestaña Certificates → New Certificate. La propia aplicación dispone de plantillas (Templates) para la generación de los diversos tipos de certificados. Seleccionamos [default]CA y picamos Apply all.

6

En la pestaña 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 pestaña Extensions comprobaremos que el certificado que se

7

está creando es para una CA y verificamos el periodo de validez del certificado, modificándolo si lo creemos necesario. Con la pestaña Key Usage elegimos la aplicación de la clave de la CA: Certificate Sign y CRL Sign. Finalmente, en la pestaña 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 después: OpenSSL> x509 –in certificado.crt –text –noout OpenSSL> x509 -in certificado.crt –text –out certificado.txt Con la Autoridad Certificadora testCAi creada se generarán los certificados de servidor y cliente. Generación de certificados firmados por testCAi Creación del certificado para un servidor En el proceso se genera la pareja de claves pública/secreta del servidor, se crea la petición de certificado digital para la clave pública y después se firma esa petición por la CA.

Abrimos la base datos (si no estuviera ya abierta) y picamos la pestaña Certificate signing requests New Request. En la pantalla seleccionamos el Template [default]HTTPS_server y picamos en Apply all. En la pestaña Sujeto introducimos los datos relativos al servidor. Internal name (demoserveri) (el campo Internal name se usa sólo 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 (Dirección IP de la máquina i). Picando en el botón 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 pestaña Key usage

8

donde indicaremos la aplicación de la clave: Digital Signature, Key Encipherment, Data Encipherment, Key Agreement. En la pestaña Netscape seleccionamos SSL Server. Picamos en

Aceptar y se tendrá creada la petición de certificado (que posteriormente será firmada por la CA). Creada la petición se procede, seguidamente, a firmarla. Seleccionando esta petición, con el botón derecho del ratón seleccionamos Sign para firmar esta petición, 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. Creación del certificado para un cliente Para la creación del certificado del cliente se seguirán los mismos pasos que para la creación del certificado de servidor, usando, en este caso, el Template [default]HTTPS_client. En este caso es interesante completar, en la pestaña Sujeto, el campo emailAddress con la dirección de correo que se quiera utilizar para la realización de las prácticas. En la pestaña Key usage seleccionar Digital

9

Signature, Key Encipherment, Data Encipherment. En la pestaña Netscape seleccionar SSL Client, S/MIME. Dado que la CA de la máquina i(j) deberá firmar el certificado del cliente de la máquina j (i), tenga en cuenta las siguientes consideraciones: La máquina i creará la petición de certificado para el cliente i, que será firmada por la CA

implementada en la máquina j. En consecuencia, deberá exportarse la petición de certificado del cliente i y ponerlo a disposición de la CAj.

Esta petición de certificado deberá importarse a la base de datos donde está la clave de la CAj. La CAj firma la petición de certificado del cliente i. Se exporta el certificado creado y se pone a disposición 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 pasaríamos al apartado Instalación de Certificados en el navegador. Instalación 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 práctica, el navegador de la máquina ideberá 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 deberán poder ser accedidos por Apache, si bien no es necesaria su instalación en el navegador. La cumplimentación 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.

10

La opción 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 máquina i, la clave del servidor i (formato PEM,

extensión .pem, carpeta \Apache\demoCA\private); el certificado del servidor i (formato PEM, extensión .crt, carpeta \Apache\demoCA\certs) y el certificado de la CAi (formato PEM, extensión .crt, carpeta \Apache\demoCA\certs)

Para el navegador, deberemos exportar, desde la máquina i, el certificado del cliente i (formato PKCS#12,extensión .p12,carpeta \Apache\demoCA\private).

Lo indicado para la máquina i sería igualmente de aplicación para la máquina j. Para la incorporación al navegador se procedería como sigue: Internet Explorer Acceder a Herramientas → Opciones de Internet → Contenido → Certificados. Seleccionar la pestaña de “Entidades emisoras de certificados de raíz 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 pestaña 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 máquina i (j) debe tener instalado el certificado de la la CA implementada en la máquina j (i).

11

Configuración 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 configuración de Apache. Configuración 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. Autenticación Basic.

o Definir las directivas en el servidor para la autenticación de usuarios y el nombre de dominio que presentará en el cuadro de diálogo de acceso.

Configuración 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 líneas 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 configuración con las directivas correspondientes. Incluir la directiva para la verificación 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, automáticamente, los accesos por http a \Apache\Publico.

Reiniciar el servidor Apache con la nueva configuración

12

Anexo A: El archivo httpd.conf 1. Estructura El archivo httpd.conf es el archivo principal de configuración de Apache. En el archivo se encuentran todos los parámetros de funcionamiento de Apache. Algunos parámetros son generales para la instalación y funcionamiento de Apache. Las secciones más 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 sección <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 sección <Files> se aplicarán 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 sección se aplicarán 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 comodín, donde ? equivale a cualquier carácter individual, y * equivale a cualquier secuencia de caracteres. También pueden usarse expresiones regulares extendidas, con la ventaja de que también se puede usar el carácter ~. Por ejemplo:

<Files ~ "\.(gif|jpe?g|png)$">

equivaldría a la mayoría de los formatos gráficos 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. Parámetros globales y directivas de funcionamiento. Parámetros globales Todos estos parámetros que se establecen dentro de esta sección son globales para el funcionamiento del servidor, por lo que no admiten estar dentro de ninguna directiva. ServerRoot: especifica la ubicación del directorio raíz 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

13

También permite especificar qué direcciones IP atenderá; por defecto todas. Para atender dos direcciones IP distintas, con distintos puertos, se utilizaría: Listen 192.168.255.5:80 Listen 192.168.255.8:8080 LoadModule: Directiva que sirve para cargar módulos que incluyen distintas funcionalidades. La sintaxis es: LoadModule nombreModulo ubicacionArchivo En el archivo httpd.conf basta con descomentar la línea correspondiente al módulo que se quiera activar. Directivas de funcionamiento Esta es la sección principal de configuración del servidor; en ella se pueden podemos encontrar las siguientes opciones: ServerAdmin: especifica la dirección de correo electrónico del administrador; esta dirección aparece en los mensajes de error, para permitir al usuario notificar un error al administrador. No puede estar dentro de ninguna sección. ServerName: especifica el nombre y el puerto que el servidor utiliza para identificarse; normalmente se determina automáticamente, pero es recomendable especificarlo explícitamente para que no haya problemas al iniciar el servidor. Si el servidor no tiene un nombre de dominio, se recomienda poner su dirección IP. No puede estar dentro de ninguna sección. Sintaxis: ServerName direccionIP:Puerto DocumentRoot: la carpeta raíz que se ubica en el servidor, desde la que se servirán los documentos. Por defecto, todas las peticiones, tendrán como raíz esta carpeta, a no ser que se utilicen Alias. Al instalar el servidor, este parámetro tiene, por defecto, el valor C:/Apache/htdocs. No puede estar dentro de ninguna sección. Por ejemplo: DocumentRoot "C:/Apache/htdocs" Indexes: si se incluye esta opción, todo aquel que teclee sólo el nombre de dominio obtendrá un listado de los archivos disponibles, en lugar de la página principal. Por defecto, Apache establece la opción Indexes para el directorio htdocs, (directorio raíz 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 más 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.

14

Esta directiva se puede encontrar fuera de cualquier sección, dentro de una sección o dentro de un archivo .htaccess. AccessFileName: Cuando se procesa una petición, el servidor busca el primer archivo de configuración en cada directorio de la ruta al documento para conocer la configuración 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 sección. 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>

15

Seguridad en Apache. Autenticación, autorización y control de accesos con Apache.

Cuando un servidor Apache recibe una petición de una página Web, antes de devolver el resultado, lleva a cabo varias acciones para verificar que la petición está autorizada. Estas acciones se pueden agrupar en tres tipos: Autenticación, Autorización y Control de Accesos. Autenticación 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 contraseña, pero se pueden utilizar otros métodos para validar la identidad de una entidad, como son el uso de certificados, tarjetas, etc. Los dos tipos de autenticación disponibles en Apache son:

Autenticación básica. Es el método más simple. Cuando se solicita un recurso protegido por este tipo, Apache envía una cabecera Authentication Required notificando al cliente que se deben introducir sus credenciales, normalmente nombre de usuario y contraseña. La transferencia de las contraseñas se hará en claro, por lo que no debería usarse para la transferencia de datos sensibles a menos que se utilice mod_ssl. Este proceso se repite en cada petición aún cuando se trate del mismo cliente. El módulo implicado es mod_auth_basic.

Autenticación por resumen. Para evitar la transmisión en claro de las contraseñas se dispone del tipo Digest, de forma que lo que el cliente envía es un resumen, ejecutado con MD5, de la contraseña de usuario. El módulo implicado es mod_auth_digest.

En Apache la autenticación puede estar gestionada por distintos módulos, dependiendo de la forma de implementación: gestionando ficheros con listas de usuarios/grupos y contraseñas (cifradas), mediante base de datos, etc. Autorización 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 acción, 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 gestión de estos ficheros, los usuarios se suelen unir en grupos proporcionando los permisos al grupo. En Apache la autorización de acceso a recursos es gestionada o bien mediante la directiva <Directory> en el fichero principal de configuración, o bien mediante la configuración de la carpeta a través de archivos .htaccess. Control de acceso es el proceso por el cual se verifica que la máquina desde la que se ha hecho la petición, tiene acceso al recurso. Los controles de acceso se utilizan para limitar y controlar las máquinas 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 autenticación. En Apache, el control de acceso se puede llevar a cabo mediante las directivas contenidas en secciones <Directory> <Files> y <Location>, o a través de archivos .htaccess para controlar una carpeta especifica. Si se planifica usar archivos .htaccess para configurar las tres características citadas (autentificación, autorización y control de acceso), es necesario tener la directiva:

AllowOverride AuthConfig

16

para así permitir el uso de las distintas directivas de autenticación. Por supuesto, deberá asegurarse que se cargan los módulos mod_authn_core y mod_authz_core. Módulos y directivas relacionadas Hay tres tipos de módulos involucrados en el proceso de autenticación y autorización. Generalmente se necesitará escoger, al menos, un módulo de cada grupo. Tipos de autenticación (ver la directiva AuthType)

o mod_auth_basic o mod_auth_digest

Proveedor de autenticación

o mod_authn_anon o mod_authn_dbd o mod_authn_dbm o mod_authn_file o mod_authnz_ldap o mod_authn_socache

Autorización (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

Además de estos módulos, intervienen mod_authn_core y mod_authz_core. Estos módulos implementan directivas omunes a todos los módulos de autenticación. El módulo mod_authnz_ldap pertenece tanto al grupo de proveedor de autenticación como de autorización. El módulo mod_authz_host proporciona autorización y control de acceso basado en el nombre del host del cliente, su dirección IP u otras características de la petición del cliente, pero no es parte del sistema proveedor de autenticación. Para configurar el servidor Apache para que sea capaz de autenticar a los usuarios y verificar la autorización del mismo al recurso solicitado, es necesario realizar las siguientes acciones:

1. Crear un fichero con usuarios 2. Crear un fichero con grupos (si es necesario) 3. Definir las directivas en el archivo de configuración o mediante un archivo .htaccess o

en la sección <Directory> 1. Dependiendo del tipo de autenticación se emplea htpasswd (Basic) ó htdigest (Digest)

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

17

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 sólo se deberá poner la primera vez que se crea el archivo, de lo contrario lo borrará. Para añadir el usuario Daniel al archivo existente:

htpasswd ruta/passwords Daniel

En los archivos de usuarios de Apache, cada línea especifica un nombre de usuario separado de dos puntos, seguido del resumen de la contraseña con MD5.

2. El formato del archivo de grupos es muy simple y se puede crear manualmente En estos archivos, en cada línea se especifica un grupo escribiendo el nombre del grupo seguido de dos puntos, y a continuación 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 línea:

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, sólo el usuario root debería estar autorizado a escribir en él, mientras que solo el usuario que ejecuta el servicio Web, debería estar autorizado para leerlo.

3. La configuración del servidor para que pida contraseñas y decirle qué usuarios están

autorizados se puede hacer, o bien editando el archivo httpd.conf o creando un archivo.htaccess. En ello están 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 autenticación 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 autorización para acceder a un directorio. La cadena de caracteres que se especifique como valor de AuthName será lo que aparecerá en el cuadro de diálogo de acceso. Este nombre de dominio se muestra al cliente para que el usuario sepa qué nombre de usuario y contraseña ha de introducir. AuthName toma solamente un argumento; si el nombre de dominio contiene algún 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"

18

En este ejemplo, una vez que un cliente ha sido autenticado en el área "Top Secret", automáticamente enviará la misma contraseña para cualquier área del mismo servidor que esté marcada como perteneciente al dominio "Top Secret".

En la versión 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 sección <Directory>, <Files> y <Location> así como en los archivos .htaccess para controlar el acceso a partes concretas del servidor, basándose en el nombre del host del cliente, su dirección IP u otras características de la petición 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 idéntica 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 contraseña). El hecho de que esta directiva esté incluida en el archivo, hace que las demás no tengan efecto. Require ip A.B.C.D Pueden acceder los clientes en la dirección IP especificada.

19

Require host nombre_de_dominio El resultado de la directiva Require puede negarse con el uso de la opción not. Cuando se niega la directive Require ésta solo puede fallar o devolver un resultado neutro y, por tanto, nunca puede autorizar una petición independientemente. En el siguiente ejemplo, se autoriza a los usuarios pertenecientes a los grupos alpha y beta excepto aquellos que pertenezcan también 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 autorización 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 autorización de las cuales una debe tener éxito. La directiva <RequireNone> ··· </RequireNone> se utiliza para englobar un grupo de directivas de autorización 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 lógicas de autorización más complejas. En general, las directivas de restricciones de acceso se aplican a todos los métodos de acceso (GET, PUT, POST, etc). Es posible restringir algunos métodos dejando otros sin restringir incluyendo las directivas en una sección <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é página 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> Después se dan permisos o restringe el acceso a la carpeta de la que cuelgan todas nuestras páginas y por último se irán dando o quitando permisos a subcarpetas o a archivos concretos que no queremos que se vean. Ejemplos:

20

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 sección <Directory“C:\Apache\Consultas”> - Con AuthType Basic se estará protegiendo la carpeta Consultas con autenticación

básica, 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 línea AuthBasicProvider file en este caso sería opcional, dado que file es el

valor por defecto para esta directiva. Se necesitará esta directiva si se escoge un origen diferente para la autenticación, tal como mod_authn_dbd, mod_authn_dbm ó mod_authnz_ldap.

- Con AuthUserFile /ruta/passwords y AuthGroupFile /ruta/groups se definirá la ubicación tanto de los archivos de usuarios que se crearon con htpasswd como los archivos de grupos. Si se tiene un gran número de usuarios, puede ser más conveniente manejar los datos de los usuarios en una base de datos. El módulo 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 código, hacemos visible el directorio del que cuelgan todas nuestras páginas: <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 página que hayamos indicado en el parámetro DirectoryIndex, normalmente index.html y que debe estar guardada en C:/MiWeb (el valor del parámetro 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:

21

o Indexes, si en la carpeta no hay un fichero index.html, se mostrará en el navegador de quien quiera acceder a nuestras páginas un índice con todos los ficheros guardados en la carpeta a la que intenta acceder.

o FollowSymLinks, el servidor seguirá enlaces simbólicos a esta carpeta (alias de esa carpeta). Es decir, permitimos que este directorio, tenga otros nombres diferentes al real en nuestro ordenador, y aún así los navegadores de los equipos que intenten acceder a nuestra página, lo entenderán.

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 código, 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 líneas 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 después de la directiva de Require all denied, una directiva Require all granted con las direcciones IP desde las cuales dejamos acceder a nuestras páginas: ....... 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 algún 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 cuestión: <Directory "....."> <FILES “prohibido.htm”> Require all denied </FILES> AllowOverride FileInfo

22

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>

23

Anexo B: httpd.conf (Ejemplo) # ThreadsPerChild 250 MaxRequestsPerChild 0 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

24

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 #

25

<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

26

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>

27

Anexo E: Muestra en formato texto del certificado raíz 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 Not Before: Jan 19 12:24:11 2009 GMT Not After : Jan 19 12:24:11 2010 GMT 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:

Issuer y Subject

coinciden

28

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

Sección [ v3_ca ]

29

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

30

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