El cliente autofirma falla al intentar firmar un PDF certificado que admite firmas

[jose-vano]

Buenas tardes.

Al intentar firmar un campo de firma en un PDF previamente certificado que admite firmas, el cliente autofirma falla con el siguiente error:

El PDF está certificado y no admite firmas electrónicas adicionales.

Con el fin de que se pueda reproducir el error, se adjunta un test.zip ZIP que contiene un PDF previamente certificado que contiene un campo de firma. El cliente de autofirma debería permitir firmar el campo de firma.

Muchas gracias.

[jose-vano]

La corrección propuesta en

https://github.com/ctt-gob-es/clienteafirma/pull/22

soluciona el problema.

[jose-vano]

El problema se solucionó; pero, después, alguien ha reescrito el PdfUtil.java y lo ha estropeado: ahora vuelve a ocurrir el problema. :'(

Por favor, ¿pueden ustedes arreglarlo? Muchas gracias.

[jose-vano]

El problema se solucionó; pero, después, alguien ha reescrito el PdfUtil.java y lo ha estropeado: ahora vuelve a ocurrir el problema. :'(

Por favor, ¿pueden ustedes arreglarlo? Muchas gracias.

[jesusMariaNuinGobNav]

Buenos días, Este problema sigue ocurriendo en nuevas versiones de Autofirma, como la 1.6.5, como la que está publicada en el PAe; supongo que son contratos aparte, en cualquier caso, ¿pueden por favor arreglarlo? Además, publicarlo la corrección en la página de descarga para el ciudadano https://firmaelectronica.gob.es/Home/Descargas.html. Muchas gracias.

[jose-vano]

El problema se solucionó mediante el parche de #22 ; pero, después, alguien reescribió el PdfUtil.java y lo estropeó todo. :'(

La versión 1.6.5 salió rota, y no parece que vayan a arreglar el problema. Es una pena. :'(

[Gamuci]

Hola José,

Acabo de probar a firmar con el último código del repositorio y he podido firmar tanto desde la interfaz de escritorio de AutoFirma como llamándolo desde el navegador. En ambos casos se me ha avisado de que el PDF estaba certificado y se me ha pedido confirmación para continuar. Cuando he aceptado, la firma se ha completado. ¿A ti te da error con este código? ¿En qué caso de uso?

También he probado con AutoFirma 1.6.5 y es cierto que con ella falla la firma desde la interfaz de escritorio.

Muchas gracias.

[jose-vano]

Sr. Gamuci:

Efectivamente, el autofirma falla desde la interfaz de escritorio (no desde el navegador).

El problema se arregló con el parche #22 pero, posteriormente, el desarrollador clawgrip reescribió el PdfUtil.java (y, con ello, estropeó la reparación) en: https://github.com/ctt-gob-es/clienteafirma/commit/8211f33f3d0ad25047614f145616da76eab1e99a#diff-94ba19ef1cc28c78b28013efca8ec9e5

El último código del repositorio sigue estando mal. Si usted lo ha probado y le ha funcionado, es posible que haya sido por las propiedades definidas en la prueba. Pero está claro que volverá a fallar cuando saquen la próxima versión de explotación con las propiedades habituales.

Si usted quiere, puedo volver a proponer un parche para volver a reparar el problema: probablemente bastaría con borrar del PdfUtil.java estas cinco líneas de código fuente:

        else if ("false".equalsIgnoreCase(allow)) { //$NON-NLS-1$
            // No se permite, se lanza excepcion
            throw new PdfIsCertifiedException();
        }
        // No establecido

pero el usuario clawgrip podría, posteriormente, volver a estropear la reparación. ;-)

Muchísimas gracias por atender este "issue", Sr. Gamuci.

Un cordial saludo.

[clawgrip]

José, El comportamiento en este caso debe ser tri-estado, permitir la firma, no permitir la firma o preguntar al usuario, y ello dependiendo de si la propiedad "allowSigningCertifiedPdfs" vale "true", "false" o cualquier otra cosa (incluyendo null). Eliminar uno de los tres estados no soluciona ningún problema, hace que funcione uno haciendo que falle el otro.

Como bien ha probado Gamuci, el código actual del repositorio es el correcto. 1.- Se establece por defecto allowSigningCertifiedPdfs=false (línea 140 de ExtraParamsHelper). 2.- Se comprueba en PdfUtil el estado de la propiedad. a) Es "false", con lo que salta una excepción "PdfIsCertifiedException" 3.- La excepción se captura en SignPanelSignTask (línea 421), y si se está firmando un único fichero, se pregunta al usuario qué hacer. 4.- Si el usuario decide firmar aun estando certificado, se establece ahora la propiedad "allowSigningCertifiedPdfs" a "true" (con "addParamToCertifiedPdf()") y se vuelve a llamar al firmador. 5.- Ahora, PdfUtil encuentra la propiedad a "true" y realiza correctamente la firma.

