Documento de control de versiones para políticas de validación v5

Transcripción

1 Versión: 1.21 Fecha: 18/09/2014

2 HOJA DE CONTROL Título Entregable Nombre del Fichero Autor Documentación Politica v21 DGPD Versión/Edición 1.21 Fecha Versión 18/09/2014 Aprobado por José Ignacio Cortés Santos Fecha Aprobación 18/09/2014 Nº Total Páginas 11 REGISTRO DE CAMBIOS Versión Causa del Responsable del Área Fecha del 1.0 Primera versión del documento Versión /12/ Versión ) 1.2 Versión ) 1.3 Versión ) 17/12/ /02/ /05/ Versión ) Versión ) 23/10/ Versión ) 17/11/2009 Página 2 de 11

3 Versión Causa del Responsable del Área Fecha del Versión ) 1.6 Versión ) Versión ) 10/12/ Versión ) Versión ) 28/01/2010 Versión ) 1.8 Versión ) Se reestructuran los apartados del documento 19/03/ Versión ) Versión ) 04/05/ Versión ) Versión ) 18/10/2010 Versión ) 1.11 Versión ) Versión ) Se actualiza el formato del documento a formato monocromo 25/01/ Versión (@firma 5.0.1) Versión (@firma 5.2.1) Versión (@firma 5.3.1) 23/03/2011 Actualización de confianza OCSP 1.13 Versión (@firma 5.0.1) Versión (@firma 5.2.1) 04/04/2011 Versión (@firma 5.3.1) Página 3 de 11

4 Versión Causa del Responsable del Área Fecha del Actualización de confianza OCSP Admisión de certificados para personas Físicas emitidos por las CA ACCV y ANF 1.14 Actualización almacén de confianza CRL Admisión de Certificados de sello de tiempo la FNMT Pablo Pizarro Armendáriz 28/03/2012 Versión (@firma 5.0.1) Versión (@firma 5.2.1) Versión (@firma 5.3.1) Modificaciones realizadas en prestador CAMERFIRMA Modificaciones realizadas en prestador ANCERT. Modificaciones realizadas en prestador ABOGACÍA. Pablo Pizarro Armendáriz 07/05/2012 Versión (@firma 5.2.1) Versión (@firma 5.3.1) 1.16 Inclusión de método de validación OCSP para FNMT AP. Versión (@firma 5.2.1) Pablo Pizarro Armendáriz 04/07/2012 Versión (@firma 5.3.1) 1.17 Inclusión certificados para la validación de respuesta OCSP de ANF. Versión (@firma 5.2.1) Pablo Pizarro Armendáriz 14/03/2013 Versión (@firma 5.3.1) 1.18 Modificaciones realizadas en prestador CAMERFIRMA. Versión (@firma 5.2.1) Ernesto Salgado Suárez 05/06/2013 Página 4 de 11

5 Versión Causa del Responsable del Área Fecha del Versión ) Versión ) Inclusión de certificado de TSA 1.19 Versión ) Versión ) Alejandro Román Márquez 02/01/2014 Versión ) Modificación mapeo DNIe (5.0.20) 1.20 Actualizada subca de ANCERT Inclusión de jerarquía ANF Versión ) Alejandro Román Márquez 03/02/2014 Versión ) Versión ) 1.21 Inclusión de certificado FNMT SSL estándar PJ Versión ) Versión ) Ernesto Salgado Suárez 18/09/2014 Versión ) Página 5 de 11

6 ÍNDICE 1. Introducción Proceso de importación Copia de seguridad Importar archivo Versión v Solución de errores de importación Errores de importación detectados en Validación del certificado de firma del Notario Electrónico Mantenimiento de pares de claves y certificados...11 Página 6 de 11

7 1. Introducción Este documento ha sido elaborado para determinar que versión y que cambios se producen en las políticas exportadas desde la plataforma de la Junta de Andalucía. La exportación de las políticas se realiza desde los nodos de producción con URL correspondiente a la versión 5.5 con extensión de compatibilidad Las políticas exportadas tienen carácter acumulativo, lo que significa que importando la última política tendremos actualizada la plataforma completamente, incluyendo los cambios de versiones anteriores. Esto hace que sea muy importante seguir los pasos descritos en el manual para la versión que se está importando, ya que puede ser necesario configurar algunos aspectos manualmente. A partir de la fecha 05/06/2013, se incluye en la distribución de políticas exportadas los archivos necesarios para realizar la importación en plataformas 5.2.1, y 5.5. El archivo de importación para la versión se numera con 3.x.x, para la versión con 2.x.x. y para la versión 5.5 con 5.x.x. Es necesario tener en cuenta que en las versiones y de debe configurar el método de validación CRL_NOTARIO_JA según el apartado Proceso de importación 2.1. Copia de seguridad Antes de realizar el proceso de importación de la política de certificación, la plataforma guarda una copia de seguridad de los almacenes, keystores y la configuración dentro de la ruta $JBOSS_HOME/server/all/conf con archivos renombrados con la fecha y hora de importación: ArchivoCopiaSeguridad.vx.xxx.fDDMMYY-HHMMSS.backup En el caso de producirse un error de importación será necesario restaurar los archivos de backup descritos y reiniciar la plataforma Importar archivo Lo primero en el proceso de importación es seguir los pasos descritos en el apartado correspondiente de la versión importada, pues para que una versión concreta sea importada con éxito puede ser necesario configurar algo manualmente. Posteriormente, para realizar el proceso de importación debemos abrir la consola de administración de la plataforma en la sección de Importación/Exportación de políticas de certificación. Desde Página 7 de 11

