EDItran - Firma XAdES-BES para TGSS

Transcripción

1 EDItran - Firma XAdES-BES para TGSS zos Manual de Usuario e Instalación Indra. Mayo EDXAdESUSIA.doc.

2 DOCUMENTO/ARCHIVO Título: NombreArchivo/s:EDXAdESUSIA.doc Código: Soporte lógico: Documento Word 97 Fecha: Versión: 0.1 Ubicación física: /home/jumilla/editranxades/doc/os390/doc. Tecnica REGISTRO DE CAMBIOS Versión Páginas Motivo del cambio Redacción inicial DISTRIBUCIÓN DEL DOCUMENTO Nombre Personal de EDItran Área Desarrollo CONTROL DEL DOCUMENTO PREPARADO REVISADO APROBADO ACEPTADO Damián Menéndez Mejía Cumplimentar con el nombre, la firma y la fecha Sólo para clientes

3 Índice 1. INTRODUCCIÓN INSTALACIÓN Y REQUISITOS Requisitos de instalación Instalar en USS INSTALACIÓN CERTIFICADOS DE CAS DE TGSS Creación del keystore Incorporación de CAs al keystore DEFINICIONES. INTERFAZ GRAFICA Ficheros, Recursos cics EDItran/P Sesión de transmisión EDItran/P (sólo CICS) EDItran/G Sesión de presentación EDItran/G EDItran/FF Entorno local EDItran/FF Usuarios remotos EDItran/FF Cómo incluir el CN si no conocemos el mismo? Sesión de presentación EDItran/FF (parámetros generales) Grupos asociados a Sesión de presentación EDItran/FF Usuarios asociados a Sesión de presentación EDItran/FF Consulta de la sesión de presentación EDItran/FF (firmantes) EJEMPLO PROCEDIMIENTO POSTERIOR A RECEPCION Fichero de salida a la aplicación Otras situaciones LOG EDITRAN/FF ANEXO A Subir al USS el certificado de la CA ANEXO B Códigos de Resultado del servidor Indra. Todos los derechos reservados 24/05/2012 Pag. I - 1

4 1 INTRODUCCIÓN 1. INTRODUCCIÓN En este documento se describen las acciones necesarias para: Instalar EDItran/CD (en la parte USS del zos). Instalar certificados de las CA de la TGSS. Instalar EDItran/FF. Definiciones en la interfaz gráfica Proceso de descarga de un fichero -BES firmado. Modo de funcionamiento. El módulo EDItran/FF-CD hasta la fecha, usaba sólo el formato PKCS#7. No obstante, en una primera fase, se implementa la funcionalidad -BES, para recibir ficheros firmados, validar los certificados y los firmantes y descargar. En una primera fase: TGSS firmará ficheros de aplicación norma 34 en ASCII, con 2 firmantes, uno del grupo de gestores y otro del grupo de interventores, ambos bajo un certificado de la misma CA (si en el futuro hay más de una, no habría problemas). Enviará a las EEFF un fichero attach por cada transmisión (aunque pudieran ser más en un futuro). Este fichero es un XML ASCII base64 con el propio fichero de aplicación más las 2 firmas. En las EEFF, se definirá el grupo de tesoreros y el de gestores, cada uno de ellos con 3 posibles firmantes remotos (aunque el fichero sólo viene con una firma de cada uno de los grupos anteriores). Al recibir el fichero attach firmado, las EEFF en su proceso posterior a recepción: o En un primer paso, descargarán el XML o En un segundo paso, validarán que los firmantes pertenecen a los grupos descritos, que viene una firma de cada grupo, que son correctos los nombres y NIF de los firmantes y validarán el propio certificado. Una vez hecho esto, extraerán las firmas el fichero attach, quedando por tanto un fichero norma 34 en ASCII. o En un último paso, se traducirá el fichero de aplicación de TGSS a EBCDIC y se formateará sobre un FB de LRECL=72, para que lo puedan tratar las aplicaciones de las EEFF, proporcionando además información (fichero ZTBFFSAL), sobre las validaciones de la firma. Las EEFF, con la información anterior, y con el tratamiento del fichero de aplicación, enviarán un fichero de confirmación (positivo o negativo), a TGSS sin firmar. Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 1-1

5 2 INSTALACIÓN y REQUISITOS 2. INSTALACIÓN y REQUISITOS La verificación de firma que proporciona EDItran está desarrollada como un servidor en Java que será instalado en los servicios Unix del zos Requisitos de instalación. Se debe tener instalado, al menos, IBM 31-bit SDK for z/os, Java Technology Edition, V6 y tener acceso al JZOS para el acceso a ficheros de MVS, los ficheros para ello se encuentran en $JAVA_HOME/lib/ext. Con el fin de superar las limitaciones en el tamaño de las claves criptográficas que se utilicen en las firmas, se deben reemplazar los archivos de política restringidos US_export_policy.jar and local_policy.jar del directorio $JAVA_HOME/lib/security, con los que IBM entrega el SDK, por otros de versión no restringida que están en $JAVA_HOME/demo/jce/policy-files/unrestricted. Un servidor TCP java, el cual debe disponer de una dirección y un puerto en el que escuchar las peticiones realizadas desde el EDItran en MVS. Acceso a los servicios UNIX del ZOS. Disponer de criptografía DES (para poder cifrar password). Versión mínima EDItran V5R0F Instalar en USS. 1. Se recomienda crear un directorio en la partición Unix de zos (USS) para instalar el software de verificación de firma, por ejemplo: /u/editranxades 2. Enviar, en modo binario, al USS el paquete EDItranSignatureServicesZOS.tar. Puede usar cualquier utilidad de transferencia de ficheros, como el ftp (ejemplo en el punto 7). 3. Conectarse al USS y descomprimir el fichero dentro del directorio creado (u/editranxades>tar -xof EDItranSignatureServicesZOS.tar). Dejará esta estructura: -lib ---boot -logs -rsc ---truststore En el ejemplo queda como sigue: Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 2-1

