Plataforma OpenSSL. Pág. 1 29/10/2015. Luis Mengual (C)

Transcripción

1 Pág. 1 29/10/2015

2 OpenSSL es un entorno integrado que permite la creación y gestión de certificados digitales. OpenSSL dispone de la infraestructura necesaria para crear una Autoridad de Certificación, firmar certificados de usuario, revocar certificados etc. OpenSSL es además un paquete de herramientas de administración y librerías de seguridad para la gestión de certificados y la implementación de mecanismos de seguridad. OpenSSL proporciona un entorno mediante el cual es posible mediante línea de comandos crear certificados, firmas digitales, cifrado/descrifrado información, mensajes S/mime etc.además proporciona librerías para implemementar aplicaciones de seguridad en entorno C/C++ en sistemas operativos windows/linux Esta librería criptográfica surge a partir del proyecto SSLeay, que fue iniciado por Eric A. Young y Tim J.Houston, y como propuesta inicial pretendía ofrecer el protocolo SSL para cualquier aplicación de seguridad. El proyecto OpenSSL fue iniciado en 1995, y actualmente es la librería criptográfica más usada. Algunas de las razones que la hacen tan popular son: Es distribuida, usando una licencia de código libre. Esto permite a los usuarios realizar cambios y optimizaciones constantes en los elementos criptográficos que la componen. Es posible integrarla en cualquier aplicación comercial sin necesidad de abonar tasas, permitiendo ofrecer soporte SSL criptográfico, comparable con casi cualquier librería comercial. Puede ser ejecutada en numerosas plataformas, permitiendo la exportación de las aplicaciones que la utilizan a cualquier sistema operativo. Pág. 2 29/10/2015

3 La herramienta openssl, que se invoca mediante la línea de mandatos, proporciona acceso a un gran conjunto de funciones criptográficas correspondientes a la librería criptográfica crypto. Algunas de las operaciones que se pueden realizar mediante dicha librería son: Creación y gestión de certificados digitales X.509, solicitudes de certificados digitales (CSR) y listas de revocación de certificados (CRL). Creación y gestión de claves privadas y claves públicas Operaciones relacionadas con la criptografía de clave pública Cálculo de resúmenes de mensajes mediante funciones hash. Firma digital Cifrado y descifrado con un amplio conjunto de algoritmos Api para el desarrollo de aplicaciones SSL/TLS cliente-servidor Manejo de s S/MIME cifrados y firmados Generación y verificación de sellos de tiempo Pág. 3 29/10/2015

4 Una vez instalado el entorno OpenSSL hay que poner en la variable path del sistema C:\OpenSSL-Win32\bin que es la instalación por defecto de la plataforma. De esta forma podemos ejecutar la herramienta desde cualquier directorio del sistema. La forma de invocar la herramienta es tecleando openssl. Momento en el cual entramos en el entorno OpenSSL> En la figura se observan el conjunto de comandos disponibles de la herramienta.. Pág. 4 29/10/2015

5 Los certificados X.509 tiene un estándar PKCS#6 pueden almacenarse en formato binario DER con extensiones.crt,.cer,.der. Tambíen pueden alamcenarse en formato PEM con extension.pem. La claves privada al igual que los certificados pueden estar en formato DER o PEM. Y las extensiones de los ficheros serían.der o.pem. El formato de las claves sigue el estandar PKCS#8. El formato PEM es la conversión base64 del formato DER a la que se añaden unos delimitadores del tipo -BEGIN CERTIFICATE- y -END CERTIFICATE Los archivos con extensión.p12 se utilizan para almacenar en un único fichero cifrado el certificado de clave pública de un usuario y su clave privada. La extensión.pfx (Personal information exchange) es similar que la *.p12 en el entorno windows. El formato de estos ficheros sigue el estándar PKCS#12. El entorno Openssl nos permite convertir formatos de certificados segun sean requeridos por nuestras aplicaciones Pág. 5 29/10/2015

