certificados digitales en un entorno educativo · para la generación de estos certificados...
TRANSCRIPT
Eduardo Martínez Tobías
Julio Rubio García
Facultad de Ciencias, Estudios Agroalimentarios e Informática
Grado en Ingeniería Informática
2014-2015
Título
Director/es
Facultad
Titulación
Departamento
TRABAJO FIN DE GRADO
Curso Académico
Certificados digitales en un entorno educativo
Autor/es
© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2015
publicaciones.unirioja.esE-mail: [email protected]
Certificados digitales en un entorno educativo, trabajo fin de gradode Eduardo Martínez Tobías, dirigido por Julio Rubio García (publicado por la Universidad
de La Rioja), se difunde bajo una LicenciaCreative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.
Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a lostitulares del copyright.
Facultad de Ciencias, Estudios Agroalimentarios e Informática
TRABAJO FIN DE GRADO
Grado en Ingeniería Informática
Certificados digitales en un entorno educativo
Alumno:
Eduardo Martínez Tobías
Tutor:
Julio Jesús Rubio García
Logroño, Junio 2015
Resumen
Desde que se publicó la Ley de Administración Electrónica, el modo de relacionarse los
usuarios con los organismos públicos ha cambiado. Esta evolución que consiste en
fomentar el uso de los medios telemáticos ha provocado el desarrollo de herramientas
como la firma digital y de componentes como los certificados digitales.
Con este estudio queremos analizar cómo dotar a un organismo público educativo, como pudiera ser la Universidad de La Rioja, de una herramienta para gestionar las identidades digitales de los alumnos y trabajadores que realizan trámites administrativos con él.
En este trabajo instalaremos una infraestructura de clave pública para la generación de
certificados, exploraremos sus opciones más interesantes y desarrollaremos una
herramienta de integración para hacer más fácil su utilización dentro de aplicaciones
que requieran el uso de certificados digitales.
Palabras clave: Firma digital, certificado digital, infraestructur a de clave
pública, herramienta de integración .
Abstract
Since the Ley de Administración Electrónica was published, the way that users interact with public statements has changed. This evolution consists in promoting the telematics uses and has caused the development of tools like digital signatures as well as electronic components like digital certificates. This work aims at analyzing how to provide a public body, as the Universidad de La Rioja, with a tool to manage students and workers’ digital identities, so they can use it for administrative procedures. Our targets are: install a public key infrastructure to generate certificates, explore its most important options and develop an integration tool in order to make its use easier in the applications which require digital certificates.
Keywords: Digital signature, digital certificate, public key infrastructure,
integration tool.
1
Tabla de contenido
1. Introducción .......................................................................................................................... 4
2. Documento de objetivos del proyecto .................................................................................. 5
2.1. Descripción del proyecto .................................................................................................... 5
2.2 Justificación del proyecto .................................................................................................... 5
2.3 Alcance del proyecto ........................................................................................................... 5
2.3.1. Informe del alcance ..................................................................................................... 5
2.4 Recursos humanos y personales ......................................................................................... 6
2.5 Plan de comunicaciones ...................................................................................................... 6
2.6 Planificación del proyecto ................................................................................................... 6
2.6.1. Estructura de descomposición del proyecto ............................................................... 7
3. Presentación y configuración de EJBCA .............................................................................. 11
3.1 Análisis de alternativas ...................................................................................................... 11
3.2 Decisiones de implementación ......................................................................................... 11
3.3 Puesta en práctica ............................................................................................................. 12
3.3.1 Configuración del entorno de ejecución .................................................................... 12
3.3.2 Servidor de aplicaciones JBOSS .................................................................................. 12
3.3.3 Módulo EJBCA ............................................................................................................ 13
3.3.4 MYSQL ........................................................................................................................ 15
3.4 Discusión y posibles mejoras ............................................................................................. 16
4. Generación de perfiles y certificados .................................................................................. 18
4.1 Análisis de alternativas ...................................................................................................... 18
4.2 Decisiones de diseño ......................................................................................................... 19
4.2.1 Añadiendo campos en el DN ...................................................................................... 20
4.2.2 Añadiendo campos en el nombre alternativo del sujeto ........................................... 21
4.2.3 Añadiendo extensiones básicas ................................................................................. 22
4.3 Puesta en práctica ............................................................................................................. 23
4.3.1 Creación de perfiles de certificados ........................................................................... 23
4.3.2 Creación de entidades certificadoras ......................................................................... 26
4.3.3 Creación de entidades finales .................................................................................... 27
4.3.4 Generación del certificado ......................................................................................... 28
4.4. Discusión y posibles mejoras............................................................................................ 29
2
5. Validaciones ........................................................................................................................ 31
5.1 Análisis ............................................................................................................................... 31
5.2 Diseño ................................................................................................................................ 33
5.3 Implementación ................................................................................................................ 34
5.3.1 Certificado instalado en el navegador........................................................................ 35
5.3.2 Certificado exportado en un fichero .......................................................................... 37
5.3.3 Cambios para las llamadas al validador ..................................................................... 37
5.4 Pruebas y posibles mejoras ............................................................................................... 38
6. Gestión del proyecto ........................................................................................................... 41
7. Conclusiones........................................................................................................................ 43
7.1 Problemas más importantes encontrados ........................................................................ 43
7.2 Conocimientos adquiridos................................................................................................. 44
7.3 Trabajo futuro ................................................................................................................... 44
8. Bibliografía .......................................................................................................................... 46
9. Apéndice I – Instalación ...................................................................................................... 47
9.1 Modificación de la JVM (Java Virtual Machine) para que pueda manejar claves de gran
tamaño .................................................................................................................................... 47
9.2 Creación de un usuario administrador para acceso a la interfaz web de JBOSS .............. 47
9.3 Instrucciones ejecutadas a través de la interfaz cliente de JBOSS para modificar la
configuración por defecto ....................................................................................................... 48
10. Apéndice II – Perfil UNIRIOJA ROOT CA ............................................................................ 49
11. Apéndice III – Actas de reuniones..................................................................................... 51
Primera reunión ...................................................................................................................... 51
Segunda reunión ..................................................................................................................... 52
Tercera reunión ....................................................................................................................... 53
3
Índice de figuras
Figura 1. Estructura de descomposición en tareas del proyecto .................................................. 7
Figura 2. Programación temporal de las tareas a realizar .......................................................... 10
Figura 3. Representación en diagrama de Gantt de las tareas ................................................... 10
Figura 4. Modelo de arquitectura en un sistema con varias instancias ...................................... 17
Figura 5. Representación de nuestra jerarquía de certificados .................................................. 23
Figura 6. Formulario del sistema de notificaciones en los perfiles de entidad final ................... 27
Figura 7. Formulario para la creación de una entidad final ........................................................ 28
Figura 8. Protocolo de una solicitud de un certificado ............................................................... 29
Figura 9. Casos de uso para la aplicación de validación .............................................................. 32
Figura 10. Esquema UML de las clases del módulo de validación OCSP ..................................... 33
Figura 11. Representación de la clase de utilidades es.unirioja.tfg.edmartt.CertUtils ............... 34
Figura 12. Aspecto del menú modificado con las nuevas opciones ............................................ 35
Figura 13. Ventana de selección de certificado del navegador solicitada por el servidor .......... 36
Figura 14. Pantalla de resultados de la validación ...................................................................... 36
Figura 15. Pantalla de selección de un certificado contenido en un fichero .............................. 37
Figura 16. Pantalla con la relación de certificados emitidos y sus funciones ............................. 39
Figura 17. Pantalla de validación de un certificado revocado por clave comprometida ............ 39
Figura 18. Hilo sobre cómo incorporar OID en el Subject alternative name .............................. 43
Figura 19. Cabecera de definición del perfil de certificado UNIRIOJA ROOT CA ........................ 49
Figura 20. Permisos asignados durante la generación de certificados ....................................... 49
Figura 21. Definición de extensiones .......................................................................................... 49
Figura 22. Información de revocación ......................................................................................... 50
Figura 23. Información adicional de definición del perfil............................................................ 50
4
1. Introducción
Hoy en día la gran mayoría de organismos públicos disponen de medios telemáticos para poder realizar trámites administrativos con ellos. Para poder realizar estos procesos, además de necesitar de adaptaciones dentro de las aplicaciones convencionales y publicarlas en un entorno web, necesitan de un elemento imprescindible para poder completar todos los procesos, la firma digital. Todo usuario que quiera emplear estos medios telemáticos necesita certificar su identidad frente al organismo público. Para esta identificación, vía web, se necesita de un certificado digital, componente informático que garantiza que la identidad de la persona que está realizando en un momento determinado un trámite es la que dice ser. Para eso, se consulta a un tercero de confianza (entidad certificadora) que avala que el certificado es válido y está emitido para la persona a la que representa. Este estudio consiste en la creación de una entidad certificadora, basada en una infraestructura de clave pública, para un entorno como podría ser la Universidad de La Rioja. A continuación se ha desarrollado un módulo JAVA para facilitar la integración de estos certificados con aplicaciones y por último se ha desarrollado un ejemplo de integración, basado en un validador de certificados. Esta memoria recoge la información más relevante de estas tareas, que componen el trabajo fin de grado de Eduardo Martínez Tobías.
5
2. Documento de objetivos del proyecto
2.1. Descripción del proyecto
Instalación y puesta en marcha de una infraestructura de clave pública (PKI, Public Key Infrastructure) basada en una solución open source llamada EJBCA (Enterprise Java Bean Certificate Authority). Se especificarán diferentes perfiles de certificados adecuados al mundo universitario. Se pondrá en marcha la validación de la revocación de certificados a través de un servicio OCSP (Online Certificate Status Protocol). Además se desarrollarán funcionalidades extras dentro de la PKI. Se crearán herramientas para facilitar su integración dentro de aplicaciones web. Se tratará de virtualizar la instalación de la PKI para su uso en la asignatura de Seguridad del Grado de Ingeniería Informática.
2.2 Justificación del proyecto
La idea de este trabajo surgió a partir de mi propia experiencia laboral y de la relación con la Universidad durante los procesos administrativos que he tenido que ir completando de matrícula, envío de datos bancarios, etc. al constatar que no existía una solución para poder realizar de forma telemática parte de los trámites administrativos por requerir firma del usuario y no existir una alternativa electrónica.
2.3 Alcance del proyecto
2.3.1. Informe del alcance
El primer objetivo que se plantea en este estudio es realizar una simulación sobre cómo dotar a las personas que trabajan y estudian en esta universidad de un certificado digital. En función de la relación que tenga esa persona con la universidad se le generará un certificado adecuado a su perfil de usuario: alumno, profesor o personal de administración (P.A.S.). Para la generación de estos certificados necesitaremos de una infraestructura de clave pública. Como solución PKI hemos elegido la versión 6.2.0 de EJBCA. Se trata de una PKI de código abierto desarrollada en JAVA. En este estudio se describirán los puntos más importantes encontrados durante el proceso de instalación, despliegue y configuración. Además se mostrarán los diferentes perfiles de certificados que se propone generar y los metadatos más destacados que contienen estos certificados. Para facilitar la integración de estos certificados con otras aplicaciones se desarrollará una librería en JAVA (API, application programming interface). Además de
6
funcionalidades particulares de estos certificados, se incluirán otras genéricas para el tratamiento de certificados desde las aplicaciones que quieran integrarse. Por último se desarrollará un validador para los certificados que generaremos, por un lado como ejemplo de integración de una aplicación web con nuestra API y, por otro, como herramienta para determinar el estado de nuestros certificados en cualquier momento.
2.4 Recursos humanos y personales
El desarrollo y puesta en marcha del proyecto lo realizará Eduardo Martínez Tobías. El seguimiento y las labores de tutoría las realizará Julio Jesús Rubio García.
2.5 Plan de comunicaciones
Para el seguimiento del proyecto se empleará el correo electrónico. Fundamentalmente servirá para ir aclarando dudas sobre el alcance y los objetivos del trabajo, repartición de tiempos para la consecución de objetivos, consejos de forma a la hora de afrontar y resolver un problema, así como la consecución de los hitos marcados. Otro elemento fundamental serán las reuniones presenciales con Julio Rubio, mi tutor. Intentaremos que sean periódicas y que marquen el devenir del trabajo final. En esas reuniones consideramos “cómo empezar”, “por dónde vamos hasta ahora”, “hasta dónde queremos llegar” o “pasar a la fase siguiente”.
2.6 Planificación del proyecto
Al tratarse de un trabajo en el que parte es investigación o se trata de tareas que nunca antes he realizado me resulta complicado hacer una propuesta de horas fiable.
Para la realización de este trabajo tendré que conciliar mi vida laboral y personal con su desarrollo. Por lo que inicialmente me he planteado la realización de dos horas diarias de media desde su inicio el 03 de febrero de 2015 hasta la fecha de la entrega. Se marcarán varios hitos dentro del desarrollo que se irán revisando:
Instalación, puesta en marcha y configuración de EJBCA.
Determinación, generación de perfiles de certificados y certificados de entidad final
Personalización de perfiles para adaptarlos a un entorno universitario
Desarrollo del API
Desarrollo del validador
Memoria
7
2.6.1. Estructura de descomposición del proyecto
Figura 1. Estructura de descomposición en tareas del proyecto
PT000 Gestión del plan (15 horas): Seguimiento contínuo del plan del proyecto y realización de las tareas correspondientes en cada momento. A0000 Seguimiento del plan de alcance. (10 horas) A0001 Seguimiento del plan de comunicaciones. (5 horas) PT001 Reuniones (20 horas): Tareas para preparar las reuniones y elaborar las actas a lo largo de todo el trabajo. A0010 Preparación de cada reunión. (3 horas) A0011 Realización del acta de cada reunión. (3 horas) A0012 Reuniones. (14 horas) PT002 Creación del plan (10 horas): Determinar qué tareas realizar y establecer unas prioridades para su ejecución.
8
A0020 Documentación y recopilación de información para la realización del plan del proyecto. (7 horas) A0021 Creación del plan de proyecto. (3 horas) PT003 Creación de la memoria (50 horas): A0030 Recopilación de documentación. A0031 Realización de la memoria. PT004 Defensa (30 horas): A0040 Preparar información más relevante del trabajo. (29,5 horas) A0041 Defensa del trabajo frente al tribunal. (0,5 horas) PT005 Documentación (20 horas): A0050 Localizar documentación e implementaciones reales de la solución propuesta. (14 horas) A0051 Lectura y aprendizaje. (6 horas) PT010 Preparación de entorno de instalación (10 horas): Localizar e instalar el sistema operativo recomendado por la plataforma EJBCA para su correcto funcionamiento. A0100 Localizar/Descargar SO recomendado. (0,5 horas) A0101 Instalar versión de SO recomendado. (8 horas) A0102 Configuración del SO. (1,5 horas) PT011 Instalación del servidor de aplicaciones (5 horas): Instalar y hacer funcionar el servidor de aplicaciones donde se ejecutará el módulo con la funcionalidad de la PKI. A0110 Localizar/Descargar servidor de aplicaciones recomendada. (1 hora) A0111 Instalar versión del servidor de aplicaciones recomendada. (4 horas) PT012 Despliegue del módulo EJBC (5 horas): Desplegar la aplicación (encapsulada en un fichero .ear, Enterprise ARchive) dentro de nuestro servidor de aplicaciones estableciendo un entorno estable y hacerlo como una posible distribución de un entorno de producción. A0120 Despliegue dentro del servidor de aplicaciones. (0,5 horas) A0121 Puesta en marcha y configuración. (4,5 horas)
9
PT013 Adaptación de la plataforma a un entorno universitario (25 horas): Detectar las teóricas necesidades dentro de la universidad e intentar cubrirlas mediante la creación de certificados en función de los diferentes trabajadores de la universidad y de los alumnos. A0130 Análisis de las necesidades. (7 horas) A0131 Definición de los perfiles de certificados necesarios. (15 horas) A0132 Creación de perfiles de certificados. (3 horas) PT014 Habilitar OCSP (12 horas): Activar el servicio de OCSP para poder validar el estado de revocación de los certificados emitidos por nuestra PKI. PT020 Estudio en entorno WINDOWS (15 horas): Analizar la posibilidad de desplegar nuestro módulo dentro de un entorno WINDOWS y su posterior virtualización en este entorno. Determinar además las versiones más adecuadas. PT021 Estudio en entorno LINUX (10 horas): Necesidades para desplegar nuestro módulo en un entorno LINUX y su posterior virtualización. PT030 Elección de lenguajes y tecnologías (2 horas): Tanto para los complementos propuestas dentro de la plataforma como para los componentes externos a ella se valorarán algunas alternativas. A0300 Selección de metodología de programación. (1 hora) A0301 Selección de lenguaje para back-office. (0,5 horas) A0302 Selección de tecnologías para front-end. (0,5 horas) PT031 Validador de certificados on-line (16 horas): Analizar las funcionalidades que deberá prestar el validador así como la salida, el diseño y los estilos a aplicar. PT032 Gestión de alertas (30 horas): Utilizar la información almacenada en la plataforma para usarla en el envío de alertas de caducidad o de revocación de los certificados emitidos. A0320 Enlace con la base de datos de EJBCA. (7 horas) A0321 Análisis y diseño del planificador de alertas. (23 horas)
10
PT033 Desarrollo API de integración (25 horas): Componente para la integración de validación de certificados de nuestra PKI dentro de aplicaciones web. A0330 Análisis y diseño. (22 horas) A0331 Documentación del API. (3 horas) En las figuras 2 y 3 tenemos la representación temporal de mis tareas mediante un diagrama de Gantt. El desarrollo de las tareas y su duración las he representado con los criterios anteriormente mencionados.
Figura 2. Programación temporal de las tareas a realizar
Figura 3. Representación en diagrama de Gantt de las tareas
11
3. Presentación y configuración de EJBCA
3.1 Análisis de alternativas
A la hora de determinar qué aplicación emplear de todas las que existen en el mercado me decanté por esta solución por varios criterios:
Se trata de una solución de código abierto con una comunidad de desarrolladores y de apoyo bastante activa. Es un producto en evolución pero que está implantado en organismos nacionales e internacionales por lo que se trata de un software de contrastada solvencia.
Está instalado como solución en producción para grandes organismos públicos como la PKI de la Comunidad Valenciana (que en 2013 emitió 88.500 certificados), los ministerios de defensa y finanzas franceses o entidades educativas como la Universidad de Zurich.
El lenguaje en el que está desarrollado es JAVA que es el que más domino.
Se trata de un aplicativo muy flexible con el que se pueden hacer diferentes tipos de instalaciones en función del volumen que vaya a tener que atender el servicio, niveles de seguridad, infraestructura de servidores, etc.
Además este software es capaz de generar certificados que se ajusten a lo exigido por la Ley 59/2003 de firma electrónica y que sean reconocidos por otros organismos públicos de cara a establecer una cadena de confianza. Se valoraron alternativas como el software empleado por la FNMT de SAFELAYER y otras, pero se trata de productos de pago. Además sus licencias no permiten incorporar mejoras por parte de una comunidad de desarrolladores. Así que no se cumplen algunos de los objetivos marcados en este trabajo como es el desarrollo de un API, como medio de enriquecimiento de la herramienta.
3.2 Decisiones de implementación
Para la instalación de la herramienta en modo piloto para su evaluación y puesta en marcha se ha elegido el siguiente entorno: Sistema operativo: Windows 7 64 bits Servidor de aplicaciones: JBoss Application Server 7.1.1 Servidor de base de datos: MYSQL 6.2 Versión de JAVA: 1.8.0.45 Me he decantado por esta instalación para la prueba de la herramienta por el uso, en su mayoría, de productos gratuitos y por ser una de las instalaciones recomendadas. Esta instalación, que podría definirse como una instalación de prototipo, podría perfectamente utilizarse como una instalación en producción realizando pequeños cambios.
12
En primer lugar habría que personalizar y cambiar las opciones y contraseñas que se proponen por defecto. Además se necesitaría incorporar un dispositivo HSM (Hardware Security Module) para la custodia de las claves generadas, que por defecto se almacenan en soporte software, mucho menos seguro. La instalación de un módulo EJBCA independiente, al que llegarían todas las consultas del estado de los certificados, mejoraría la seguridad y la capacidad de nuestra solución. Se puede ver un ejemplo de esta arquitectura en la figura 4 de este mismo capítulo. Para alcanzar el objetivo de este trabajo consideramos que estas modificaciones sobre la instalación realizada no son necesarias por el alcance del mismo y por el coste que supone la adquisición de un dispositivo HSM, por ejemplo.
3.3 Puesta en práctica
Durante el proceso de instalación he tenido que modificar algunos ficheros de configuración y propiedades de EJBCA, así como del servidor donde se va a desplegar. Las modificaciones más relevantes están reflejadas en esta memoria. Se puede encontrar detalle de algunos procesos concretos en el apéndice I. Estos son los pasos que he realizado durante la instalación y el despliegue:
3.3.1 Configuración del entorno de ejecución
Descarga1 de la JDK 1.7.
Creación de la variable de entorno JAVA_HOME.
Modificación de la JDK para que permita el manejo de claves de gran tamaño. En el apéndice I se puede consultar este proceso.
Descarga2 de JAVA ANT para la gestión de la aplicación y su instalación y despliegue en el servidor.
Inclusión en el PATH del equipo las rutas a JAVA_HOME y ANT.
3.3.2. Servidor de aplicaciones JBOSS
Descarga del servidor JBOSS en su versión 7.1.1 Final, servidor recomendado por EJBCA para su despliegue. Se trata de un servidor de aplicaciones J2EE que se adapta perfectamente a nuestras necesidades. El primer paso será crear un usuario administrador para poder acceder a la consola de gestión de JBOSS. La creación de este usuario se explica en el apéndice I. Desde esta consola de administración se pueden consultar parámetros de configuración y gestionar los despliegues de aplicaciones en JBOSS.
1 http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html
2 http://ant.apache.org/bindownload.cgi
13
Además JBOSS dispone de una interfaz en modo línea de comandos CLI (Command Line Interface). Esta herramienta la emplearemos para aplicar cambios en la configuración por defecto de JBOSS. Una de las modificaciones que vamos a aplicar consiste en cambiar el nivel de log del servidor a modo debug para tener una traza detallada de los problemas que puedan surgir durante los despliegues de nuestras aplicaciones. Otra modificación consiste en ampliar la tabla de caracteres para que cuando se publiquen recursos desde EJBCA no haya problemas con caracteres especiales. Los comandos concretos que he aplicado se pueden consultar en el apéndice I. Por último deberemos configurar el conector del JBOSS para la conexión https asegurándonos que las rutas a los almacenes de certificados para negociar el SSL son las correctas. Esta información se encuentra en el fichero jboss_home/standalone/configuration/standalone.xml. Si esta información no está correctamente indicada después no tendremos acceso a la parte de administración. <connector name="httpspriv" protocol="HTTP/1.1" scheme="https" socket-
binding="httpspriv" redirect-port="8443" secure="true">
<ssl key-alias="localhost" password="serverpwd" certificate-key-
file="c:\\jboss\standalone\configuration\keystore\keystore.jks" verify-client="true" ca-
certificate-file="c:\\jboss\standalone\configuration\keystore\truststore.jks" ca-
certificate-password="changeit"/>
</connector>
<connector name="httpspub" protocol="HTTP/1.1" scheme="https" socket-
binding="httpspub" secure="true">
<ssl key-alias="localhost" password="serverpwd" certificate-key-
file="c:\\jboss\standalone\configuration\keystore\keystore.jks"/>
</connector>
3.3.3 Módulo EJBCA
Descargar3 el módulo EJBCA. Se trata de un fichero .zip que deberemos descomprimir. Al descomprimirlo nos creará una carpeta con el nombre y la versión de nuestro módulo EJBCA. En nuestro caso ejbca_6_2_0. Dentro de este directorio vemos varios subdirectorios. Dentro de la carpeta modules tenemos todos los diferentes módulos en los que se divide nuestro aplicativo. Cuando compilemos y empaquetemos el proyecto mediante ANT nos creará un archivo .war (Web Application Archive) por cada uno de estos módulos. La carpeta conf contiene una serie de ficheros que potencialmente serán los ficheros de propiedades del proyecto pero que inicialmente están renombrados con la extensión .sample. Para activar estos ficheros haremos una copia del fichero que queremos personalizar y renombrarlo eliminando del nombre la extensión .sample. De todos los que existen en ese directorio he necesitado los siguientes:
3 http://www.ejbca.org/download.html
14
ejbca.properties: En este fichero debemos indicar dónde tenemos instalado el servidor sobre el que vamos a hacer el despliegue. Las propiedades a modificar son: # Tipo de servidor
appserver.home=c:\\jboss
# Tipo de servidor
appserver.type=jboss
install.properties: Contiene los parámetros que por defecto nos va a proponer durante la instalación del módulo EJBCA dentro del JBOSS. Partiendo de estos valores se va a crear una entidad de certificación y se va a generar un certificado. Este certificado será el que se emplee para la identificación de la administración de EJBCA una vez que la tengamos instalada y operativa. Es decir, en el proceso de instalación se crea una CA, un certificado de entidad final y será éste el que se configure para permitir el acceso al panel de administración de EJBCA. Dejamos las opciones que vienen por defecto, pero debemos de activar el .properties.
web.properties: Dejaremos las opciones que vienen por defecto. Entre otros datos tenemos el CN (Common Name, nombre que representa ese certificado) que vamos a autorizar para el acceso al panel de administración, contraseñas de almacenes de certificados y los puertos para el acceso por http y https (para configurar las rutas dentro de la aplicación).
ocsp.properties: Renombrar el fichero. Dejamos las opciones por defecto. Con esto activaremos el servicio OCSP para verificar el estado de revocación de los certificados.
database.properties: En este fichero configuraremos la conexión con la base de datos. Si realizamos y mantenemos la instalación por defecto se creará el esquema sobre la base de datos que trae integrada JBOSS (MariaDB). Para nuestro estudio queremos realizar la instalación sobre MYSQL. En la siguiente sección se enumerarán las principales modificaciones que hemos tenido que realizar para hacer este cambio.
Una vez configurado adecuadamente nuestro módulo, deberemos hacer la instalación dentro del servidor de aplicaciones. Para ello hay que ir al directorio donde tenemos EJBCA y, a través de línea de comandos y con el servidor levantado, ejecutaremos: ant install
Con esta instrucción (que sólo deberemos de ejecutar una única vez) se desencadena un proceso en el que se generan las credenciales para acceder en modo administrador a nuestro aplicativo. Para ello se realiza el siguiente proceso:
15
Primero se genera una entidad certificadora, cuyas propiedades se encuentran dentro del fichero install.properties. Esta CA, autogenerada, será necesaria para crear el certificado del usuario administrador.
Además incorpora dentro del almacén de certificados de confianza del servidor (JBOSS_HOME\standalone\configuration\keystore\truststore.jks) la parte pública de esta CA recién generada para que el servidor la interprete como una CA de confianza y así podamos utilizar los certificados recién generados para identificación
Genera un certificado de administrador en un fichero (EJBCA_HOME/p12/superadmin.p12). Este certificado deberá ser importado al navegador desde el que vamos a querer acceder a la administración de EJBCA. Estas serán las credenciales necesarias para garantizar que el usuario es administrador de la aplicación.
Una vez completado el proceso de instalación podríamos realizar cambios posteriores en la configuración de EJBCA modificando estos ficheros de propiedades. Después de estas modificaciones y para que estos cambios surtan efecto deberemos ejecutar desde el directorio de instalación de EJBCA los siguientes comandos y reiniciar el servidor: # elimina el despliegue actual
ant clean
# realiza el despliegue de EJBCA con las condiciones actuales
ant deploy
3.3.4 MYSQL
Para esta instalación piloto vamos a conectar EJBCA con una base de datos MYSQL por
su potencia y la facilidad de acceso posterior para la explotación de la información que
se va almacenando en ella. Tras la descarga4 y la instalación por defecto, tendremos
que realizar una serie de adaptaciones:
Sobre el database.properties incluiremos las siguientes modificaciones
sobre la URL donde tengo mi servidor de base de datos, usuario,
contraseña, esquema, driver de base de datos elegido, es decir todo lo
necesario para que EJBCA vuelque la información a MYSQL:
datasource.jndi-name=EjbcaDS
database.name=mysql
database.url=jdbc:mysql://127.0.0.1:3306/ejbca
database.driver=com.mysql.jdbc.Driver
database.username=ejbca
database.password=ejbca2015
database.useSeparateCertificateTable=true
Copiar el driver elegido (JAVA) a la carpeta jboss_home/standalone/lib/ext.
Crear el directorio jboss_home/modules/com/mysql/main y copiar el driver.
4 http://dev.mysql.com/downloads/file.php?id=455548
16
Crear un fichero module.xml y copiarlo en la ruta anterior.
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="com.mysql">
<resources>
<resource-root path="mysql-connector-java-5.1.34-bin.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
<module name="javax.transaction.api"/>
</dependencies>
</module>
Registrar el driver MYSQL a través del interface cliente de JBOSS:
/subsystem=datasources/jdbc-
driver=com.mysql.jdbc.Driver:add(driver-
name=com.mysql.jdbc.Driver,driver-class-
name=com.mysql.jdbc.Driver,driver-module-name=com.mysql,driver-
xa-datasource-class-
name=com.mysql.jdbc.jdbc.jdbc2.optional.MysqlXADataSource)
:reload
Con todo esto ya tenemos nuestro módulo EJBCA conectado con una base de datos
MYSQL. A partir de este momento toda la base de datos de nuestros certificados será
accesible de una forma más sencilla.
3.4 Discusión y posibles mejoras
La implantación que he realizado de EJBCA ha permitido crear una PKI con garantías
para poder evaluar sus posibilidades durante el proceso de configuración, generación y
evaluación de certificados.
Durante la instalación he conservado gran parte de las opciones que vienen por
defecto, contraseñas de administración, almacenes de certificados y otros recursos y
he personalizado otras opciones con el fin de explorar las posibilidades para una
implementación futura en producción.
Para el desarrollo de este trabajo sólo he trabajado con una instancia de EJBCA pero si
nos encontramos con un escenario de muy alta demanda, la herramienta está
preparada para trabajar en cluster y para desarrollar una instalación con diferentes
instancias dedicadas a cada una de las tareas que una PKI necesita: validación de
certificados, emisión de certificados y generación y custodia de claves.
Trabajar con diferentes instancias además de mejorar el rendimiento nos permite
adecuar las medidas de seguridad a cada entorno. Podemos, por ejemplo, instalar
medidas de seguridad extra en los elementos más sensibles, como pueden ser las
partes encargadas de custodiar las claves de firma de certificados, con respecto a otras
que necesitan máxima disponibilidad y visibilidad al exterior pero no tanta seguridad,
17
como el módulo encargado de recibir las peticiones de consulta de revocación de un
certificado o la encargada de emitir certificados de entidad final (RA registration
authority).
Figura 4. Modelo de arquitectura en un sistema con varias instancias
EJBCA dispone de dos perfiles de acceso. El perfil público está disponible y abierto para
cualquier usuario que conozca la dirección donde está publicada nuestra PKI. En este
apartado público aparecen las opciones para que cada usuario final pueda descargar su
certificado una vez que el administrador ha realizado todas las tareas de generación
(RA). Con el modelo representado en la figura 4, esta sección pública debería
implementar unas medidas de seguridad adecuadas para conseguir máxima
disponibilidad para accesos externos y a la vez tener una seguridad razonable.
La parte privada (perfil de administración), además de estar bajo protocolo seguro,
podría tener limitado el acceso desde el exterior e intentar que todas las peticiones
que se hagan a la parte de generación y custodia de certificados sean accesos
exclusivamente desde la intranet con el fin de evitar, en lo posible, ataques externos.
Por último la independencia que presentan todos los componentes permitiría migrar a
otro motor de base de datos, si fuera necesario, ya que las tareas de persistencia de
información están desarrolladas desacopladamente del gestor de base de datos que
tengamos instalado.
18
4. Generación de perfiles y certificados
4.1 Análisis de alternativas
Para la creación desde cero de un certificado necesitamos generar varios elementos
previos antes de conseguir nuestro certificado de entidad final.
En primer lugar necesitamos la creación de un certificado raíz. Se trata de un
certificado autofirmado que va a ser el origen de todos los certificados de nuestra
entidad certificadora. Una entidad certificadora se corresponde con un certificado raíz.
EJBCA permite la gestión de varias entidades certificadoras. En nuestro caso vamos a
crear una única entidad certificadora que vamos a llamar UNIRIOJA y a la que vamos a
calificar con la información relativa a la Universidad de La Rioja. De ésta dependerá el
resto de certificados que emitamos.
Además crearemos entidades subordinadas (que estarán firmadas por nuestro
certificado raíz, ROOT, creado anteriormente) o entidades intermedias intentando
aglutinar los certificados que tengan características afines.
La creación de entidades intermedias facilita la gestión de los certificados desde la
herramienta ya que esta clasificación permite acceder a la información de los
certificados de forma más sencilla. Nos permite tener clasificados los certificados
inicialmente en varios tipos. Además podemos configurar más adecuadamente los
perfiles y las características de nuestros certificados adecuándolos mejor al propósito
para el que son generados. Otra ventaja es que de esta división en grupos podemos
seguir creando subdivisiones si consideramos que nos puede aportar mejoras en la
gestión de los certificados que vamos generando, aplicar cambios en una rama de
certificados que no afectan a la otra rama. En definitiva conseguimos más versatilidad.
Cada certificado raíz y sus subordinados se generan a partir de perfiles de certificados
que previamente se han tenido que definir.
Un perfil de certificado define la información y estructura que el certificado va a tener,
referencias de validación, emisión de certificados dependientes, usos para los que se
emitirán certificados con ese perfil, es decir, describe cómo serán todos los certificados
generados a partir de ese perfil y la información y estructura común que van a
contener.
EJBCA dispone de unos perfiles por defecto para la creación de CA’s y SUBCA’s.
También dispone de perfiles por defecto para certificados de entidad final. Podríamos
usar para la generación de nuestros certificados estos perfiles genéricos pero, para
19
realizar una mejor adaptación al uso dentro de una universidad, generaremos perfiles
personalizados, eso sí, partiendo de los genéricos.
Por último necesitaremos crear perfiles de entidad final. Crearemos uno por cada uno
de los tipos de certificados que vayamos a generar. Cada perfil de certificado de
entidad final tendrá algunos datos como no modificables y que marcarán el tipo de
entidad que se va a generar para mantener una homogeneidad en el formato de los
certificados de entidad final.
4.2 Decisiones de diseño
Con todo lo expuesto anteriormente y con la estructura que tienen tanto los sujetos
que se relacionan con la universidad como de la organización interna vamos a definir
nuestra jerarquía de certificados.
En primer lugar generaremos un certificado de entidad certificadora (CA) que
etiquetaremos como UNIRIOJA ROOT CA. Para nuestro caso concreto crearemos sólo
dos entidades certificadoras subordinadas (SUBCA). Una entidad intermedia que
aglutinará los certificados emitidos para personas físicas (que llamaremos UNIRIOJA PF
SUBCA) y otra entidad intermedia para aglutinar los certificados que representen a
facultades o unidades administrativas dentro de la universidad (que llamaremos
UNIRIOJA COMP SUBCA).
Por último crearemos un perfil de certificado de usuario final, para ajustar las
propiedades que queremos, dentro de los certificados de personas físicas y otro para
los certificados de componente.
La herramienta, por defecto, sólo me permite incluir en nuestros perfiles unos
determinados campos dentro de nuestros certificados. Pero para nuestro trabajo
necesitaremos algunas características particulares que califiquen nuestros certificados
con propiedades específicas.
Esta necesidad nos va a servir para explorar los diferentes mecanismos que EJBCA
tiene para personalizar los perfiles y los campos con los que por defecto podemos
trabajar. En concreto para los certificados de personas nos interesaría determinar de
qué tipo es (Alumno, Profesor o P.A.S.) y de qué especialidad (en el caso de alumnos
qué estudios cursa, en el del profesor a qué facultad está adscrito o en el caso del
personal administrativo a qué unidad pertenece).
A la hora de incorporar estos campos nuevos, que llamaremos “Tipo de certificado” y
“Especialidad”, debemos asignarles un identificador único u OID (de sus siglas en inglés
Object Identifier Digital). Para elegir un identificador para cada uno de los campos
20
hemos decidido acudir a la página web5 de REDIRIS donde se enumeran los OID’s
reservados por el momento para la comunidad educativa en España.
Si este estudio teórico pasara a ser una realidad deberíamos de proceder a registrar los
OID’s con los que vamos a trabajar. Para nuestro caso y pensando que hemos realizado
los correspondientes trámites hemos “reservado” el OID 1.3.6.1.4.1.7547.1.27 un
derivado del genérico 1.3.6.1.4.1.7547. Se trata del primer identificador libre de
universidad.
El siguiente paso es ver cómo incorporamos estos dos nuevos campos (no estándar)
dentro de nuestros certificados. A través de la herramienta tenemos tres modos de
hacerlo. He explorado las tres formas a fin de determinar qué modelo es el que más
nos interesa.
4.2.1 Añadiendo campos en el DN
EJBCA permite la creación de campos personalizados en el DN (Distinguished Name).
Para ello deberemos de realizar modificaciones en dos ficheros de propiedades.
El primero de ellos es ejbca_home\src\java\profilemappings.properties.
En este fichero nos encontramos con los atributos que por defecto EJBCA tiene definidos para los campos de certificado DN y nombre alternativo del sujeto. Al principio del fichero de propiedades aparecen las instrucciones para incorporar nuevos campos y el formato de las nuevas entradas. Incorporamos al final de todo el contenido que viene por defecto las siguientes entradas:
DN;2.16.840.1.113730.1.7;203;2.16.840.1.113730.1.7;203;Tipo de
usuario;DNTIPOCERTIFICADOINDENTIFIER
DN;2.16.840.1.113730.1.9;204;2.16.840.1.113730.1.9;204;Especialidad;ES
PECIALIDADINDENTIFIER
El formato es:
<Tipo de entrada>;<OID>;<identificador interno>;<OID>;<Denominación>;<identificador interno>;<Clave del fichero de idiomas para este elemento>
El identificador interno deberá ser un número entero entre 200 y 299. Es importante que una vez tengamos definidos estos campos en el fichero de propiedades y hayamos vinculado nuestros perfiles de certificados a estos dos nuevos campos, no cambiemos estos identificadores que tenemos asignados ya que se podrían provocar inconsistencias en la generación de certificados de entidad final.
5 http://www.rediris.es/rid/oid/registered/
21
Para las denominaciones de los nuevos campos deberemos de modificar los ficheros
de literales que posee la herramienta, uno por cada idioma que soporta. Estos ficheros
se encuentran en la ruta ejbca-home\modules\admin-gui\resources\languages.
Los ficheros tienen una estructura de <código del literal> = <denominación en el
idioma que se trate>. En nuestro caso deberemos de editar el fichero
languagefile.es.properties (que es el que contiene los literales en castellano) e
incorporaremos las siguientes entradas:
DNTIPOCERTIFICADOINDENTIFIER = Tipo de usuario (Alumno, Profesor,
P.A.S.)
ESPECIALIDADINDENTIFIER = Especialidad
Para que los cambios tengan efecto deberemos de recompilar el módulo EJBCA y
realizar un nuevo despliegue. Para ello ejecutaremos desde el directorio EJBCA_HOME
el siguiente comando ant:
ant deploy
Además necesitaremos un reinicio del servidor de aplicaciones.
4.2.2 Añadiendo campos en el nombre alternativo del sujeto
Otra forma de incorporar campos personalizados a través de la herramienta es dentro del contenido del campo nombre alternativo del sujeto. Este campo a su vez está compuesto por otros campos predefinidos pero además podemos incorporar campos personalizados. Para ello deberemos de modificar los mismos ficheros de propiedades que en el caso anterior pero con otros valores.
Editaremos el profilemappings.properties con una entrada nueva por cada uno de nuestros nuevos campos con un formato parecido al caso anterior pero en esta ocasión deberemos de cambiar el prefijo de nuestra línea por el de ALTNAME. En resumen las dos nuevas entradas quedarían:
ALTNAME;2.16.840.1.113730.1.4;201;2.16.840.1.113730.1.4;201;Tipo
certificado; DNTIPOCERTIFICADOINDENTIFIER
ALTNAME;2.16.840.1.113730.1.6;202;2.16.840.1.113730.1.6;202;Especialid
ad;ESPECIALIDADINDENTIFIER
Como se puede observar, los identificadores de nuestros nuevos campos pueden ser
los mismos que en el caso anterior pero los identificadores internos de elementos
deben ser diferentes (en este caso son 201 y 202). Debemos ser especialmente
cuidadosos con estos identificadores para no provocar inconsistencia en los perfiles
finales y es recomendable asegurarse bien de los cambios que hagamos sobre los
ficheros antes de crear los perfiles de entidad final para no tener problemas.
22
4.2.3 Añadiendo extensiones básicas
Para incorporar extensiones personalizadas en nuestros certificados deberemos de modificar el fichero de propiedades ejbca_home\src\java\certextension.properties.
Cada extensión nueva está configurada con una serie de parámetros que define las propiedades de nuestra extensión. La descripción de estos parámetros es:
oid: El identificador único de nuestra extensión.
classpath: La ruta completa a la clase que va a encargarse de gestionar esta extensión. Como se trata de extensiones básicas su valor siempre será org.ejbca.core.model.ca.certextensions.BasicCertificateExtension.
displayname: El nombre que tendrá la extensión en la página de edición de perfiles de certificado.
used: Si la extensión se usará o si estará deshabilitada. Se usa true o false.
translatable: Si el display name se deberá traducir según el fichero de idiomas. Se usa true o false. Si indicamos true deberemos de incorporar las entradas correspondientes en el fichero de idiomas como anteriormente hemos visto.
critical: Para marcar la extensión como crítica (true) o no (false).
property.encoding: La codificación que se usará para el valor de la extensión.Siempre será DERUTF8STRING.
property.value: El valor estático que tendrá. Para nuestras dos extensiones tendremos que incorporar las siguientes entradas en el fichero de propiedades: id1.oid = 2.16.840.1.113730.1.3
id1.classpath=org.cesecore.certificates.certificate.certextensions.Bas
icCertificateExtension
id1.displayname=Tipo Certificado Alumno
id1.used=true
id1.translatable=true
id1.critical=false
id1.property.encoding=DERPRINTABLESTRING
id1.property.dynamic=true
id1.property.value=0101
id2.oid = 2.16.840.1.113730.1.2
id2.classpath=org.cesecore.certificates.certificate.certextensions.Bas
icCertificateExtension
id2.displayname=Especialidad
id2.used=true
id2.translatable=false
id2.critical=false
id2.property.encoding=DERPRINTABLESTRING
id2.property.dynamic=true
id2.property.value=0101
Después de estas modificaciones habrá que hacer un deploy nuevo de la herramienta.
23
En este trabajo se trata de realizar una implementación de una PKI mediante la
herramienta EJBCA pero también de conocer las opciones que permite la herramienta.
De ahí que estemos explorando todos los mecanismos de configuración personalizada
de nuestros perfiles de certificados.
Para nuestro caso concreto y teniendo en cuenta las tres opciones anteriormente
expuestas y buscando el mejor resultado final posible nos hemos decantado por la
opción primera, es decir, la de incorporar los nuevos campos como campos DN. Es en
la única de las opciones en las que el valor que toman nuestras nuevas propiedades
aparece sin estar codificado en base64. Además es sencillo asignar nuevos valores
durante la generación de los certificados y ese mecanismo ha sido el empleado para
incorporar campos como el NIF o CIF, exclusivos de los certificados de CA’s españolas y
que los perfiles por defecto que manejaba la herramienta EJBCA no tenían
incorporados.
4.3 Puesta en práctica
Para atender a las demandas de certificación que nos podemos encontrar dentro de la
universidad nos hemos planteado reproducir la jerarquía de certificados representada
en la figura 5.
Figura 5. Representación de nuestra jerarquía de certificados
Como se puede ver en la figura 5 vamos a tener una entidad certificadora raíz de la
que heredarán dos entidades intermedias en función de la naturaleza de nuestros
certificados y finalmente de estas dos colgarán nuestros certificados de entidad final.
4.3.1 Creación de perfiles de certificados
Como hemos comentado en puntos anteriores, para la generación de entidades
certificadoras previamente necesitamos perfiles de certificados en los que apoyarnos.
24
Para la creación de los perfiles necesitamos acceder a la sección de administración
(administration) del menú principal. Se solicita la identificación a través de certificado
del usuario administrador. Este certificado de administrador se ha generado durante la
instalación de la herramienta. En la ruta ejbca_home\p12\ tenemos el fichero
superadmin.p12 que contiene el certificado autorizado para acceder a la sección de
administración. Deberemos importarlo en el almacén de certificados de nuestro
navegador.
Una vez que hemos accedido a la sección de administración para la creación de
nuestros perfiles vamos a la sección Funciones de CA > Perfiles de certificados.
Nos aparece la relación de los perfiles que por defecto trae EJBCA y opciones para
importar y exportar perfiles. Como el objetivo es crear nuestros perfiles personalizados
partiendo de los genéricos, para la generación del certificado raíz de nuestra CA
pulsaremos el botón Clonar asociado al perfil ROOTCA. Al pulsar esta opción nos
pregunta qué nombre queremos darle a nuestro nuevo perfil. En este caso le daremos
UNIRIOJA ROOT CA.
Una vez lo tenemos “clonado” realizaremos la personalización. En el apéndice II se
pueden consultar todos los valores asignados en este perfil. La información a
personalizar está dividida en secciones.
Información general como el tipo de certificado, tamaño de la clave, período de
validez o el algoritmo de firma empleado.
Un segundo apartado que se llama Permisos. Se trata restringir la generación
de certificados usando un determinador perfil, con una serie de condiciones
como por ejemplo, que sólo se permita la creación de certificados con número
de serie único o con CN único.
El tercer apartado contiene las extensiones del estándar X.509v3. Aquí ya se
comienzan a configurar los campos que aparecerán o no en nuestro certificado así
como sus valores. Cabe destacar que en este punto se configura el propósito para el
que vamos a crear nuestro certificado. En el caso del certificado ROOT los usos de
clave serán firma digital, firma de clave de certificado y firma de CRL’s.
Dependiendo del tipo de certificado los usos también serán diferentes.
A continuación viene la sección con la información de distribución de las listas
de revocación y del servicio de OCSP. Es decir toda la información que
incorporaremos en nuestros certificados generados a partir de este perfil para
realizar posteriormente su consulta de revocación.
Después nos encontramos con las extensiones cualificadas de certificados. Se
trata de los campos definidos en la RFC 37396.
6http://www.ietf.org/rfc/rfc3739.txt?number=3739
25
Las últimas secciones sirven para relacionar nuestros perfiles de certificados
con nuestras entidades certificadoras. Con ello marcamos que un determinado
perfil se puede o no usar con una CA determinada. En nuestro caso
seleccionaremos cualquier CA para que nuestros perfiles sean transversales a
todas nuestras entidades de certificación creadas.
Siguiendo con nuestra jerarquía deberemos de definir dos nuevos perfiles de
certificados de entidad intermedias. Estos perfiles serán clones del perfil SUBCA que
para entidades intermedias nos proporciona la herramienta. Estos dos perfiles los
llamaremos UNIRIOJA PF SUBCA (para personas) y UNIRIOJA COMP SUBCA (para
certificados de componente) y serán clonaciones del genérico SUBCA.
Por último crearemos el perfil para usuarios finales. En este caso la clonación la
haremos del genérico ENDUSER.
Para los certificados de usuario final deberemos de indicar los propósitos de firma
digital, no repudio y cifrado de clave. Además podremos acotar tanto los campos que
formarán parte de nuestro nombre alternativo del sujeto como del DN. En este punto
incluiremos en los campos del DN los siguientes:
CN, nombre común.
SN, número de serie.
GN, nombre.
Apellido
O, organización
OU, unidad organizacional
NIF, número de identificación fiscal
Tipo de usuario, alumno, profesor o PAS.
Especialidad, facultad o unidad.
En cuanto a los campos que permitirá el nombre alternativo del sujeto
seleccionaremos únicamente Nombre RFC822 para incorporar el correo electrónico
asociado al usuario del certificado.
Indicaremos además que este perfil se puede emplear con cualquiera de las entidades
certificadoras que tengamos definidas.
26
4.3.2 Creación de entidades certificadoras
Para la creación de las entidades certificadoras deberemos de ir a la opción del menú
de administración Funciones de CA > Autoridades de certificación.
En esta opción aparece la lista de las CA’s creadas hasta el momento y permite la
creación de nuevas. Para ello tendremos que introducir el nombre de la entidad a
crear y pulsamos el botón de crear. Aparecerá la pantalla con toda la información para
crear una CA. La información también está dividida por secciones:
La primera sección contiene toda la información referente a las claves que va a
contener nuestro certificado.
La siguiente sección es la de directivas donde se indican características de
unicidad sobre el número de serie o el campo CN, así como información relativa
al almacenamiento de los certificados generados.
En la sección de datos del certificado de la CA se indica gran parte de la
información más relevante que aparecerá en nuestro certificado, la caducidad,
la organización, y sobre todo si va a ser un certificado autofirmado
(correspondiente a un certificado raíz) o va a estar firmada por otra clave
(entidades intermedias).
A continuación se especifica la información referente a las listas de revocación,
información sobre el servicio OCSP e información sobre las aprobaciones antes
de la emisión de certificados. Este punto se refiere a qué usuarios
administradores deben de validar las peticiones que se realizan de certificados
antes de su emisión. En caso de requerir aprobación previa a la generación del
certificado, el usuario debería de ir a una oficina de registro de certificados
para justificar su identidad. Una vez constatada su identidad, enseñando el DNI
por ejemplo, el administrador aprobaría esa petición. El usuario ya estaría en
disposición de obtener su certificado ya que su solicitud queda marcada como
válida. Este mecanismo, por ejemplo, es el empleado para la emisión de
certificados de la FNMT.
Para la generación del certificado raíz, en el campo Firmado por, deberá de indicarse
Autofirmada y en la lista de perfiles tendremos que seleccionar el generado para
nuestra CA (UNIRIOJA ROOT CA).
Para las entidades intermedias en el campo Firmado por deberemos seleccionar la CA
creada anteriormente. En el campo del perfil seleccionaremos nuestro perfil de
entidad intermedia correspondiente.
27
4.3.3 Creación de entidades finales
Además necesitamos crear un perfil de entidad final. Para ello iremos a la opción
Funciones RA > Perfiles de entidad final. Crearemos un perfil de entidad final por cada
tipo de certificado de usuario final.
En este perfil se pueden asignar valores por defecto a los campos seleccionados para el
DN y marcar el contenido de los campos como fijo o como modificable. En cada uno de
ellos asignaremos el valor correspondiente al campo Tipo de usuario y lo marcaremos
como no modificable. Así cuando vayamos a crear certificados de uno u otro tipo este
valor ya estará marcado como constante y no se podrá modificar.
Además en esta ventana en la sección de Otro dato existe un apartado de
Notificaciones. En este apartado se puede programar el envío de correos electrónicos
cuando se produzcan determinados cambios en el estado del certificado. Se puede
configurar desde el remitente que aparecerá en el mail de alerta, el contenido del
asunto, el cambio de estado que provocará el envío o el texto del cuerpo del mensaje,
con la posibilidad de cargarlo desde una plantilla predefinida.
Figura 6. Formulario del sistema de notificaciones en los perfiles de entidad final
El último paso para crear nuestros certificados será ir a la opción Funciones RA >
Agregar entidad final. En el formulario que aparecerá, lo primero que deberemos de
seleccionar es el perfil del certificado de entidad final del que queremos generar una
instancia. A continuación deberemos fijar un usuario y una contraseña, credenciales
que deberán de ser introducidas por el usuario final para obtener el certificado
generado. Después aparecerán todos los campos que han sido preseleccionados
durante la personalización de los perfiles de los certificados. En la figura 7 se puede ver
el aspecto del formulario de una generación de certificado de alumno:
28
Figura 7. Formulario para la creación de una entidad final
Como se puede ver, EJBCA maneja dos conceptos como son perfiles de certificados y
perfiles de entidad final. En los primeros se especifica información referente a las listas
de revocación, caducidad de certificado, etc. y en los perfiles de entidad final se
determina la información referente a qué campos del DN y del nombre alternativo del
sujeto (subject alternative name) van a incorporarse en el certificado así como sus
valores por defecto y si éstos campos van a ser o no modificables durante la
generación del certificado.
4.3.4 Generación del certificado
Una vez tenemos creada nuestra entidad final deberemos obtener el certificado. En el
perfil de entidad final se puede especificar el formato de exportación. Puede ser en
fichero o directamente el certificado se incorporará en el almacén de certificados del
navegador desde el que se está solicitando el certificado.
29
En nuestro caso además no hemos marcado la opción de aprobación por lo que el
usuario podrá obtener el certificado inmediatamente después de su creación sin
necesidad de que el administrador apruebe la petición.
Figura 8. Protocolo de una solicitud de un certificado
Para obtener el certificado, el usuario accede mediante el navegador a la URL donde
está instalado EJBCA. Aparecerá el menú de la parte pública de nuestra PKI. Abrir la
opción Enroll > Create browse certificate. Se accede a un formulario para introducir el
usuario y la contraseña dados de alta por el administrador en el momento de la
creación de la entidad final. En el siguiente paso se produce la exportación definitifva
del certificado en el formato prefijado durante su creación.
Esta exportación sólo se podrá realizar una sóla vez. Es decir, el proceso anteriormente
indicado es único. Se trata de una medida de seguridad para que no se puedan generar
réplicas de los certificados que se van emitiendo.
4.4. Discusión y posibles mejoras
Los dos puntos de trabajo más importantes desarrollados en este apartado han sido
por un lado la composición y generación de los certificados necesarios para replicar la
jerarquía modelo que nos hemos marcado y por otro lado todo el trabajo explorando
las opciones de incorporación de campos personalizados dentro de los certificados de
entidad final.
30
La decisión tomada para incorporar estos campos ha sido una solución de
compromiso. El esfuerzo inicial se basó en intentar incorporar estos campos con sus
OID’s como campos dentro del nombre alternativo del sujeto (Subject Alternative
Name). Este modelo es el empleado por entidades certificadoras como CAMERFIRMA o
la FNMT para incorporar esos campos en su certificados.
Tras darme de alta en los foros de soporte y desarrolladores y plantear cómo realizar
esto, se me indicó que actualmente esta solución está pendiente de implementar. Es
decir, en el formulario para la configuración de los campos del nombre alternativo del
sujeto, no está incorporar un OID personalizado. Investigando el código fuente de la
herramienta, pude observar como el apartado referente a incorporar el OID en el
subject alternative name no estaba implementado por el momento pero sí parece que
se contemplaba como una opción a futuro.
Como conclusión, en el día de la realización de este estudio las opciones de
personalización son las expuestas anteriormente. En la hoja de ruta de EJBCA está
contemplado la incorporar campos OID’s personalizados asociados con textos no
encriptados en base64, que permitirán completar la información que por defecto
proporcionan los perfiles incluidos en EJBCA.
Además, y analizando la evolución de la herramienta he podido observar que en
versiones anteriores, los datos de NIF y CIF no estaban por defecto incorporados
dentro del núcleo de EJBCA. A requerimiento de empleados de ACCV (la PKI de la
comunidad valencia) que están empleando en producción EJBCA como solución para
su PKI se realizaron las moficaciones correspondientes y finalmente estos dos campos
de NIF y CIF aparecen por defecto dentro de EJBCA en las últimas versiones.
Miembros de ACCV se han incorporado dentro del grupo de desarrolladores de EJBCA
para proponer esta modificación adjuntando las modificaciones en el código
necesarias y finalmente los gestores de la plataforma introdujeron este cambio.
Esta es una gran ventaja de cómo funciona EJBCA de cara a pensar que si en un caso
determinado se transmite una necesidad particular pero que puede ser útil para un
gran número de usuarios potenciales desde la plataforma de desarrollo de la
herramienta están totalmente abiertos a incorporar estas necesidades siempre, claro
está, que esté debidamente justificada.
Esto transmite que estamos tratando con una solución en contínua evolución
soportada por una comunidad de desarrolladores activa.
31
5. Validaciones
Se ha desarrollado un API JAVA para poder facilitar la integración de aplicaciones que
tengan necesidades de certificación. Además y como ejemplo de integración de este
API se ha desarrollado un validador de certificados, herramienta incorporada dentro
de EJBCA como una opción más y que utiliza muchas de las funciones incluidas dentro
de este API.
Por un lado nuestro validador podría ser un modelo para conocer cómo incorporar
funciones de manejo de certificados dentro de aplicaciones web y por otro se trata de
una aplicación que complementa el actual funcionamiento de EJBCA.
5.1 Análisis
Las necesidades de desarrollo están basadas fundamentalmente en poder recuperar
toda la información, que nuestros certificados contienen, de una forma sencilla para su
uso dentro de aplicaciones futuras. También deben existir métodos de validación de
nuestros certificados.
Una vez desarrollada el API, la aplicación de validación de certificados, incorporará
mecanismos para seleccionar el certificado a validar y una página de resultados con el
estado y la información que contiene el certificado seleccionado. La selección del
certificado se podrá realizar a través de dos métodos:
Seleccionando un certificado de los instalados en el navegador que está
ejecutando el validador
Seleccionando un fichero de exportación de un certificado (extensiones .p12 o
pfx).
Se trata de un mecanismo para poder conocer qué información contiene nuestro
certificado y su estado. Finalmente este validador será llamado desde las opciones de
EJBCA en su interfaz público para que todos los usuarios puedan, en cualquier
momento, verificar el estado y conocer la información de su certificado.
32
Figura 9. Casos de uso para la aplicación de validación
La lógica de negocio de la aplicación validadora se ha basado casi en su totalidad en las
funciones propias del API. Pero para permitir su integración en otros sistemas hemos
dividido el desarrollo en dos proyectos, uno web con la interfaz para la selección de
certificados y otro con las clases propias del API. De este modo, este API se podrá
empaquetar en modo librería JAVA generando un fichero .jar (Java ARchive).
Vamos a centrarnos en el análisis del API.
En cuanto a la organización de las clases hemos establecido un esqueleto (interface)
para nuestras clases de validación que deberán implementar los métodos que
determinan si nuestro certificado es válido o no:
isCertificadoValido() throws CertificadoValidadorException;
isCertificadoCaducado() throws CertificadoValidadorException;
isCertificadoRevocado() throws CertificadoValidadorException;
getCertificadoRevocadoInfo () throws CertificadoValidadorException;
Para este estudio sólo se ha implementado la validación mediante el servicio OCSP,
pero se podría implementar otros mecanismos de validación como por ejemplo uso de
CRL’s (Certificate Revocation List) o llamadas a servicios web.
Para ello sólo sería necesario que nuestra nueva implementación integrara los
métodos anteriores.
Para la parte de desarrollo de clases de validación se ha empleado el patrón Bridge con
el fin de facilitar la implementación de otros validadores.
33
Figura 10. Esquema UML de las clases del módulo de validación OCSP
5.2 Diseño
Para incorporar un nuevo método de validación tendríamos que crear una nueva rama,
semejante a la rama OCSP representada en la figura 10, pero implementando el nuevo
sistema de validación e integrándolo en nuestra factoría.
Además se han incorporado utilidades para el manejo de certificados desde JAVA. Esto
ayudará a la puesta en marcha de futuras aplicaciones web que quieran usar
certificados como método de identificación. Estas utilidades también han sido usadas
para nuestra aplicación de validación.
La clase de utilidades es es.unirioja.tfg.edmartt.CertUtils .
La mayor parte de las funciones podrían servir para certificados emitidos por cualquier
entidad certificadora, como son las funciones de conversión de formatos, de acceso a
34
ficheros de certificados o al análisis de los valores de las diferentes extensiones que un
certificado X509 V3 contiene.
Figura 11. Representación de la clase de utilidades es.unirioja.tfg.edmartt.CertUtils
5.3 Implementación
Como ejemplo de implementación hemos desarrollado una mini-aplicación web que
dispone de dos mecanismos de selección de certificados.
Para acceder a estas opciones se ha personalizado las opciones del menú de la parte
pública de EJBCA (la forma cómo se ha realizado esta personalización se describirá en
el siguiente capítulo). De esta forma podremos llamar a una u otra opción como si se
tratara de un elemento propio de nuestra PKI.
35
Figura 12. Aspecto del menú modificado con las nuevas opciones
5.3.1 Certificado instalado en el navegador
Si pulsamos sobre la primera de las opciones (Validador > Certificados del navegador)
se realiza una solicitud de autenticación mediante certificado, por parte del servidor
para un sitio https. Con este mecanismo forzamos a que el navegador muestre su
pantalla de selección de certificados admitidos.
Una vez seleccionado e introducida la contraseña correspondiente, este certificado se
envía al servidor (la parte pública).
Para que el navegador nos proponga para seleccionar certificados de nuestra PKI, es
necesario que incorporemos la clave pública de nuestra CA al almacén de certificados
de confianza de nuestro servidor
(JBOSS_HOME\standalone\configuration\keystore\truststore.jks). Es el servidor el que
le indica al navegador qué certificados puede o no puede permitir seleccionar.
Con esto indicamos al servidor que los certificados emitidos por nuestra PKI son “de
confianza”.
36
Figura 13. Ventana de selección de certificado del navegador solicitada por el servidor
Una vez seleccionado nuestro certificado e introducida la contraseña con la que está
protegido pulsaremos “Aceptar” y aparecerán los datos extraídos y su estado.
Figura 14. Pantalla de resultados de la validación
Como se puede ver en la figura 14 el diagnóstico es “certificado válido”. Para
determinar este estado se ha realizado la validación de caducidad y la de revocación.
Nos hemos conectado por medio de las clases de nuestra API al servidor OCSP de
nuestra PKI y tras la consulta el estado ha sido de OK.
37
5.3.2 Certificado exportado en un fichero
El segundo método consiste en la selección de un fichero de exportación de un
certificado, que tengamos dentro de nuestro sistema de archivos de nuestro
ordenador. Este fichero puede tener extensión .pfx (Personal inFormation eXchange) si se
ha exportado desde Internet Explorer o extensión .p12 (PKCS12, estándar de sintaxis de
intercambio de información personal) si se ha exportado desde Firefox .
La opción a seleccionar desde el menú público es Validación > Certificados en fichero.
Una vez seleccionada esta opción nos aparece la figura 15 que contiene, entre otros
elementos, un selector de ficheros.
Seleccionaremos el fichero que contiene nuestra clave privada y posteriormente
deberemos de introducir la contraseña de respaldo con el que se ha creado esta copia.
Este dato es imprescindible para poder cargar el certificado en un almacén de claves
para su posterior manejo. Todas las funciones de gestión de certificados desde un
fichero se han incorporado dentro del API.
Figura 15. Pantalla de selección de un certificado contenido en un fichero
La pantalla de resultados es la misma se haya seleccionado el certificado del primer
modo o del segundo.
5.3.3 Cambios para las llamadas al validador
Para incorporar la funcionalidad del validador de certificados como si se tratara de un
elemento integrado dentro de EJBCA se ha tenido que modificar los menús de la parte
pública.
38
Los ficheros que se han modificado han sido:
ejbca_home\modules\publicweb-gui\resources\enrol\header.jsp
ejbca_home\modules\publicweb-gui\resources\inspect\header.jsp
ejbca_home\modules\publicweb-gui\resources\retrieve\header.jsp
ejbca_home\modules\publicweb-gui\resources\templates\header.jsp
En todas estas jsp’s he incorporado las dos llamadas a los métodos de validación que
hemos incorporado. Con estas modificaciones parecen dos opciones por defecto de
EJBCA.
<li>
<div class="menuheader">Validador</div>
<ul>
<li>
<a href="../enrol/validador_nav.html">Certificados del navegador</a>
</li>
<li>
<a href="../enrol/validador_file.html">Certificados en fichero</a>
</li>
</ul>
</li>
Las llamadas desde el menú invocan a páginas que son las que finalmente hacen la
llamada a cada uno de los mecanismos de incorporar certificados para su posterior
validación. Esas dos páginas las he incorporado en uno de los directorios de la parte
pública de EJBCA. Para conseguir una integración esas páginas realizarán la llamada a
través de un <iframe> por lo que nuestro validador queda completamente embebido
en el entorno de EJBCA.
La página con los resultados de la validación así como la página de selección de fichero
de certificados tienen los estilos de EJBCA. Hemos importado la hoja de estilos dentro
de nuestro proyecto web. El resultado se ha podido ver en las figuras 13, 14 y 15.
5.4 Pruebas y posibles mejoras
Durante el proceso de pruebas he empleado certificados caducados, revocados y
revocados con un motivo determinado. Para modificar el estado de revocación de los
certificados deberé acceder a las funciones de RA (Registration Authority) dentro del
menú de administrdor de EJBCA (Funciones de RA > Listar entidades finales). Una vez
dentro de esta opción tenemos una serie de filtros que podemos aplicar previamente a
la obtención de la relación de todos los certificados emitidos.
39
En la figura16 se pude ver la forma de presentación de unos cuantos certificados
emitidos durante el proceso de pruebas.
Figura 16. Vista de la relación de certificados emitidos y sus opciones
De todos los certificados, seleccionamos el o los que queremos revocar (marcando el
checkbox de la primera columna) y asignamos un motivo de por qué revocamos estos
certificados. Este motivo podrá ser recuperado en el proceso de validación.
Figura 17. Pantalla de validación de un certificado revocado por clave comprometida
En la figura 17 se puede ver la salida de nuestro validador ante un certificado
revocado. Se indica el motivo y el momento en el que se realizó la revocación.
Como he indicado anteriormente la pantalla de salida con los datos del certificado y su
estado es común ya se seleccione el certificado por uno u otro método.
40
Existe una limitación cuando se emplea la identificación mediante solicitud por parte
del servidor del certificado a validar ya que esta información, el certificado
seleccionado, se almacena en la sesión del navegador y sólo puede haber una
identificación por sesión. Mientras no cerremos el navegador estará vigente el
certificado que hemos seleccionado y sólo cerrando el navegador podríamos validar
otro distinto al anterior. Para resolver este problema se podría integrar un selector de
certificados del navegador basado, por ejemplo, en un applet. Consideramos que no es
parte de este estudio integrarnos con componentes de firma externos ya que no iba a
aportar nada extra al conocimiento de la herramienta EJBCA.
Por otro lado, tenemos la opción de validación desde soporte software (fichero) que
podemos emplear todas las veces que queramos sin necesidad de cerrar el navegador.
41
6. Gestión del proyecto
Durante el desarrollo de este trabajo nos hemos encontrado con diferentes
circunstancias que han evitado que llegáramos a ejecutar una pequeña parte de los
objetivos marcados en el apartado 2.6 de este trabajo. Fundamentalmente han sido las
siguientes:
En primer lugar abordamos el apartado referente a la virtualización en
entornos LINUX y WINDOWS. No se ha completado este hito porque se trata de
una aplicación basada en Enterprise Java Beans (EJB), es decir, al estar
desarrollado en JAVA, un lenguaje multiplataforma, vimos que iba a ser un
esfuerzo que no iba a aportar nada nuevo a lo expresado en este trabajo en la
parte de instalación y despliegue de nuestro prototipo.
Además ya existen entornos virtualizados7 de esta herramienta para su
descarga con el fin de hacer pruebas. Así que este asunto ya estaba resuelto
también por la comunidad de desarrolladores.
En segundo lugar nos encontramos con la tarea Gestión de alertas dentro de la
PKI.
Una vez que conseguimos desplegar nuestro prototipo y comenzamos a realizar
las diferentes tareas se observó que la propia herramienta dispone ya de un
sistema de alertas. En la definición de los perfiles entidades finales (sección
4.3.3 de este estudio) se muestra el sistema de notificaciones integrado en
EJBCA.
Esta funcionalidad cubría perfectamente las necesidades que nos habíamos
marcado inicialmente para el aviso temprano de fechas de caducidad o
notificaciones de cambios en el estado de un certificado al usuario. Este es el
motivo por el que no hemos desarrollado esta tarea.
Además, durante el desarrollo del proyecto se produjo un problema con la base de
datos que usa EJBCA y se perdió parte de la información guardada. No se disponía de
copia de seguridad completa del contenido de esa base de datos, pero, a través de las
copias de respaldo de los perfiles de certificados, se consiguió restaurar por completo
la jerarquía de certificados y el resto de información.
Pese a estas incidencias, hemos conseguido cumplir con los plazos previstos en el DOP, de modo global. En cuanto a la dedicación a cada una de las tareas, se puede decir que la mayor parte de ellas estaban adecuadamente dimensionadas en el tiempo. Sólo la
7 http://www.ejbca.org/download.html#Virtual%20Machine%20for%20Testing
42
parte de definición de los perfiles de certificados (con la inclusión de nuevos campos) y la integración del validador dentro de EJBCA, han superado la estimación inicial. Este tiempo extra ha sido compensado con los tiempos reservados para los apartados no realizados. Ambas desviaciones se han producido por no tener un conocimiento profundo de la herramienta al inicio de este trabajo. Como ya se indica en el DOP, eran previsibles estos desvíos, porque parte de las tareas ejecutadas han sido labores de investigación. Además, hay que tener en cuenta el tiempo que se ha necesitado para restaurar la definición de los perfiles, tras la pérdida accidental de información de la base de datos comentada anteriormente.
Con todo esto podemos concluir que la estimación inicial ha sido adecuada dada la naturaleza de nuestro estudio y de los problemas que han surgido.
Para el seguimiento del trabajo se han realizado tres reuniones (adjunto las actas en el
apéndice III) para hacer un seguimiento del proyecto, para poner en común los hitos
alcanzados o para ir dirigiendo los siguientes pasos en la elaboración de este estudio.
Además se ha empleado el grupo de FACEBOOK urGradoInformaticaTFG para ir
consultando las publicaciones de los tutores y de cómo conseguir realizar un buen TFG.
El principal medio de comunicación con mi tutor ha sido el correo electrónico. A lo
largo de la realización de este estudio nos hemos intercambiado más de 50 correos.
Primero para determinar el alcance de este trabajo. Posteriormente para realizar
seguimiento de los hitos que se iban consiguiendo. Por último, cómo organizar la
memoria final, los apartados a tratar, etc.
También ha servido para el intercambio de contenidos y para todo el proceso de
revisión de la memoria.
43
7. Conclusiones
Una vez realizado los trabajos expuestos, es el momento de hacer una reflexión sobre
los problemas encontrados a lo largo de este estudio.
También vamos a analizar qué feed-back hemos recibido tras el desarrollo de este
estudio y marcar una línea de trabajo en la que el germen haya sido este proyecto.
7.1 Problemas más importantes encontrados
Fundamentalmente los principales problemas surgieron durante la definición de los
perfiles de certificados.
Inicialmente nos habíamos marcado como referencia el perfil de certificado emitido
por la FNMT. En estos certificados se incorporan campos particulares dentro del
Nombre alternativo del sujeto en forma de OID’s.
EJBCA de momento no tiene implementado este sistema. Tuvimos que darnos de alta
dentro de la comunidad de desarrolladores para acceder a las listas de soporte a
usuarios y poder plantear nuestra necesidad. Tras introducir mi pregunta en varios
foros conseguí la contestación del administrador de la plataforma.
La solución para conseguir replicar los perfiles de la FNMT sería modificar la
programación de EJBCA en la clase encargada de generar la entidad final (clase
CerTools). En la figura 18 se muestra la contestación del administrador de EJBCA.
Figura 18. Hilo sobre cómo incorporar OID en el Subject alternative name
44
Una vez conocida esta limitación nos marcamos otras alternativas para modificar los
perfiles por defecto que ya se han explicado en esta memoria.
Otro problema surgió durante la generación de certificados de entidad final. Nuestros
campos personalizados los hemos incorporado dentro del DN de nuestro certificado.
El contenido del DN se guarda en una única columna en varias tablas de la base de
datos de EJBCA. Al incrementar el tamaño de la información a persistir, en ocasiones, y
dependiendo de los datos introducidos durante la generación (nombre y apellidos más
largos), se generaba un error (Value too large for column USERDATA.SUBJECTALTNAME) por
tamaño de campo insuficiente.
La solución fue incrementar el tamaño de una serie de campos donde se almacena esa
información a través de las siguientes instrucciones SQL:
alter table CertificateData modify subjectDN varchar(2048);
alter table UserData modify subjectDN varchar(2048);
alter table UserData modify subjectAltName varchar(2048);
7.2 Conocimientos adquiridos
Durante el desarrollo de este estudio he comprendido desde dentro el mecanismo
para la generación de certificados. Hasta la fecha y por mi experiencia profesional
había trabajo con certificados como un elemento generado y que era un componente
más dentro del desarrollo de aplicaciones. Con la realización de este trabajo he
conocido todo el proceso previo hasta conseguir un certificado.
Además durante el desarrollo del API he podido profundizar en la estructura interna de
los certificados digitales y cómo tienen dispuesta la información para poder extraerla.
Qué campos contienen la información personal y cómo podemos acceder a esta
información para ponerla a disposición de las aplicaciones.
Por otro lado me he introducido en el manejo de otro servidor de aplicaciones de
código abierto (hasta ahora sólo había trabajado con JRUN, TOMCAT y GLASSFISH)
como es JBOSS. Además he adquirido algunas nociones básicas de administración
como el manejo de la consola para despliegues, la creación de un conector https para
el acceso de aplicaciones mediante protocolo seguro, el registro de un driver de base
de datos o la configuración usando la interfaz de línea de comandos.
7.3 Trabajo futuro
La labor fundamental de aquí en adelante trataría de transformar este prototipo en
una solución para producción. Ya se han marcado algunas pautas durante este estudio
de cómo se podría realizar esta evolución.
45
Una vez que tengamos una plataforma sólida en producción el siguiente paso sería
extender el uso de estos certificados primeramente de forma interna entre los
trabajadores de la universidad para las tareas administrativas internas.
Otra forma de extender el uso de certificados podría ser incorporarlos dentro del
carnet de estudiante. Además de ser una tarjeta monedero quizás se podría emplear
como una tarjeta inteligente (Smart card) donde podríamos grabar a cada alumno un
certificado durante la emisión del mismo. Mientras el alumno esté matriculado en la
universidad podría disponer de uno de estos certificados como identidad digital válida.
Este podría ser el germen para intentar alcanzar el hito de “papel cero” en las tareas
administrativas en la universidad.
46
8. Bibliografía:
Documentación de referencia de EJBCA.
- http://www.ejbca.org/docs/index.html
Listas de correos de la comunidad de desarrolladores de EJBCA.
- http://sourceforge.net/p/ejbca/mailman/
Registro y consulta de OID’s
- http://www.rediris.es/rid/oid/registered.html/
Consulta OCSP
- http://www.programcreek.com/java-api-
examples/index.php?api=org.bouncycastle.ocsp.OCSPResp
- https://svn.cesecore.eu/svn/ejbca/branches/Branch_3_4_pr1/ejbca/doc/h
owto/HOWTO-OCSP-RESPONDER.txt
47
9. Apéndice I – Instalación
9.1 Modificación de la JVM (Java Virtual Machine) para que
pueda manejar claves de gran tamaño
Cuando se realiza una instalación de una JVM por defecto, presenta limitaciones para
realizar operaciones criptográficas que requieren el uso de claves de gran tamaño.
Para resolver esta limitación debemos de modificar la política de seguridad por
defecto, realizando las siguientes tareas:
En primer lugar deberemos descargar8 la extensión criptográfica de JAVA que
modifica las políticas de seguridad. Esta extensión está compuesta por dos
ficheros .jar (local_policy.jar y US_export_policy.jar) La descarga se hace a
través de un fichero .zip que contiene los dos ficheros mencionados.
Copiar los nuevos ficheros .jar en el directorio JAVA_HOME\lib\security\ de la
instalación que queramos modificar. Sobrescribir en la copia, ya que esos
ficheros ya existen previamente en esa ubicación.
Reiniciar el servidor de aplicaciones para que el cambio tenga efecto.
9.2 Creación de un usuario administrador para acceso a la
interfaz web de JBOSS
C:\jboss\bin>add-user
What type of user do you wish to add?
a) Management User (mgmt-users.properties)
b) Application User (application-users.properties)
(a): a
Enter the details of the new user to add.
Realm (ManagementRealm) : usuario
Username : usuario
Password :
Re-enter Password :
About to add user 'usuario' for realm 'usuario'
8 http://www.oracle.com/technetwork/es/java/javase/downloads/jce-7-download-432124.html
48
Is this correct yes/no? yes
Added user 'usuario' to file 'C:\jboss\standalone\configuration\mgmt-
users.properties'
Added user 'usuario' to file 'C:\jboss\domain\configuration\mgmt-
users.properties'
9.3 Instrucciones ejecutadas a través de la interfaz cliente de
JBOSS para modificar la configuración por defecto
Arrancar la interfaz cliente:
Jboss/bin/jboss-cli.bat
Conectarse a la interfaz cliente:
connect
Configuración de los logs en modo depuración (DEBUG) y conocer los posibles
problemas que puedan aparecer durante los despliegues de aplicaciones:
/system-property=org.jboss.as.logging.per-deployment:add(value=false)
/subsystem=logging/logger=org.ejbca:add
/subsystem=logging/logger=org.ejbca:write-attribute(name=level,
value=DEBUG)
/subsystem=logging/logger=org.cesecore:add
/subsystem=logging/logger=org.cesecore:write-attribute(name=level,
value=DEBUG)
Instrucciones para poder incorporar caracteres internacionales en las listas de
revocación publicadas:
/system-
property=org.apache.catalina.connector.URI_ENCODING:add(value=UTF-8)
/system-
property=org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STR
ING:add(value=true)
49
10. Apéndice II – Perfil UNIRIOJA ROOT CA
A continuación se muestran varias capturas sobre las opciones definidas en el perfil de
certificado UNIRIOJA ROOT CA. Se ha realizado esta presentación en detalle de este
perfil por tratarse del certificado raíz de nuestra CA.
Figura 19. Cabecera de definición del perfil de certificado UNIRIOJA ROOT CA
Figura 20. Permisos asignados durante la generación de certificados
Figura 21. Definición de extensiones
50
Figura 22. Información de revocación
Figura 23. Información adicional de definición del perfil
51
11. Apéndice III – Actas de reuniones
Primera reunión
Fecha: 04 de Febrero de 2015
Hora: 11:30 (duración 30 minutos)
Asistentes: Eduardo Martínez Tobías y Julio Jesús Rubio García
Lugar: Despacho de Julio
Tema: Inicio del trabajo fin de grado de “certificados digitales en un entorno
educativo”.
Se habla sobre la necesidad de comenzar el estudio. Para determinar el alcance del
trabajo se plantea la redacción del Documento de Objetivos del Proyecto como punto
de partida.
Se entrega documentación de consulta para conocer cómo realizar un DOP, qué partes
tiene y donde aparecen ejemplos de partes de un DOP.
Se establece como medio de comunicación el correo electrónico.
Se acuerda un plazo de diez días para tener el DOP y para su posterior revisión por el
tutor.
52
Segunda reunión
Fecha: 31 de Marzo de 2015
Hora: 12:30 (duración 1 hora)
Asistentes: Eduardo Martínez Tobías y Julio Jesús Rubio García
Lugar: Despacho de Julio
Tema: Puesta en común sobre lo realizado hasta la fecha. Tomar decisiones sobre qué método
usar para incorporar meta información en el certificado. Determinar si la jerarquía y perfiles
creados hasta el momento son suficientes. Algunas conclusiones sobre la presentación de la
herramienta.
Para la presentación de la herramienta, si no requiere mucho esfuerzo, dar un estilo UNIRIOJA
al banner y entorno.
Después de valorar los tres métodos disponibles en la herramienta (dentro del CN, en el
subject alternative name o como una extensión) se toma la decisión de que vaya en el CN los
campos de tipo y especialidad, por flexibilidad y claridad. El resto de métodos se valoran que
se hayan investigado y se incluirán en la memoria y quizás los empleemos de alguna forma
para darle valor al trabajo realizado.
En cuanto a la jerarquía definiremos otra SUBCA para generar certificados de tipo
componente.
Se valora como otro valor extra la creación de un servidor de marca de hora con un certificado
generado por nuestra PKI, firmar un PDF con nuestros certificados.
Para continuar con el desarrollo del TFG se plantea el desarrollo del API que contendrá de
momento:
- La llamada al OCSP
- Obtener toda la información contenida dentro del certificado además de los datos
alternativos y pasarlos a la aplicación
Después se empleará este API en el validador de certificados al estilo del validador del
Gobierno de La Rioja9.
9 http://www.larioja.org/firma
53
Tercera reunión
Fecha: 28 de Abril de 2015
Hora: 18:00 (duración 1 hora)
Asistentes: Eduardo Martínez Tobías y Julio Jesús Rubio García
Lugar: Despacho de Julio
Tema: Comentar el problema de pérdida de perfiles de certificados y puesta en común del
desarrollo del API.
Se toma como decisión intentar replicar exactamente el perfil de entidad final para ver si así
podríamos reproducir la jerarquía de certificados perdida partiendo de los perfiles de los que
tenemos copia de seguridad.
Se muestra API con la lógica de funciones y objetivo de su desarrollo. Además se comenta las
opciones que podría tener el validador y el medio para poder obtener los certificados para
analizar.
Se acota las formas de incorporar los certificados al validador mediante un selector de ficheros
y mediante la selección de los certificados incorporados en el navegador por medio de petición
de identificación por servidor.
También se acota las funcionalidades del API y se acuerda como siguiente paso cerrar ya el
validador y toda la parte de desarrollo para comenzar la redacción de la memoria. Se presume
que puede ser una tarea compleja por la naturaleza de este estudio.