6 2 INSTALACIÓN y REQUISITOS /u/editranxades: >ls -l total rw-rw-r--+ 1 KI1056E KISNCE Apr 26 17:05 EDItranSignatureServicesZOS.tar -rwxrwxr-x+ 1 KI1056E KISNCE 132 Apr 27 10:22 keystore.sh drwxrwxr-x+ 3 KI1056E KISNCE 832 Apr 24 10:26 lib -rwxrwxr-x+ 1 KI1056E KISNCE 86 Apr 26 16:49 listks.sh drwxrwxr-x+ 2 KI1056E KISNCE 256 Apr 27 10:26 logs drwxrwxr-x+ 3 KI1056E KISNCE 448 Apr 24 10:26 rsc -rwxrwxr-x+ 1 KI1056E KISNCE 867 Apr 24 10:26 start.sh -rwxrwxr-x+ 1 KI1056E KISNCE 255 Apr 24 10:26 stop.sh Ahora podemos comprobar que los ficheros keystore.sh, listks.sh, start.sh y stop.sh tienen permisos de ejecución. 4. A continuación se edita el fichero start.sh y se da valor a las siguientes variables: PWD= ruta de instalación, donde se ha descomprimido MEM_INI= memoria inicial destinada, en Megas MEM_MAX= memoria máxima destinada, en Megas IP= IP en la que arranca el servidor PORT= PUERTO en el que está escuchando el servidor JAVA_HOME= ruta de instalación de java En nuestro ejemplo el fichero contiene las siguientes líneas: PWD=/u/editranxades cd ${PWD} MEM_INI=1024 MEM_MAX=1024 IP=" " PORT="7775" JAVA_HOME="/usr/lpp/JAVA/J6.0" 5. Posteriormente se edita el fichero stop.sh dando valor a las siguientes variables PWD= ruta de instalación, donde se ha descomprimido En el ejemplo: PWD=/u/editranxades 6. En la instalación se suministra un fichero con la clave pública de la TGSS, keystore, para la validación de los certificados firmantes: /u/editranxades/rsc/truststore/ truststore.pfx. Este fichero tiene como contraseña password. Se recomienda crear un nuevo keystore en el que incorporar el fichero con la clave pública, que también se proporciona, u/editranxades/rsc/truststore/ca--tgss.cer (véase el apdo. 3). 7. Una vez hecho esto ya es posible arrancar la aplicación ejecutando el comando:./start.sh Una vez arrancado el servidor se crea un fichero con el id del proceso: ThreadPooledServer.pid Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 2-2

7 2 INSTALACIÓN y REQUISITOS Para comprobar que el Servidor ha arrancado correctamente una vez ejecutado el comando vemos el archivo logs/out.log, y debería tener las siguientes trazas (el puerto y la IP deberían ser las que hayamos configurado en el fichero). Ponemos el ejemplo: /u/editranxades: >cd logs /u/editranxades/logs: >cat out.log 24/04/ :37:49,564 0 INFO [main] servers.threadpooledserver main - Starting Server 24/04/ :37:49, INFO [Thread-3] servers.threadpooledserver openserversocket - Port: /04/ :37:49, INFO [Thread-3] servers.threadpooledserver openserversocket - LocalSocketAddress:/ : /04/ :37:49, INFO [Thread-3] servers.threadpooledserver openserversocket - InetAddress:/ En caso de que ya estuviera arrancado (por el mismo usuario de USS) obtenemos la siguiente respuesta: /u/editranxades: >./start.sh Error:The Server is already started Si lo intentamos arrancar desde otro usuario, en el fichero de log veríamos: /u/ki64f6e/logs: >tail -f out.log 18/04/ :17:06, ERROR [Thread-3] servers.threadpooledserver openserversocket - Make sure the address is not in use. 18/04/ :17:06, INFO [Thread-3] servers.threadpooledserver openserversocket - Fichero de identificación del proceso eliminado correctamente 18/04/ :49:32,375 0 INFO [main] servers.threadpooledserver main - Starting Server 18/04/ :49:32, ERROR [Thread-3] servers.threadpooledserver openserversocket - Error Starting Server. 18/04/ :49:32, ERROR [Thread-3] servers.threadpooledserver openserversocket - Make sure the address is not in use. 18/04/ :49:32, INFO [Thread-3] servers.threadpooledserver openserversocket - Fichero de identificación del proceso eliminado correctamente 24/04/ :41:01,422 0 INFO [main] servers.threadpooledserver main - Starting Server 24/04/ :41:01, ERROR [Thread-3] servers.threadpooledserver openserversocket - Error Starting Server. 24/04/ :41:01, ERROR [Thread-3] servers.threadpooledserver openserversocket - Make sure the address is not in use. 24/04/ :41:01, INFO [Thread-3] servers.threadpooledserver openserversocket - Fichero de identificación del proceso eliminado correctamente 8. Para parar el proceso:./stop.sh Una vez finalizado se borrará el fichero: ThreadPooledServer.pid Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 2-3