6 Vamos a empezar a utilizar la herramienta creando un par clave privada-pública. La clave privada la vamos a tener en un fichero que podemos opcionalmente proteger con una clave y un algoritmo simétrico como DES, AES 256 La clave pública también la podemos crear en un fichero. Se extrae a partir de la clave privada. Pág. 6 29/10/2015

7 Vamos ahora a crear un certificado digital X.509. Este certificado nos permitirá autenticarnos frente a un servidor e implementar mecanismos de seguridad adicionales como la firma electrónica. Vamos a poner los siguientes campos en el certificado de la CA Country Name (2 letter code) [AU]:ES State or Province Name (full name) [Some-State]:MA Locality Name (eg, city) []:BOA Organization Name (eg, company) [Internet Widgits Pty Ltd]:FIM Organizational Unit Name (eg, section) []:UPM Common Name (eg, YOUR name) []:ALU1_CA Address []:ALU1_CA@fi.upm.es OpenSSL> Nótese que el comando para crear el certificado toma como parámetro de entrada el fichero de clave privada creada anteriormente. Podemos igualmente usar una clave privada cifrada; en este caso se nos pedirá la clave que cifra el fichero. Vamos a convertir el certificado a formato binario DER creando un fichero con extension *.crt. Ahora pinchando en el fichero desde el entorno Windows podemos ver que ha sido creado correctamente. También podemos crear un fichero con extension *.p12 que contenga el certificado de clave pública y la clave privada. Pinchando en el fichero obtenido desde el entorno windows se inicia un proceso de instalación del certificado. Éste se instalará en un almacén de certificado de usuario. Por último podemos ver en formato texto el certificado construido. El certificado obtenido es un certificado autofirmado en el que el emisor(emitido por) es igual que el propietario (Enviado a). Pág. 7 29/10/2015

8 Pág. 8 29/10/2015

9 Ahora nos vamos a crear un certificado de usuario pero firmado por una Autoridad de Certificación. El certificado que nos hemos creado con anterioridad coincidían los campos emisor y propietario, es decir era un certificado autofirmado. Ahora nos vamos a crea un certificado emitido por la Autoridad de Certificación. El proceso es el siguiente: En primer lugar generamos el par clave privada-pública. A continuación generamos una solicitud de firma, que en definitiva es un fichero con extensión *.csr. Este fichero lleva incorporado el certificado de usuario autofirmado con solicitud de ser firmado por una Autoridad de Certificación. Finalmente la Autoridad de Certificación tomando como parámetro su clave privada firmará el certificado. Los campos que pondremos en el certificado de usuario son los siguientes: Country Name (2 letter code) [AU]:ES State or Province Name (full name) [Some-State]:MA Locality Name (eg, city) []:BOA Organization Name (eg, company) [Internet Widgits Pty Ltd]:FIM Organizational Unit Name (eg, section) []:UPM Common Name (eg, YOUR name) []:alumno1seg Address []:alumno1seg@fi.upm.es Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:oooooo An optional company name []:oooooo Si queremos utilizar este certificado para firmar y cifrar mensajes con una aplicación de correo electrónico (como p.e outlook) necesitamos que el campo Address este correctamente rellenado a la direcciónió de correo del usuario. P.e si el usuario tiene la cuenta enel correo gmail el campo de Address deberá ser rellenado a alumno1seg@gmail.com. Pág. 9 29/10/2015

10 De forma similar a como hicimos con el certificado de la Autoridad de Certificación convertimos el certificado a formato binario DER (extensión *.cer) y también construimos el fichero *.p12 con el certificado de usuario y la clave privada protegidas por contraseña. Pinchando en el fichero usrcertificado.crt se observa que efectivamente se trata de un certificado firmado ya que los campos emisor (emitido por) y propietario (Enviado a) son diferentes. El emisor del certificado es la Autoridad que firma, que en nuestro caso se la Autoridad de Certificación que nos hemos creado. Pág /10/2015