8 esta pantalla debemos importar la política seleccionando el archivo configuracionafirma5_vxxx.xml correspondiente, y marcando la casilla Sobrescribir la configuración ya existente. Una vez finalizado el proceso de importación aparecerá una pantalla que nos informará que se ha realizado correctamente y una lista de los cambios realizados. Página 8 de 11

9 3. Versión v21 A continuación se detallan las diferencias aportadas por la versión 21 de la política respecto a la política anterior, versión 20: Inclusión del nuevo tipo de certificado FNMT SSL estándar PJ. Una vez importada la política se debe comprobar que el tipo de certificado raiz FNMT-RCM tiene habilitado el método de validación CRL_FNMT_APE_ROOT en el apartado Métodos de validación del PSC que incluye Gestión de Políticas. 4. Solución de errores de importación Se incluye en la distribución de esta política el AlmacenPSCs.jks, el AlmacenTiposCertificados.jks, el AlmacenConfianzaCRL.jks y el AlmacenConfianzaOCSP.jks, correspondientes a la última política exportada. En el caso de producirse alguno de los siguientes errores reconocidos se podrá hacer uso de estos archivos para configurar correctamente los servidores. Para que los cambios surtan efecto deben copiarse a la ruta JBOSS_HOME/Server/all/conf y reiniciar la plataforma Errores de importación detectados en Se ha comprobado un error de importación provocado por una previa modificación manual en el almacenpscs.jks o el AlmacenTiposCertificados.jks. El problema causa que no se importen todos los certificados necesarios en estos almacenes y por tanto la validación de algunos tipos de certificados puede verse afectada. En el caso deberán copiarse los Almacenes distribuidos con esta política en la JBOSS_HOME/Server/all/conf y reiniciar la plataforma. Es importante tener en cuenta que el AlmacenPSCs.jks y el AlmacenTiposCertificados.jks nunca deben manipularse, siendo modificados únicamente mediante las diferentes opciones de la herramienta de Administración o mediante la importación de políticas como esta. 5. Validación del certificado de firma del Notario Electrónico. Aunque este apartado de configuración solo es necesario realizarlo una sola vez, si se sobrescribe la política al importar una nueva será necesario configurarlo de nuevo, ya que se modificará la URL de descarga del método de validación CRL_NOTARIO_JA. Página 9 de 11

10 Debido a que el prestador del certificado de firma del Notario Electrónico no está dado de alta en el sistema se usa la importación para dar de alta su PSC, mapeos y método de validación, pero es necesario realizar una modificación del método de validación CRL_NOTARIO_JA en cada plataforma o que realice la importación. La CRL para validar los certificados del Notario Electrónico es fija y única (duración de 10 años), de forma que es necesario darla de alta en la base de datos del esquema de validación (VALIDAOWNER) Para este fin, tendrá que copiarse el archivo CRLNotario/crlNotario.crl distribuido junto a este documento en la ruta jboss /server/all/deploy/afirma.war (si no existiera, es necesario crear la ruta en el Una vez copiada la CRL en la ruta indicada se modificará el método de validación CRL_NOTARIO_JA. La modificación de este método de validación se realiza cambiando la ruta de la propiedad URL Servidor con la ruta hacia el contexto afirma.war, justo hacia el nodo concreto donde se ha copiado la CRL de notario qué contiene esta política, por ejemplo, Tras esta modificación la plataforma está preparada para validar los sellos de tiempo proporcionados por el Notario Electrónico. Basta con realizar una prueba con sello de tiempo (Firma en dos fases) sobre el servidor donde se ha copiado la CRL para que esta sea dada de alta automáticamente en la base de datos. Una vez la CRL está en base de datos todos los miembros del cluster podrán acceder ella directamente para validar sus sellos de tiempo independientemente. Página 10 de 11

11 6. Mantenimiento de pares de claves y certificados Tras pasar el tiempo y haber dado de alta certificados y pares de claves en los almacenes y keystores veremos que se lanzan diariamente alarmas AL000 para avisarnos de que han caducado. En el correo recibido a los administradores de la plataforma podremos ver que se especifica el asunto y el almacén o keystore donde se encuentra el certificado. Estos pueden y deben ser eliminados manualmente por el administrador, ya que únicamente provocan el lanzamiento de las alarmas AL000. Si existe algún certificado estrictamente necesario, será necesario actualizarlo para la posterior eliminación del caducado. Los certificados listados a continuación solo son usados por el organismo CHAP, de forma que el resto de organismos que importen este certificado de confianza pueden eliminarlo sin problemas. El motivo de que sea exportado es que no puede hacerse una exportación selectiva y por tanto será importado con esta política: AlmacenConfianzaOCSP: c=es,cn=av dnie minhap,o=direccion general de la policia,ou=dnie,ou=minhap Página 11 de 11