Firma no válida Camerfirma

[isjhdenu]

Al firmar una factura electrónica con un certificado clasificación 8 (sello cualificado de entidad) y 11 de la autoridad camerfirma, la librería genera un fichero que autofirma dice que es válido, pero las webs de Valide y FACe no aceptan por firma incorrecta.

He probado a importar la factura en el programa facturae y firmar con los mismos certificados. El resultado sí pasa los tests de las webs anteriores. La única diferencia que se aprecia visualmente (aparte de los digests y la signature) es el campo x509issuername.

[JMLOSP]

@isjhdenu Buenos días, ¿llegaste a solventar este problema?

Gracias. Saludos

[isjhdenu]

Esta es la respuesta recibida por parte de responsables de @firma.

Se ha comprobado el proceso de verificación que sigue la firma remitida contra el entorno de Producción de la plataforma @firma y ha sido posible reproducir el comportamiento detectado (se adjuntan las trazas de log correspondientes al proceso de validación). El problema de validación de la firma reportada está relacionado con la generación de la firma XAdES B-Level en la que el valor contenido en el elemento es incorrecto ya que éste incluye el atributo stateOrProvince "S" que no es conforme a la norma definida en el estándar RFC 2253 (norma técnica definida en https://tools.ietf.org/html/rfc2253, apartado "2.3. Converting AttributeTypeAndValue"): CN=AC CAMERFIRMA FOR LEGAL PERSONS - 2016, O=AC CAMERFIRMA S.A., OID.2.5.4.97=VATES-A82743287, SERIALNUMBER=A82743287, OU=AC CAMERFIRMA FOR LEGAL PERSONS - 2016, OU=see current address at https://www.camerfirma.com/address, S=MADRID, L=MADRID, C=ES</ds:X509IssuerName> No obstante, la validación del certificado firmante resulta correcta en @firma y dicho atributo es mapeado correctamente (ST=MADRID) en la Plataforma. Entendemos, por tanto, que el problema se encuentra localizado en el aplicativo que trata la generación de firmas de facturas desde el entorno del emisor de las mismas, como parece corresponderse con el caso expuesto en la presente incidencia.

En un entorno windows el atributo que genera para stateOrProvince es "S" y no "ST", por lo que no hay solución.

[JMLOSP]

@isjhdenu Muchas gracias por tomarte un momento en contestarme.

Por lo que veo según la librería de FirmaXades lo que se hace es trasladar el atributo Name del certificado al valor de la firma del nodo X509IssuerName.

Entiendo que afirma lo que hace es manipular ese valor para que ponga ST y no ponga la S que viene del certificado de CamerFirma. ¿Correcto?

¿Llegaste a hablar con CamerFirma para saber si están generando estos certificados de forma correcta?

Muchas gracias por todo. Saludos.

[isjhdenu]

@JMLOSP El problema está en la interpretación del oid de stateOrProvince por el sistema operativo windows.

La librería de FirmaXades, para generar el nodo "x509issuername" en el xml, hace uso de un librería de .net framework que mapea el oid de stateOrProvince y lo representa con el atributo S. El mismo error ocurre cuando visualizas el certificado desde el visor del sistema operativo (certmgr.msc).

Camerfirma al emitir el certificado incluye el oid y no su representación de texto.

Si ese certificado lo visualizamos con alguna herramienta de linux o java, ese atributo se mapea correctamente con ST (como indica el RCF 4514 que deja obsoleto el 2253)

Un saludo.

[rasputino]

Si he entendido el problema bien, indicáis que en en una firma realizada por factura-e en el siguiente nodo: <ds:X509IssuerName>CN=AC FNMT Usuarios,OU=Ceres,O=FNMT-RCM,C=ES</ds:X509IssuerName>

Si está firmado con camerfirma el contenido debe tener un aspecto diferente en firmaxadesnet y en factura-e, no? Si fuera así, ¿podrías pegar un ejemplo de ambas? No dispongo de firma de camerfirma

[JMLOSP]

@rasputino El issuerName depende del certificado, en el caso de las firmas de la FNMT como indicas no existe el componente ST con lo cual no existe este problema, en cualquier otro certificado como el de camerfirma para personas físicas si que existe, Windows lo interpreta como que el nodo es "S" cuando en realidad debería ser "ST" de esta forma independientemente de cómo generes la firma siempre estará errónea si el origen del certificado es un Sistema operativo Windows.

En nuestro caso y gracias a toda la información que facilitó @isjhdenu hemos podido solventar el problema firmando a través de JAVA en vez de a través de la librería de .Net , JAVA por su propio funcionamiento interpreta el certificado correctamente y genera la firma sin incidencias.

No es la solución idónea pero nos permite solventar los problemas para estos tipos de certificados ya que como se indica en este hilo no hay solución a la interpretación errónea de este certificado.

[isjhdenu]

Otra solución poco elegante es guardar el fichero original en el sistema de archivo, invocar el ejecutable de autofirma y leer el fichero firmado.

[dnturbanismo]

Hola,

Quizás se pueda leer la parte pública del certificado (su rawdata) mediante Bouncy Castle (si no recuerdo mal se puede convertir de X509Certificate2 a X509Certificate de Bouncy) para ver cómo interpreta dicha propiedad, y establecer el valor del IssuerName en el nodo de la firma, y seguir empleando el proveedor criptográfico de Windows para la generación de la firma.

Un saludo.

---

De: isjhdenu [notifications@github.com] Enviado: sábado, 15 de febrero de 2020 12:22 Para: ctt-gob-es/FirmaXadesNet45 CC: Subscribed Asunto: Re: [ctt-gob-es/FirmaXadesNet45] Firma no válida Camerfirma (#17)

Otra solución poco elegante es guardar el fichero original en el sistema de archivo, invocar el ejecutable de autofirma y leer el fichero firmado.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/ctt-gob-es/FirmaXadesNet45/issues/17?email_source=notifications&email_token=AESVBZRY7ZLJB63WPB7ZXWTRC7F7PA5CNFSM4IDUEFZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3ICZI#issuecomment-586580325, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AESVBZSBZZXZCVLQR34HGZDRC7F7PANCNFSM4IDUEFZA.

El consumo de papel es perjudicial para el medio ambiente. Por favor téngalo en cuenta antes de imprimir éste mensaje.

Este mensaje de correo electrónico así como los documentos que, en su caso, lleve anexos están dirigidos EXCLUSIVAMENTE a los destinatarios especificados. La información contenida es CONFIDENCIAL y está LEGALMENTE PROTEGIDA. Se informa a quien lo reciba sin ser el destinatario o persona autorizada por éste, que la información contenida es RESERVADA y que cualquier uso, difusión, distribución o copia están PROHIBIDOS LEGALMENTE.

Si ha recibido este mensaje por error, le rogamos lo comunique al remitente y proceda a su ELIMINACIÓN, así como a la de cualquier documento adjunto al mismo. Gracias.

[lespinosajuan]

Buenas tardes!!

habeis conseguido con esta librería que Factura-e os valide el XML firmado con un certificado de FNMT??

No consigo que me valide la firma.

GRACIAS

[jromerus]

Como bien han comentado, las autoridades de certificación suelen indicar el texto del atributo tal y como recomienda el estándar RFC 2253, en este caso debería ser "ST", pero Camerfirma pone el OID 2.5.4.8 para stateOrProvinceName que efectivamente debería ser "ST". Microsoft por su parte analiza la cadena esperando en principio el texto, pero si encuentra el OID lo mapea erróneamente por "S" según se ve en la siguiente tabla.

La solución consiste en aplicar un pequeño parche. La forma más sencilla y rápida que he encontrado es modificar la clase Microsoft.Xades.IssuerSerial y en el método LoadXml línea 126:

//this.x509IssuerName = xmlNodeList.Item(0).InnerText; this.x509IssuerName = xmlNodeList.Item(0).InnerText.Replace(", S=", ", ST=");