11 Pág /10/2015

12 OpenSSL nos proporciona la infraestructura necesaria para crear nuestra propia Autoridad de Certificación, en adelante CA (Certification Authority). Nuestra CA será una entidad capaz de crear firmar certificado previa solicitud de un usuario, de revocar certificados, de conservar una base de Datos con los certificados firmados/revocados etc.. Para poder crear y gestionar nuestra propia CA es necesario crear un fichero de configuración de OpenSSL basado en el fichero por defecto openssl.cfg. Este nuevo fichero que lo llamaremos MyCA.cfg nos permitirá crear certificados firmados con las características particulares de nuestra organización Así mismo es necesario crear un árbol de directorios en el que almacenar los certificados creado/revocados, las bases de datos de los certificados creados y revocados y distintos ficheros de configuración. Con todo ello el siguiente paso sería crearnos el certificado de la CA. El que utilizaremos para firmar certificados de usuario. En general, los certificados de las Autoridades de Certificación deben ser dados a conocer por los usuarios. De esta forma los usuarios podrán (si lo consideran oportuno) instalar el certificado de la CA en su almacén de entidades emisoras raíz de confianza. Después de todos los pasos anteriores ya estaremos en condiciones de firmar certificados de usuario. Pág /10/2015

13 Para crear nuestro fichero de configuración que llamaremos MyCA.cfg, modificamos el fichero original openssl.cfg en tres secciones: [CA_default], [req_distinguished_name] y [policy_match] En [CA_default] especificamos la carpeta donde vamos a guardar el certificado de la CA, su clave privada, los certificados firmados, los revocados y los ficheros de registro de los certificados firmados y revocados. Pág /10/2015

14 En el campo [policy_match] se establece la política a seguir a la hora de firmar una solicitud de certificado certificado. Esta se podía denegar si en la solicitud aparece el campo cuntryname diferente al que tiene la CA. En nuestro fichero de configuración hemos quitado estas restricciones Como se aprecia en la figura eliminamos todas las restricciones a la hora de firmar un certificado por nuestra CA. Pág /10/2015

15 [req_distinguished_name] Se puedeen proporcionar valores por defecto a la hora de crear el certificado de la CA. Pág /10/2015

16 Para construir la infraestructura de una CA básica hay que crear un árbol de directorios que empieza en CA y que contenga las carpetas: Certs, newcerts, crl, csr, private, Además tiene que contener los ficheros serial, index.text, clrnumber y crl.pem. Estos cuatro ficheros deben de estar en la carpeta CA. index.txt y crl.pem deben estar vacios. Los ficheros serial y crlnumber deben tener el valor 01 y un salto de línea. Los dos primeros ficheros (serial, index.text) se utilizan para registrar los certificados firmados y los dos otros (clrnumber y crl.pem) se utilizan para registrar los certificados revocados Por último hay que añadir el mismo fichero de configuración MyCA.cfg Pág /10/2015

17 Las carpetas necesarias para crear la infraestructura de la CA se describen en la figura. Pág /10/2015

18 Con nuestras infraestructura de CA, la autoridad de Certificación no podrá firmar dos veces el mismo certificados para la misma máquina si haber revocado previamente el anterior. Si se intenta se obtendrá un mensaje de error diciendo que no se puede actualizar el fichero index.txt. Pág /10/2015