8 3 INSTALACIÓN CERTIFICADOS de CAs de TGSS 3. INSTALACIÓN CERTIFICADOS de CAs de TGSS 3.1. Creación del keystore. Para crear el almacén de certificados en el que, en principio, vamos a incluir las CAs de la TGSS, utilizaremos la herramienta keytool, proporcionada por IBM en su instalación del SDK for z/os, Java Technology Edition (guía de uso en la dirección El keystore se creará de tipo PKCS12 incorporando el certificado que viene en el fichero u/editranxades/rsc/truststore/ca--tgss.cer. Ejemplo: Para ello ejecutaremos:./keystore.sh nombre_de_keystore En la instalación que tenemos partimos de la siguiente situación: /u/editranxades/rsc/truststore: >ls CA--TGSS.cer truststore.pfx Ejecutamos el siguiente comando: /u/editranxades: >./keystore.sh claves.p12 Cuya respuesta es: Enter keystore password: Introduciremos la contraseña con la que queramos crear el keystore, que nos volverá a ser pedida: Re-enter new password: Nos mostrará información sobre el certificado y nos preguntará si es de confianza, a lo que contestaremos yes: Owner: OU=SGI, O=Seg-social, C=ES Issuer: OU=SGI, O=Seg-social, C=ES Serial number: 3e4ce218 Valid from: 2/14/03 1:03 PM until: 2/14/23 1:33 PM Certificate fingerprints: MD5: 2E:25:DE:80:85:0C:CF:B0:B5:A5:ED:0D:F7:A4:44:DB SHA1: A6:7B:6A:93:09:70:66:93:CC:BE:F0:7E:B2:B1:59:C3:F4:BB:D9:AF Trust this certificate? [no]: yes El proceso finaliza correctamente con esta respuesta: Certificate was added to keystore Para ver que se ha añadido el certificado correctamente podemos ejecutar el comando:./listks.sh nombre_de_keystore Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 3-1

9 3 INSTALACIÓN CERTIFICADOS de CAs de TGSS Siguiendo con nuestro ejemplo: /u/editranxades: >./listks.sh claves.p12 Nos pedirá la contraseña con la que hemos creado el fichero Enter keystore password: Y obtenemos esta respuesta: Keystore type: pkcs12 Keystore provider: IBMJCE Your keystore contains 1 entry tgssca1, Jan 1, 1970, trustedcertentry, Certificate fingerprint (MD5): 2E:25:DE:80:85:0C:CF:B0:B5:A5:ED:0D:F7:A4:44:DB Nos indica que se ha añadido al keystore el certificado con el alias tgssca1. En caso de querer cambiar el alias con el que se guarda el certificado en el fichero tendríamos que editar el archivo keystore.sh y cambiar la opción alias tgssca1 con el nombre que se desee Incorporación de CAs al keystore. Si quisiéramos incorporar una nueva CA al keystore podremos hacerlo mediante las utilidades que proporciona la instalación Java de IBM (keytool, ikeyman) o ejecutando el script keystore.sh donde cambiaremos: el nombre del alias (en el original tgssca1) el nombre del fichero donde resida el certificado que vamos a incorporar (parámetro file, en el original CA--TGSS.cer). En el caso de que TGSS no proporcionara un fichero con la nueva CA, sino que enviase algún fichero firmado con algún certificado que incorpore esa nueva CA, podremos obtener un fichero con la CA siguiendo los pasos detallados en el ANEXO A Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 3-2

10 4 DEFINICIONES. INTERFAZ GRAFICA 4. DEFINICIONES. INTERFAZ GRAFICA 4.1. Ficheros, Recursos cics. Debe definir los ficheros ZTBFFLO y ZTBFFPE al CICS (ver miembro FCTCEDA en la librería de jcls). A su vez, debe inicializar dichos ficheros al CICS (ver miembros ZTBFJILO y ZTBFJIPE en la librería de jcls) Para la versión IMS consultar el manual EFF51USUI.doc EDItran/P Sesión de transmisión EDItran/P (sólo CICS). En la sesión de transmisión EDItran/P, se indicará: Procedimiento posterior a recepción: Indra proporciona un procedimiento especial para la descarga, verificación y extracción de firmas, ZTBFP4C EDItran/G Sesión de presentación EDItran/G. En la sesión de presentación EDItran/G, se indicará: Formato fichero descarga = V. El fichero que se recibe es un binario XML, pero necesitamos descargarlo como variable. Fichero único en Recepción. Si va a recibir más de 1 fichero en la misma transmisión, indique N. Si va a recibir un único fichero en cada transmisión indique S. Nombre físico del fichero de aplicación de recepción. Este es el nombre del fichero con que descarga EDItran el XML ASCII base64 que contiene las firmas y el documento. Por tanto, es un fichero que no será tratado por su aplicación. En base a ello, indique un nombre temporal ó no indique nada, en cuyo caso, EDItran creará los valores por defecto para crearlo. Revise la documentación EDItran para ver las opciones de parametrización de este campo. En el ejemplo que sigue, por si se recibe más de 1 fichero, se añade la variable %C (número de orden del fichero recibido) Procedimiento posterior a recepción: Indra proporciona un procedimiento especial para la descarga, verificación y extracción de firmas, ZTBFP4C, ZTBFP4 en IMS. Ascii/Ebcdic = E. TGSS transmite desde una máquina EBCDIC. Traducir en recepción = N. No se puede traducir al descargar el fichero, pues perdería la validez de las firmas. Tabla de conversión en recepción = espacios. No se puede aplicar tabla de conversión al recibir, pues perdería la validez de las firmas. Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 4-1

11 4 DEFINICIONES. INTERFAZ GRAFICA 4.4. EDItran/FF. En lo referente a los perfiles de la versión de IMS se deberá consultar el manual EFF51USUI.doc Entorno local EDItran/FF. Incluir el directorio de funciones y el almacén, así como fichas jcl, prefijo ficheros y procedimiento proporcionado para consultar certificados Pulse PF8 e introduzca path key storage, campos del servidor, PSW del key storage. Path del key storage, es la ruta del fichero keystore donde se guarda el certificado de la TGSS (CA). En esta pantalla se muestra el fichero creado por el usuario (véase 3.1). PSW, deberá introducir la password del keystore. Si el keystore utilizado es el que se suministra con la instalación, truststore.pfx, deberá poner password. Si ha creado un keystore, deberá introducir la password elegida en el momento de su creación. IP del (listener) servidor donde reside la aplicación java de firma de ficheros. La aplicación java, corre en el entorno USS y requiere arrancar un listener en una ip y puerto específicos. Puerto del (listener) servidor donde reside la aplicación java de firma de ficheros. La aplicación java, corre en el entorno USS y requiere arrancar un listener en una ip y puerto específicos. Tiempo conexión servidor. Tiempo en segundos, durante los cuales se espera que la aplicación java devuelva control, extrayendo el fichero del XML y validando las firmas. Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 4-2

12 4 DEFINICIONES. INTERFAZ GRAFICA Ejemplo. Si la ip es la misma que la de la pila ip que atiende al monitor de teleproceso, indique (dirección de loopback). El puerto, puede poner por ejemplo el 7775 (resérvelo en la pila IP), y el tiempo recomendado 60 segundos Usuarios remotos EDItran/FF. TGSS podrá emitir en cada transmisión, n ficheros a tratar. Cada uno de ellos es un binario cuyo contenido es un XML con el propio documento a tratar (en ASCII y base64), y con 2 firmas embebidas. Sólo es viable traducirlo y formatearlo una vez validadas las firmas y extraído el documento ASCII, pues de otro modo se perdería la opción de verificación. Cada uno de esos XML transmitidos contiene 2 firmas autorizadas. No puede contener ni más firmas ni menos (excepto que TGSS indique lo contrario). Una de ellas, pertenece siempre al grupo de Gestión de TGSS. La otra, pertenece siempre al grupo de Intervención de TGSS. A su vez, hay 3 posibles firmantes en cada uno de los grupos descritos. En base a lo anterior, mientras TGSS no notifique lo contrario: No puede haber 1 única firma en el fichero XML, ni 3. Sólo puede haber 2. No puede haber 2 firmas en el fichero XML que pertenezcan por ejemplo a intervención ó a cualquier otro grupo distinto. Deben pertenecer una a Gestión y la otra a Intervención. No puede haber firmantes que no conozcamos entre los 3 posibles de cada grupo que haya indicado TGSS. En EDItran se necesita por tanto, controlar los grupos, cantidad de firmantes posibles por grupo, usuarios posibles de cada grupo, número de firmas requeridas de cada grupo, etc. Los usuarios posibles de cada grupo, los identificamos por su propio nombre y por su DNI (campo CN), datos extraídos del Distingued Name (DN). Tiene textualmente los Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 4-3

13 4 DEFINICIONES. INTERFAZ GRAFICA dos apellidos y el nombre del firmante, luego hay un espacio, un guión, otro espacio y el número de DNI de la persona escrito siempre con 9 caracteres (8 dígitos + letra) Este campo se corresponde con el asunto que aparece en los detalles del certificado de ese usuario en concreto. En definitiva, hemos de indicar las siguientes características: Sesión requiere 1 firma de 3 posibles del grupo de Gestión Sesión requiere 1 firma de 3 posibles del grupo de Intervención Los posibles firmantes del grupo de Gestión son (ejemplo): José Luis, María y Manuel. Los posibles firmantes del grupo de Intervención son (ejemplo): Antonio, Luisa y Raquel Los CN de cada uno de los 6 anteriores (detalles del asunto del certificado son: xxxx, yyy, zzzz, aaaa, bbbb, cccc Por tanto, es necesario conocer los nombres y DNI de los firmantes (CN), puesto que EDItran, valida quien son los firmantes a partir de esta información. TGSS indica que en caso de que no vengan bien los firmantes, se envíe un fichero de confirmación con código de control 16 (Firmante(s) no autorizado(s) en la cuenta). Los CN normalizados de los firmantes, los necesitaremos para incluirlos en los perfiles de EDItran/FF. Los nombres y dni de los firmantes, los debería proporcionar TGSS, pero si esto no ocurriera, se pueden visualizar a partir del explorador de Windows. Continuando con el ejemplo anterior, procederemos a dar de alta a los 6 firmantes posibles: José Luis, María, Manuel, Antonio, Luisa y Raquel. En la opción procedemos a dar de alta a cada uno de ellos, como usuarios remotos de TGSS (8910) Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 4-4

14 4 DEFINICIONES. INTERFAZ GRAFICA Meteremos el CN de la siguiente forma, CN=los dos apellidos y el nombre del firmante, luego hay un espacio, un guión, otro espacio y el número de DNI de la persona escrito siempre con 9 caracteres (8 dígitos + letra) Cómo incluir el CN si no conocemos el mismo?. Si no conocemos el CN del firmante, debemos solicitarlo a TGSS. No obstante, también podemos coger el fichero XML recibido y realizar las siguientes operaciones: Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 4-5

15 4 DEFINICIONES. INTERFAZ GRAFICA Editar el XML recibido, con el explorador (*.xml) y seleccionar el contenido entre las primeras etiquetas <ds:x50s Certificate> y ==</ds:x509certificate> Copiar ese contenido a un fichero *txt (bloc de notas), que acabaremos renombrando como *.cer Abrimos con el explorador de windows Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 4-6

16 4 DEFINICIONES. INTERFAZ GRAFICA Vamos a la pestaña Detalles y después a Asunto: Cogeremos exactamente el CN indicado y lo llevaremos al perfil FF (CN=FERNANDEZ HERNANDEZ JOSE LUIS X) Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 4-7

17 4 DEFINICIONES. INTERFAZ GRAFICA Sesión de presentación EDItran/FF (parámetros generales). Damos de alta en la opción la presentación (es necesario que exista en EDItran/G), indicando que las firmas son attach, el nombre de los ficheros descargados y el modo de formateo. En el ejemplo que nos ocupa, el fichero de aplicación final, será FB de LRECL 72, y será traducido a EBCDIC eliminando los saltos de carro x 0D0A. Tenga en cuenta que el nombre del fichero descargado y que trataba su aplicación, hasta ahora era el que figuraba en la sesión de presentación de EDItran/G, si así se lo indicábamos. Ahora, es conveniente poner otro nombre en la sesión de presentación de EDItran/G y trasladar el nombre que había antes allí a la sesión de presentación EDItran/FF. En el ejemplo, estamos identificando (por si viene más de 1 fichero en la presentación), su número (%C), la fecha de descarga (%A%M%D), la hora de descarga (%H), la entidad remota (8910) y la aplicación de la presentación (-BESB) Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 4-8

18 4 DEFINICIONES. INTERFAZ GRAFICA Grupos asociados a Sesión de presentación EDItran/FF. En el ejemplo que nos ocupa, tenemos que definir grupo GESTION y grupo INTERVENCION. Necesitamos 1 firma de cada uno de los grupos, y esos grupos tienen 3 componentes cada uno. Continuando con el ejemplo anterior, en la opción Los posibles firmantes del grupo de Gestión son (ejemplo): José Luis, María y Manuel. Los posibles firmantes del grupo de Intervención son (ejemplo): Antonio, Luisa y Raquel Repetimos la operación con el grupo INTERVENCION. Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 4-9

19 4 DEFINICIONES. INTERFAZ GRAFICA Usuarios asociados a Sesión de presentación EDItran/FF. Ahora, asociaremos cada usuario remoto a su grupo (opción ) y le indicamos que el usuario puede firmar su emisión. Recordemos con el ejemplo Los posibles firmantes del grupo de GESTION son (ejemplo): José Luis, María y Manuel. Los posibles firmantes del grupo de INTERVENCION son (ejemplo): Antonio, Luisa y Raquel Repetimos la operación con los otros 5 posibles firmantes. Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 4-10

20 4 DEFINICIONES. INTERFAZ GRAFICA Consulta de la sesión de presentación EDItran/FF (firmantes). En la presentación FF (opción ), ya tenemos que los firmantes están asociados. Si quisiéramos consultar ó modificar algún parámetro: Una vez dentro, pulsamos PF4 (usuarios-grupos asociados) para ver los firmantes. Si no indicamos nada y pulsamos INTRO, vemos todos los firmantes, los grupos y las características: En el grupo de GESTION son (ejemplo): José Luis, María y Manuel. El número de firmas obligatorias es 1. Todos ellos tienen capacidad de firmar. Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 4-11

21 4 DEFINICIONES. INTERFAZ GRAFICA En el grupo de INTERVENCION son (ejemplo): Antonio, Luisa y Raquel. El número de firmas obligatorias es 1. Todos ellos tienen capacidad de firmar. Si desde la primera pantalla de la presentación pulsamos PF5 (situación), vemos que en total hay 6 usuarios, 2 grupos remotos y que necesitamos 2 firmas. Aparece José Luis, por ser alfabéticamente el primer nombre del primer grupo Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 4-12

22 4 DEFINICIONES. INTERFAZ GRAFICA Y en esa pantalla, pulsando PF4, SITUACION ESPECIFICA DE GRUPOS Y USUARIOS, confirmamos que tenemos 2 grupos para la recepción, que tenemos los firmantes necesarios de cada grupo (1), puesto que indica que no faltan firmas obligatorias. Si por ejemplo, el fichero viene firmado por José Luis y Manuel exclusivamente, el proceso de descarga daría errores porque no llega ninguna firma del grupo Interventores. En el log FF se indicaría: Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 4-13

23 5EJEMPLO PROCEDIMIENTO POSTERIOR A RECEPCION 5. EJEMPLO PROCEDIMIENTO POSTERIOR A RECEPCION En el siguiente ejemplo, se muestra el funcionamiento del posterior a recepción En la sesión de presentación G tenemos: FORMATO FICH.DESCARGA (F/V/E): V, (TGSS debería emitir poniendo los parámetros de EDItran/G en cuanto a sus ficheros de aplicación de emisión: Formato=B, Lenguaje=B, Traducir=N) Fichero único en recepción N, Nombre del fichero descargado KI.TGSS.NORM34.N%C. En la sesión de presentación FF, tenemos: NOMBRE FISICO FICHERO DE APLICACION (FORMATEADO)...: KI.PMED.R8910.NORM34.F%A%M%D.H%H.N%C FORMATO FICH.DESCARGA (F-V-E): F LONGITUD REGISTRO ( )..: TRADUCIR RECEPCION (A-E-N)...: E ELIMINA SALTOS DE CARRO (S/N): S SALTOS A ELIMINAR EN HEXADEC.: 0D0A El procedimiento posterior a recepción, que se usará en las sesiones en las que se reciban ficheros firmados por TGSS, ZTBFP4C, tiene varios pasos: A4P- Paso que descarga los ficheros firmados emitidos por TGSS. Si por ejemplo se hubieran recibido 2 ficheros en la misma transmisión, se descargarían 2 ficheros VB con los nombres KI.TGSS.NORM34.N01 y KI.TGSS.NORM34.N02. El contenido de cada uno de esos ficheros constaría de: El propio documento ASCII Base 64 del fichero de aplicación de emisión La firma de un usuario de TGSS perteneciente al grupo GESTION La firma de un usuario de TGSS perteneciente al grupo INTERVENCION Si este paso acaba con retorno distinto de cero (y no se trata de un 01, por motivo de no recibir todavía la última transmisión de la presentación), será necesario corregir el error y relanzarlo, ó recibir de nuevo la presentación. ZTBEBA00. Paso sólo aquellos clientes con Estadísticas y alarmas. Este paso sólo entra cando da ABEND el paso A4P. Corrija el error y relance el procedimiento. ZTBGLFE. Paso que genera un fichero (ZTBGFLFE), cuyo contenido son la lista de ficheros recibidos y sus características. Este paso, sólo entra cuando el paso A4P acaba con retorno ceros. Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 5-1

24 5EJEMPLO PROCEDIMIENTO POSTERIOR A RECEPCION PASSORT. Paso para ordenar la lista de ficheros creada anteriormente. La salida se llama ZTBFFLFT. Este paso, sólo entra cuando el paso ZTBGLFE acaba con retorno ceros. PASO01. Este paso, sólo entra cuando el paso ZTBGLFE acaba con retorno ceros. Se trata del paso para verificar y extraer las firmas de los ficheros KI.TGSS.NORM34.N01 y KI.TGSS.NORM34.N02. Este paso, llama mediante una conexión TCP/IP a la aplicación que está en los servicios UNIX y que se encarga de la validación. A este paso le entra un fichero ZTBFLFE con la lista de ficheros descargados a tratar, y crea a su vez 2 listas de ficheros de salida ZTBFFSAL y ZTBFFLF2. Además, crea 2 ficheros de salida, con un nombre por defecto, cuyo contenido son los ficheros de aplicación ASCII que posteriormente se firmaron en TGSS. En este paso, en las verificaciones de firma, se pueden dar las siguientes situaciones para cada uno de los ficheros recibidos: Que este paso acabe con retorno ceros. Indica que todos los ficheros recibidos han sido procesados correctamente en cuanto a verificación de firmas Que este paso acabe con retorno 01. Indica que algún (ó todos) los ficheros recibidos han sido procesados y hay algún problema en cuanto a la verificación de firmas Que este paso acabe con otro código de retorno. Será necesario corregir el error y relanzarlo, INBORR1. Este paso, sólo entra cuando el PASO01 acaba con retorno < 02. Borra la lista de ficheros ZTBGFLFE PASO02. Este paso, sólo entra cuando el PASO01 acaba con retorno < 02. Formatea los 2 ficheros VB ASCII recibidos a ficheros FB de longitud 72 con traducción a EBCDIC, de forma que se acabarán creando 2 ficheros (independientemente de que acabarán con retorno 00 ó 01 en pasos anteriores) KI.PMED.R8910.NORM34.F H N01, siendo la fecha y la hora 16:00:00 KI.PMED.R8910.NORM34.F H N02, siendo la fecha y la hora 16:00:01 Además, el paso tratará el fichero que finalmente se pasará a la aplicación (ZTBFFSAL), cuyo formato se especifica en INBORR2. Este paso, sólo entra cuando el PASO02 acaba con retorno 00. Borra la lista de ficheros ZTBFFLF2 A partir de aquí, la aplicación usuaria, recoge el fichero ZTBFFSAL para ver el dsname de los ficheros recibidos, los nif de los firmantes y el retorno en la validación de firmas y construye un fichero de confirmación positivo o negativo: Si el retorno no es cero, generará un fichero de confirmación negativo con los retornos que le hubiera dado EDItran en el fichero ZTBFFSAL (retornos 12 a 16) Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 5-2

25 5EJEMPLO PROCEDIMIENTO POSTERIOR A RECEPCION Si el retorno es cero, la aplicación, continuará con sus validaciones o Si las validaciones de la aplicación son positivas, generará un fichero de confirmación positivo o Si las validaciones de la aplicación, son negativas, generará un fichero de confirmación negativo (códigos de control 01 a 10). Incluso, puede ser el código 16, Firmante(s) No autorizados en la(s) cuenta(s). Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 5-3

26 5EJEMPLO PROCEDIMIENTO POSTERIOR A RECEPCION 5.1. Fichero de salida a la aplicación. Se crea fichero (ZTBFFSAL) FB de 300. Indicará como fue la verificación de firmas para cada fichero recibido, así como características de las firmas. Tiene 2 tipos de registros: Nivel Nombre Long. Fmto. Descripción 1 Registro ZTBFFSAL alfn. Registros de TIPO Tipo de registros 2 Alfn 01-Registros referentes a ficheros tratados y a su resultado de validación 2 Dos puntos 1 Alfn Valor: : 2 Código de retorno 4 Num Verificación de la firma correctamente Autoridad certificadora no válida Certificado(s) revocado(s). No implementado aún Certificado(s) caducado(2) Documento modificado Firmante(s) no autorizados en la cuenta. Esto es una validación posterior de la firma contra los perfiles de EDItran/FF 2 Dos puntos 1 Alfn Valor: : 2 Dsname Formateado 44 Alfn. Dsname del fichero formateado y traducido final, a tratar final por la aplicación. 2 Dos puntos 1 Alfn Valor: : 2 Dsname descargado 44 Alfn. Dsname del fichero ASCII, extraído del XML y con las ASCII firmas también extraídas. 2 Dos puntos 1 Alfn Valor: : 2 Dsname descargado 44 Alfn. Dsname del fichero descargado por EDItran, cuyo por EDItran contenido es el XML que se ha tratado. 2 Dos puntos 1 Alfn Valor: : 2 Mensaje de error 80 Alfn Mensaje Si rc=0000, Proceso de firma correcto (sin mensaje) Si rc=xxxx, mensaje de error oportuno 2 Area reserva 77 Alfn Area de reserva Nivel Nombre Long. Fmto. Descripción 1 Registro ZTBFFSAL alfn. Registros de TIPO Tipo de registros 2 Alfn 02-Registros referentes a firmantes por fichero. Por cada registro tipo 1, habrá tantos registros de tipo 2, como firmantes contenga el fichero firmado. 2 Dos puntos 1 Alfn Valor: : 2 Area de reserva 4 Alfn 2 Dos puntos 1 Alfn Valor: : 2 Dsname Formateado 44 Alfn. Dsname del fichero formateado y traducido final, a tratar final por la aplicación. 2 Dos puntos 1 Alfn Valor: : 2 Datos del CN firmante 138 Alfn. CN=Apellidos y el nombre del firmante, luego hay un espacio, un guión, otro espacio y el número de DNI de la persona escrito siempre con 9 caracteres (8 dígitos + letra) 2 Filler 109 Alfn Area de reserva Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 5-4

27 5EJEMPLO PROCEDIMIENTO POSTERIOR A RECEPCION 5.2. Otras situaciones. TGSS parece que emitirá un único fichero por transmisión. Tenga en cuenta que todo lo anterior, se trata de un ejemplo, recomendado para situaciones en las que se emitan varios ficheros por transmisión. Además, con esta forma de actuación en el ejemplo se consigue no perder el fichero de TGSS descargado en la transmisión anterior. No obstante, si actualmente su aplicación recibe el fichero de aplicación con un nombre fijo, tenga en cuenta que quitando ese nombre del perfil-g y poniéndolo en el perfil-ff, su aplicación, continuará recibiendo ese mismo fichero. Si por ejemplo, el posterior a recepción, arranca un procedimiento de su aplicación, para tratar el fichero de TGSS, tenga en cuenta, que puede poner variables, tanto en perfil-ff, como en el propio ZTBFFSAL, que pudieran pasarse vía parm a su procedimiento. Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 5-5

28 6 LOG EDITRAN/FF 6. LOG EDITRAN/FF 7.1.1) En la sesión de presentación tenemos un log que podemos consultar (opción Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 6-1

29 7 ANEXO A 7. ANEXO A 7.1. Subir al USS el certificado de la CA El propio paquete de instalación, lleva el certificado de la CA de la TGSS, por lo tanto, no es necesario realizar este proceso. Sin embargo, se describe el mismo, por si TGSS cambia de certificado. En caso de no disponer del certificado de la CA, lo podemos conseguir, cogiendo uno de los certificados de los firmantes, lo abrimos y vamos a la pestaña Ruta de certificación. Marcamos SGI (CA) y pulsamos doble click Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 7-1

30 7 ANEXO A Vamos a Detalles, copiar en archivo y se abre otra ventana. Seleccionamos Der Binario Codificado x509 y lo guardamos Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 7-2

31 7 ANEXO A Ahora ya tenemos todos los datos necesarios En caso que hubiera otras CA (parece que en esta primera fase no es así, repetimos la operación de exportar el certificado de otras CA. Si los 2 firmantes firman bajo la misma CA, no es necesario exportar la CA del segundo firmante. Ya tenemos los certificados de la CA, c:\b2.cer, (c:\b3.cer si hubiera 2 CA ) Una vez tengamos la CA sea porque nos la envió TGSS o la extrajimos de un certificado, lo tenemos en el PC, por ejemplo c:\ CA_SILCON_Prod.der o c:\b2.cer, c:\b3.cer,., procedemos a ponerla en el USS. 1- Lo metemos en USS mediante los comandos (ejemplo de subir b2.cer): a. cmd b. ftp ip destino (pedirá usuario tso y password) c. cd /u/editranxades/rsc/truststore (directorio destino donde subiremos el certificado de la CA). d. binary (ftp en binario) e. lcd c:\ (directorio origen donde se encuentra el certificado de la CA) f. put b2.cer (certificado de la CA, a subir) g. quit (salir) Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 7-3

32 7 ANEXO A 3.- Vemos que queda en el directorio USS. /u/editranxadescd: >ls -l -rw-r editrancd KISNCE 753 Nov 2 15:09 b2.cer 4.- Si el nombre que hemos puesto es muy grande, lo renombramos (para poner un nombre muy corto, por ejemplo CA1, pues luego tenemos un jcl de incorporación al que no se le pueden pasar muchos parámetros) /u/editranxadescd: >ls -l -rw-r editrancd KISNCE 753 Oct 25 09:08 CA_SILCON_Prod.der /u/editranxadescd: >mv CA_SILCON_Prod.der CA1 /u/editranxadescd: >ls -l -rw-r editrancd KISNCE 753 Oct 25 09:22 CA1 Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 7-4

33 8 ANEXO B 8. ANEXO B 8.1. Códigos de Resultado del servidor Existen 2 categorías de resultado: a) Resultados propios de la validación de la firma Verificación de la firma correctamente 012- Autoridad certificadora no válida 013- Certificado(s) revocado(s). No implementado aún 014- Certificado(s) caducado(2) 015- Documento modificado 016- Firmante(s) no autorizados en la cuenta: Esto es una validación posterior de la firma contra los perfiles de EDItran/FF b) Errores propios del proceso Error en proceso. Consultar el código RAZ.: 017- Petición no construida correctamente Error al leer del buffer de lectura la longitud de la trama. Error al leer del buffer de lectura la petición Función peticionaria no reconocida Solamente se validan firmas Attach Lenguaje máquina origen no reconocido Valor de validación CRLS no reconocido Valor de zip no reconocido Valor de cifrado no reconocido Valor de codificación base64 no reconocido Identificador fichero a validar no reconocido Identificador fichero salida no reconocido Identificador clave keystore no reconocido Identificador del path del key storage no reconocido La ruta del fichero a validar debe ser mayor que La longitud de la ruta del fichero de salida debe ser mayor que La longitud de la ruta del fichero de salida de DN debe ser mayor que La longitud de la PASSWORD del keystore debe ser mayor que La longitud de la ruta del keystore a validar debe ser mayor que 0. Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 8-1

34 8 ANEXO B 035- Error en la lectura del fichero origen Error al analizar el xml No se encuentra el elemento Signature en el documento Error en el análisis del elemento signature Error en el proceso de validacion de la firma Error obteniendo la información de firma no válida No se utiliza No se ha encontrado el certificado con el que se firmo dentro del documento Error en la escritura del fichero destino Error en la escritura del fichero dn Error inesperado. + descrpcion del error standard java exception 046- Error leyendo el keystore Error OutOfMemoryError. + descrpcion del error standard java exception: Cuando se produzca este error, se debe aumentar los parámetros de asignación de memoria que están en el fichero start.sh de la instalación del producto. Indra. Todos los derechos reservados EDXAdESUSIA.doc 24/05/2012 Pág. 8-2

35