Permítame reiterar, no podemos eliminar el tercer estado. Su parche anterior, usando "Boolean.parseBoolean" solo admitía dos estados: permitir sin preguntar (true) o preguntar al usuario (cualquier otro valor), pero no prohibir sin preguntar (false) y no debió incorporarse al código en su momento.

[jose-vano]

Sr. Clawgrip:

En primer lugar, quiero agradecerle su contestación. El problema del cliente de escritorio de autofirma con la firma de PDFs certificados es muy desconcertante para los usuarios, por lo que cualquier paso que se dé para salucionarlo es muy bienvenido.

Efectivamente, tal como usted comenta, el comportamiento del códogo fuente actual es tri-estado.

Y, efectivamente, la documentación de autofirma especifica este comportamiento tri-estado.

No obstante, este comportamiento tri-estado implica, en la práctica, que nunca se podrán firmar (con el cliente de escritorio) PDFs certificados. Porque, por desgracia, la propiedad "allowSigningCertifiedPdfs" está fijada a false en el autofirma de explotación que se pone a disposición de los ciudadanos.

Soy consciente de que mi primer parche permitía que saliese la pregunta al usuario tanto en el caso false como en el caso no-definido. Y mi propuesta sigue siendo que se permita elegir al usuario tanto en el caso false como en el caso no-definido; para ello, habría que borrar del PdfUtils.java las líneas:

        else if ("false".equalsIgnoreCase(allow)) { //$NON-NLS-1$
            // No se permite, se lanza excepcion
            throw new PdfIsCertifiedException();
        }
        // No establecido

Tal como usted comenta, el código fuente del repositorio es correcto, pero únicamente desde el punto de vista del cumplimiento estricto del comportamiento que se especificó hace mucho mucho tiempo, no desde el punto de vista de la utilidad práctica del sistema.

Me explico: el cumplimiento estricto del comportamiento tri-estado de la especificiación inical implica que el autofirma de escritorio no puede ser usado para firmar PDFs certificados. Para solucionar este problema, le propongo el "workaround" en el código fuente para que se pregunte al usuario tanto en el caso false como en el caso no-definido.

Por favor, tenga usted en cuenta que, si no se soluciona este problema, todos los Ministerios y Organismos que enviamos a los ciudadanos "PDFs con certificación previa pendientes de firma" vamos a tener que seguir diciendoles que deben usar Adobe Reader para realizar la firma, en vez de autofirma. El autofirma es un sistema muy potente, y es una pena que no pueda ser usado para firmar PDFs certificados.

Muchas gracias de nuevo.

Un cordial saludo.

[jose-vano]

Señores Gamuci y Clawgrip:

Revisando el histórico de modificaciones, de acuerdo con las indicaciones del Sr. Clawgrip, he visto que, en el commit del 5 de agosto de 2019, añadieron ustedes un "workaround" para la excepción de PDF certificado: https://github.com/ctt-gob-es/clienteafirma/commit/955b4c6280c5c9b28c286e93b1e58a63206b535a#diff-d11e691516f39c5479a0040cdbdedf71

Por lo tanto, tienen ustedes razón: la versión actual del código fuente sí que incorpora un "workaround" que soluciona esta "issue".

Así pues, retiro lo que he dicho en mis dos anteriores comentarios y procedo a cerrar esta incidencia.

Antes de cerrarla, aprovecho la ocasión para agradecerles que hayan solucionado este problema y para rogarles que publiquen en explotación una nueva versión, puesto que la versión 1.6.5 salió antes de que ustedes incorporasen el nuevo "workaround".

Un cordial saludo.

[clawgrip]

Muchísimas gracias José, Y, efectivamente, debe ser una característica del uso como aplicación de escritorio, gracias de nuevo por revisarlo. Una pena que se escapase en la versión ya publicada, entienda por favor que en una aplicación tan compleja es muy difícil controlar todos y cada uno de los casos de uso, aunque hagamos un gran esfuerzo en ello.

Un cordial saludo: Tomás

Ciertamente, ójala todos los proyectos de sector público estuviesen como este en un repositorio abierto y permitiesen a los usuarios e integradores conversar directamente con los desarrolladores.