19 Una vez creada la carpeta CA en el directorio C:\OpenSSL-Win32 podemos invocar desde el anterior directorio los comando de la figura. Con el primer comando en línea nos creamos el fichero de certificado de la Autoridad de certificación CACertificado.pem en el directorio CA y el fichero con la clave privada de la CA CAClavePrivada.pem en la carpeta /CA/private/ req -new -x509 -days config./ca/myca.cfg -keyout /CA/private/CAClavePrivada.pem -out./ca/cacertificado.pem Con los dos comandos siguientes podemos construir el certificado de la CA en formato crt y en formato *.p12. Los ficheros generados CACertificado.crt y CA.p12 quedaran almacenados en la carpeta CA x509 -inform PEM -in./ca/cacertificado.pem -outform DER out./ca/cacertificado.crt pkcs12 -export -in./ca/cacertificado.pem inkey./ca/private/caclaveprivada.pem -out./ca/ca.p12 De esta forma obtendríamos el certificado en formato *.crt que podríamos instalar en el almacén de entidades emisoras raíz de confianza. Pág /10/2015

20 Pág /10/2015

21 Pág /10/2015

22 Pág /10/2015

23 Vamos a suponer como hemos visto anteriormente que un usuario genera una solicitud de firma de certificado. Desde el directorio C:\OpenSSL-Win32 ejecutamos los comandos que aparecen en la figura. Pág /10/2015

24 Nuevamente recordar que debemos estar en el directorio C:\OpenSSL-Win32 El fichero con la petición lo cargamos en la carpeta csr y lo vamos cambiamos de nombre según creemos nuevas peticiones y nuevos certificados Si tratamos de firmar una misma petición por segunda vez, la infraestructura de nuestra CA basada en OpenSSL nos dará el siguinete error: Certificate is to be certified until Oct 7 13:25: GMT (365 days) y) Sign the certificate? [y/n]:y failed to update database TXT_DB error number 2 error in ca Pág /10/2015

25 Pág /10/2015

26 Pág /10/2015

27 Pág /10/2015

28 Pág /10/2015

29 En la figura se aprecia el contenido del fichero index.txt después de firmar dos certificados de usuario con el certificado de nuestra CA. También se aprecia en la figura la carpeta en la que se almacenan estos certificados Pág /10/2015

30 Para revocar un certificado hay que copiarlo en primer lugar en la carpeta /CA/certs. A continuación se invocan desde el directorio C:\OpenSSL-Win32 los comandos que aparecen indicados en la figura. Pág /10/2015

31 En la figura seaprecia el resultado de la invocación del comando de revocación del segundo certificado Pág /10/2015

32 En la figura se aprecia el contenido del fichero index.txt y crl.pem. El primero contiene la lista de los certificados válidos y revocados. En el segundo esta el certificado completo revocado. La lista de certificados revocados debe ser puesta a disposición de los usuarios de la red de forma similar a como ponemos nuestra autoridad de certificación. Esto permite a los usuarios descargarse la lista de certificados revocados e instalarla en su ordenador, pudiendo comprobar que los certificados que le llegan, además de haber sido firmados por nuestra CA, continúan siendo validos para nuestra CA que los ha firmado. Pág /10/2015

33 El mecanismo de firma digital es esencial para implementar servicios como el no repudio. Un usuario que firma un documento con una clave privada asociada a un certificado de clave publica (avalado por una Autoridad de Certificación reconocida) no puede negar haber firmado un documento. El mecanismo de firma consiste en hacer un resumen de documento (aplicar una función hash) y cifrar el resultado con la clave privada del usuario: ClavePrivada[Hash(documento)]= BloqueCifrado El proceso de verificación de firma consiste en el proceso inverso: Se aplica la clave pública al BloqueCifrado anterior y se compara con el resumen del documento ClavePública[BloqueCifrado] se compara con Hash(documento) Si el resultado de esta comparación es afirmativa se considera verificada la firma. En la figura se muestra cómo generar resúmenes y el bloque cifrado con la línea de comandos OpenSSl. La firma de documentos se hace a partir de un fichero que contiene la clave privada. La verificación se hace extrayendo la clave pública del usuario de un fichero. Pág /10/2015

34 También se puede firmar un documento utilizando un fichero p12 en formato *.pem, es decir un fichero que contiene el certificado de usuario y su clave privada. Recordemos como generar el formato PEM a partir de un fichero *.p12: pkcs12 -in cert_user.p12 -out cert_userp12.pem Pág /10/2015

