Validador (libre) es un validador de firmas digitales de documentos que cumplen con la política de formatos oficiales de los documentos firmados digitalmente de Costa Rica. Utiliza la misma tecnología de reportes que utiliza el validador del proyecto Firmador libre. Se puede compilar desde el código fuente para que cualquiera pueda instalarlo en su servidor y también existe una instalación funcionando en https://validador.libre.cr.
Este validador permite disponer de una opción más para validar documentos en línea, solo teniendo un navegador de sitios web y conexión a Internet. Aunque existe el validador del sitio web de Central Directo del Banco Central de Costa Rica, la alternativa propuesta es útil para quien quiera disponer de un validador que pueda funcionar con integraciones que incluso no requieran conexión a Internet o existan restricciones para ello.
Características
La versión inicial valida los formatos PDF, XML, ODF y P7M con firmas dentro del mismo documento.
Como aspecto novedoso, el validador permite la validación de múltiples documentos a la vez (validación en lote), mediante la selección de múltiples documentos en la ventana de selección de documentos a subir. También es posible seleccionar múltiples desde el sistema operativo y arrastrar la selección hasta la franja del botón que abre la ventana de selección.
El validador en el servidor solo requiere PHP, aunque la implementación es muy sencilla y podría reescribirse en otros lenguajes. Por ahora el reporte se genera en HTML desde un XML mediante la aplicación de una transformación a partir de una plantilla XSL, que por el momento se transforma desde el lenguaje del servidor web, en este caso PHP.
Excepto el lenguaje que maneje las subidas para procesarlas, el validador no funciona como servicio sino que se trata de un ejecutable binario nativo que se lanza cuando sea necesario validar un documento. La salida normalizada (stdout) contiene el XML del reporte. Aunque el validador se basa en Java, no requiere Java en el servidor para funcionar y la velocidad de carga del validador es tan rápida que no es necesario que se tenga que mantener en memoria como servicio, ahorrando recursos si no se está utilizando y aumentando la estabilidad de la máquina servidor.
Aspectos innovadores
Este validador se planteó inicialmente tres años atrás, pero el hecho de tenerlo que preparar como servicio iba a suponer mayor complejidad en el despliegue. Con el paso del tiempo se comenzó a considerar la misma tecnología que se ha planteado en una publicación anterior sobre reemplazar la dependencia de Java en el firmador libre, por lo que inspirándose en ese proyecto a largo plazo, se retomó el desarrollo del validador basado en la misma tecnología, también como banco de pruebas inicial para comprobar la viabilidad.
Como se mencionó en la otra publicación, GraalVM CE permite la compilación anticipada (AOT) de Java en una imagen nativa, reduciendo drásticamente el tiempo de carga, disminuye el consumo de memoria y mejora la seguridad de la aplicación. El rendimiento es suficientemente bueno como para que un proceso donde habitualmente tarda más en iniciar que en procesar, merezca la la pena implementarse. No obstante, la compilación AOT todavía no es perfecta, por ejemplo se tuvo que desactivar la transformación XSL desde Java porque no funcionaba y se delegó este proceso al lenguaje utilizado en la demostración (PHP).
En opciones avanzadas del firmador, existe: cr.libre.firmador.plugins.DummyPlugin y cr.libre.firmador.plugins.CheckUpdatePlugin. Segun nos indicaron eso viene por default, y no esta funcionando la firma. Para que funcione se debe de pasar cr.libre.firmador.plugins.CheckUpdatePlugin al lado izquierdo donde dice Plugin disponible. Eso lo puede hacer en una maquina , pero si existe mil usuarios, Yo no voy a realizar una GPO ,eso no es bien visto. Se puede cambiar esa opción cuando instalo el firmador??
Hola Jose, si en el firmador apareciera un mensaje de error/aviso propio de Java al iniciar, podría ser porque detecta un certificado SSL incorrecto cuando el firmador intenta conectar a https://firmador.libre.cr/version.txt para verificar si existen actualizaciones utilizando el plugin mencionado. Aunque desactivando el plugin mitigaría la aparición del error, el motivo del mismo es que probablemente existe algún tipo de proxy que está reescribiendo la URL hacia un dominio que no corresponde con el certificado TLS que proporciona. Si esta conexión saliente pudiera ajustarse en la configuración de cortafuegos/proxy para permitir a las aplicaciones java o a esta en particular la conexión saliente para ese dominio por HTTPS, o configurar java para utilizar un proxy, creo que no sería necesario crear Políticas de Grupo específicas en AD o LDAP, dependiendo de dónde pueda configurarse esta regla de red.
Saludos,
Gracias por tu pronto respuesta, con el link https://firmador.libre.cr/version.txt me despliega 1.9.3 . Sin embargo, porque tenemos que depender de un tercero .que tal si su ULR es decir, https://firmador.libre.cr se cae por algún motivo, entonces nadie podría firmar. Para mi ese es el problema, el firmado debe apuntar a nuestros servidores es decir el codebase. Nota: el mensaje que esta desplegando es “La conexión a este sitio Web no es de confianza” y sale el sitio web de firmador.libre.cr
Con gusto, en principio si no hay conexión a Internet, el firmador puede arrancar, ya que generaría una excepción capturada silenciosamente para no afectar a la ejecución. Firmar de todos modos requiere conexión si se van a agregar sellos de tiempo (conecta con tsa.sinpe.fi.cr) y agregar información de revocación que se obtienen también los servidores de la CA del BCCR y las CA del Micitt. El mensaje que aparece es diferente, ya que lo genera Java, tal vez al ejecutarse por Web Start, porque detecta que el certificado no es el que corresponde con el del dominio al que intenta conectar, es algo anómalo. Es posible que esté intentando conectar con firmador.libre.cr:8080 y ese puerto 8080 ni siquiera existe en escucha en el servidor, por lo que es indicativo de que algún proxy o cortafuegos/antivirus local o en red está filtrando/manipulando la conexión. Además, el puerto 8080 es un puerto típico de proxy HTTP, por lo que sería recomendable revisar y, en caso de que sea posible, permtir la conexión saliente por HTTPS (puerto 443) a la aplicación Java. Las conexiones a la TSA y para consultas AIA/CRL/OCSP de las CA se realizan por HTTP (puerto 80), es algo propio de la librería y no es parte de plugin de actualizaciones. La configuración de red se configura en el panel de control de Java, ya que es Java el encargado en este caso de conectar, al menos por ahora, para configurarlo adecuadamente para utilizar un proxy, o bien configurar debidamente los antivirus/cortafuegos para que no secuestren o redirijan incorrectamente el dominio a un servidor local que tiene un certificado diferente (o ninguno) y puerto de conexión diferente al que corresponde.
Saludos,