35 Un documento también podría cifrase con la clave pública obteniendo un bloque cifrado. En este caso sólo el propietario de la clave privada par de la anterior podría descifrar ese bloque cifrado. A diferencia del mecanismo de firma (cifrado con clave privada), el cifrado con clave pública lleva implícito el servicio de confidencialidad: Nadie puede acceder a los contenidos del bloque cifrado salvo el propietario de la clave privada. Los algoritmos de la criptografía asimétrica son lentos. Están pensados para cifrar poca cantidad de información. El ejemplo más común es usarlos para cifrar las claves de sesión intercambias entre dos usuarios. El protocolo SSL lo hace así: en el mensaje Intercambio_clave_cliente se envía las claves de sesión cifradas con la clave pública del servidor extraída de su certificado. En la figura se muestran los comando OpenSSL necesarios para cifrar con la clave pública un documento. La clave pública también se puede extraer así: rsa -in cert_userp12.pem -out publica.pem -pubout Pág /10/2015

36 El entorno OpenSSL proporciona de manera estándar muchos algoritmos de cifrado simétrico, incluidas diferentes variantes de cada uno. En la figura se muestra como cifra un documento de texto incluyendo la clave de cifrado en el comando. La clave también se puede introducir por teclado: des -in documento.txt -out documento_cifrado_des des d -in documento_cifrado_des -out documento_original_des.txt Pág /10/2015

37 Se pueden utilizar otros algoritmos de cifrado : OpenSSL> des3 -in documento.txt -out documento_cifrado_des3 -pass pass:clave OpenSSL> des3 -d -in documento_cifrado_des3 -out documento_original_des3.txt -pass pass:clave OpenSSL> aes-256 -ecb-in documento.txt -out documento_cifrado_aes -pass pass:clave OpenSSL> aes-256-ecb -d -in documento_cifrado_aes -out documento_original_aes.txt -pass pass:clave OpenSSL> rc4 -in documento.txt -out documento_cifrado_rc4 -pass pass:clave OpenSSL> rc4 -d -in documento_cifrado_rc4 -out documento_original_rc4.txt - pass pass:clave OpenSSL> idea-ecb -in documento.txt -out documento_cifrado_idea -pass pass:clave OpenSSL> idea-ecb -d -in documento_cifrado_idea -out documento_original_idea.txt -pass pass:clave Pág /10/2015

38 El correo electrónico es una aplicación unidireccional en la cual no se requiere en principio una contestación del usuario receptor. Si se quiere implementar servicios de seguridad en una aplicación que utiliza un solo intercambio hay que arbitrar algún procedimiento adicional. Si se quiere incorporar el servicio de confidencialidad, es conveniente cifrar la información con una clave de sesión que sólo conozcan el emisor y el receptor. Una forma de distribuir esta clave junto con los datos cifrados, es enviar la clave cifrada con la clave pública del receptor. Lógicamente el emisor debería conocer el certificado de clave pública del receptor. Si se quiere incorporar el servicio de no repudio, el emisor puede hacer un resumen del mensaje a enviar, cifrarlo con su clave privada y enviarlo junto al mensaje. Adicionalmente puede enviar su certificado de clave pública. El receptor del mensaje podrá verificar la firma utilizando la clave pública del certificado recibido. Los servicios de confidencialidad y de no repudio se puede proporcionar juntos en un mensaje de correo. Primero se firma el mensaje y luego se firma. Pág /10/2015

39 El formato PKCS#7 cifra un documento con una clave simétrica y un algoritmo de cifrado simétrico. Posteriormente, la clave de sesión se cifra con la clave pública del usuario que se extrae de su certificado de clave pública. El usuario receptor hace el proceso inverso: utiliza su clave privada para extraer la clave simétrica. Posteriormente utiliza la clave simétrica para descifrar el documento. El formato PKCS#7 es el formato estándar utilizado en mensajes de correo electrónico para implementar servicios de confidencialidad y autenticación. En la figura se indican los comandos OpenSSL necesarios para generar un bloque con formato PKCS#7 conteniendo un documento cifrado. Pág /10/2015

40 La firma de documentos con el formato PKCS#7 es muy común hoy en día. El formato de esta firma es que se utiliza en la aplicación de correo electrónico. El bloque de firma generado con PKCS#7 consta de los siguientes elementos: 1. Texto en claro 2. ClavePrivadaUsr[hash(texto en claro)] 3. Certificado de Usuario El receptor de dicho bloque hace un hash del primer elemento criptográfico, aplica la clave pública (recibida del certificado) al segundo elemento de este bloque y finalmente verifica que los resultados coinciden. En la figura se muestran los comandos OpenSSL para realizar la firma y verificación de documentos. Nótese que la verificación del bloque criptográfico smime se puede hacer verificando además la firma del certificado de usuario. Para ello necesitamos el certificado de la Autoridad de certificación que ha firmado el certificado. Pág /10/2015

41 Pág /10/2015

42 En la figura mostramos como combinar los mecanismos de firma y cifrado simétrico para proporcionar los servicios de confidencialidad y no repudio. Primero firmamos el documento con la clave privada del usuario emisor del mensaje. En segundo lugar deberíamos cifrar el bloque firmado con una clave de sesión, que a su vez cifraríamos con la clave pública del usuario receptor del mensaje. En el ejemplo de la figura estamos haciendo la suposición de que el emisor es el mismo que el receptor del mensaje. Una vez que el mensaje llegara al receptor este realizaría los siguiente pasos: En primer lugar descifraría del bloque recibido la clave de sesión simétrica. Una vez obtenida la clave, descifraría con el algoritmo simétrico el bloque de firma. Una vez obtenido el bloque de firma procedería a su verificación como se ha hecho en ejemplos anteriores Pág /10/2015

43 Apache es un servidor de páginas web que permite a una organización proporcionar a usuarios remotos (potenciales clientes) el acceso a la información pública o restringida de esa organización. La información pública puede ser servida sin establecer mecanismos de seguridad. Por ejemplo el catálogo de productos de la compañía, especificaciones técnicas, etc.. Sin embargo la información restringida requiere incorporar mecanismos de seguridad bien sea para proteger la información en tránsito, o bien para identificar al usuario (autenticación). Esta necesidad de incorporar mecanismo de seguridad se hace crítica cuando desde el portal web de la organización se va a realizar la compra de un producto y el cliente tiene que proporcionar datos de carácter confidencial. Por todo ello el servidor Apache incorpora el protocolo SSL a partir de las librerías de OpenSSL. En la figura se presenta el proceso de instalación del servidor apache incorporando las librerías de Openssl apache_ win32-x86-openssl-0.9.8i.msi Pág /10/2015

44 Podemos ver las opciones que tenemos en la instalación eligiendo una instalación personalizada Pág /10/2015

45 Instalamos las opciones por defecto. Pág /10/2015

46 Por defecto el servidor Apache después de la instalación no incorpora el protocolo SSL. Por defecto el servidor Apache sirve la página index.html localizada en: "C:/Archivos de programa/apache Software Foundation/Apache2.2/htdocs sin ningún mecanismo de seguridad. La opciones de configuración del servidor Apache están en el fichero httpd.conf de la carpeta C:\Archivos de programa\apache Software Foundation\Apache2.2\conf2\conf Para que nuestro servidor Apache pueda incorporar el protocolo SSL es necesario modificar el fichero de configuración original en dos apartados: Primero hay que cargar el Módulo de Seguridad OpenSSL con el protocolo SSL con la opción LoadModule d ssl_module l modules/mod_ssl.so. d l En segundo lugar hay que referenciar un fichero de configuración que será cargado al inicial el servidor web que gestionará la conexión segura mediante el protocolo SSL. Esto se hace con la opción #Include conf/extra/httpd-ssl.conf Pág /10/2015

47 El fichero en el que se configura el protocolo SSL es httpd-ssl.conf y se haya en la carpeta C:\Archivos de programa\apache Software Foundation\Apache2.2\conf\extra. Para poder configurar el protocolo SSL en el servidor Apache hay que indicar por un lado donde están el certificado del servidor (SSLCertificateFile: cert_user.pem ) y la clave privada asociada (SSLCertificateKeyFile: privkey_user.pem ). Por otro lado hay que indicar la carpeta (SSLCACertificatePath) y el nombre del certificado de la Autoridad de Certificación (SSLCACertificateFile) que firma el certificado anterior. En la figura la carpeta es: C:\Archivos de programa\apache Software Foundation\Apache2.2\conf y el el certificado es ca.pem. Nótese que los certificados y la clave privada del servidor están en formato PEM Pág /10/2015

48 Una de las opciones que permite el protocolo SSL es la Autenticación del cliente. El servidor puede solicitar al cliente un certificado. La situación más simple sería aquella en la que el servidor solicita un certificado de cliente firmado por la Autoridad de Certificación que hemos configurado en el apartado anterior Pág /10/2015

49 Finalmente podemos configurar la lista de revovacion de certificados contenida en el fichero crl.pem. Este fichero lo configuramos para que sea accesible desde el servidor Apache. Recordar que todas estas configuraciones deben de hacerse con el servidor Apache parado. Pág /10/2015

50 Vemos en la figura un ejemplo del servidor Apache funcionando en modo local. Asumimos que nuestro servidor Apache tiene configurado la Autoridad de Certificación denominada Alumno_CA y que el certificado del servidor esta emitido o tiene en el campo Common Name, CN el valor: localhost y lógicamente está firmado por la autoridad Alumno_CA. En la parte inferior izquierda vemos que el cliente se trata de conectar a la URL lh / Al intentar conectarse un cliente, el servidor Apache nos pide un certificado fiable para poder hacerlo. De entro los certificados que dispone el cliente en el almacén de certificados hay que escoger uno que esté firmado por la Autoridad de Certificación Alumno_CA. Pág /10/2015

51 Vemos que efectivamente el certificado alumno1seg está firmado por la Autoridad de Certificación Alumno_CA. Pág /10/2015

52 Vemos asimismo que el certificado Alumno1seg es fiable para nuestro sistema. Esto es así porque previamente en nuestro almacén de certificados hemos tenido que instalar el certificado alumno_ca en el almacén de entidades raíz de confianza. Pág /10/2015

53 En este momento que representa la figura, el protocolo SSL está accediendo a la clave privada asociada al certificado alumno1seg para firmar el conjunto de mensajes SSL de la sesión. Es el mensaje verificación certificado. Pág /10/2015

54 Finalmente, puesto que el certificado del cliente es valido podemos en primera instancia recoger la página que sirve el servidor Apache SSL. Sin embargo esta condición es necesaria, pero no suficiente. Se tiene que cumplir una segunda condición: El certificado del servidor debe proteger el sitio (la URL) a la que nos conectamos. Es decir la URL tiene que estar en el Common Name del certificado del servidor (darían igual el resto de los campos. Además de estar firmado por una Autoridad de Certificación fiable. En resumen, el cliente confía (o debe de confiar) en el certificado del servidor por dos motivos: 1: Está firmado por una entidad fiable. Es decir, el certificado de la CA está instalado dentro del almacén correspondiente a las entidades raíz de confianza. 2: La URL a la quesequiere conectar está en el campo Common Name, CN del certificado que recibe del servidor (protege el sitio). Pág /10/2015

55 Si intentamos acceder a nuestro sitio web con un certificado que ha sido revocado obtendríamos el siguiente mensaje. Pág /10/2015