Pocas dependencias generan tantos tickets de firma electrónica como Java. No porque sea un mal entorno de ejecución, sino porque en la mayoría de las empresas nadie lo administra: se instaló alguna vez, se actualizó solo, convive con otra versión que alguien puso para un sistema contable y termina siendo la variable que nadie controla en el puesto de trabajo. El día que el firmador deja de abrir, la causa suele estar ahí.
Este artículo no repite la lista de errores. Explica cómo se gobierna Java en una empresa que firma documentos a diario: qué versión usar, cómo fijarla, cómo evitar que se actualice sola y qué hacer con el almacén de confianza cuando hay un proxy de por medio.
Por qué el firmador depende de Java
El firmador oficial del Estado está construido sobre Java, lo que le permite funcionar en Windows, macOS y Linux con una sola base de código. La contrapartida es que necesita un entorno de ejecución presente y compatible en cada equipo. Según cómo se distribuya la versión que tenga tu empresa, ese entorno puede venir incluido en el propio instalador o depender del Java instalado en el sistema. Verifica cuál es tu caso en la distribución oficial que estés usando, porque cambia por completo la forma de administrarlo: si el firmador trae su propio entorno, la política de Java de la empresa deja de afectarlo.
La versión: qué se puede afirmar y qué no
Aquí conviene ser honesto en lugar de dar un número. Los requisitos exactos de versión los publica la distribución oficial del firmador y cambian con cada actualización, así que la fuente de verdad es esa documentación y no un artículo de blog. Lo que sí es estable como criterio de administración:
- Una sola versión validada por la empresa, la misma en todos los equipos que firman.
- Versión con soporte vigente, no una que haya quedado sin actualizaciones de seguridad.
- Arquitectura coherente con el resto de componentes, especialmente el middleware del token.
- Cambio controlado: se prueba en un grupo piloto antes de tocar el resto de la organización.
Si el firmador ya no arranca y hay que resolverlo hoy, el recorrido de diagnóstico está en Java no abre FirmaEC.
El desajuste de 32 y 64 bits
Es la causa técnica más citada y la peor explicada. Un proceso de 64 bits no puede cargar una biblioteca de 32 bits, y viceversa. Cuando el token de firma se usa a través de su biblioteca criptográfica, esa biblioteca la carga el proceso de Java. Si el entorno de ejecución instalado es de una arquitectura y el middleware del fabricante es de otra, el dispositivo simplemente no aparece, aunque el token esté perfectamente conectado y Windows lo muestre sin problemas.
La regla práctica: la arquitectura del entorno de ejecución y la del middleware del token tienen que coincidir. Cuál elegir depende de lo que ofrezca el fabricante del token para ese modelo, así que la consulta es a su documentación. Si el dispositivo no aparece por ningún lado, revisa también token no reconocido por la computadora antes de reinstalar Java tres veces.
Varias versiones conviviendo en el mismo equipo
Es la situación normal en una empresa con años de sistemas acumulados: una versión para el sistema contable, otra que dejó una aplicación bancaria, otra que instaló el usuario. El problema no es que convivan, sino que nadie sabe cuál se ejecuta cuando se hace doble clic.
Lo que determina cuál se usa es la configuración del sistema: la variable que apunta al entorno predeterminado y el orden de las rutas de ejecución. Cambiar eso en un equipo es fácil; hacerlo de forma consistente en cien equipos requiere que se despliegue desde la herramienta de administración de la empresa. Recomendaciones que evitan sorpresas:
- Desinstalar las versiones que ya no use ningún sistema, tras confirmarlo con los responsables de cada aplicación.
- Dejar por escrito qué versión usa cada sistema crítico antes de tocar nada.
- Si una aplicación antigua exige una versión que el firmador no soporta, no forzar la convivencia: aislar esa aplicación o resolver la firma por otra vía.
Actualizaciones automáticas: apagarlas y reemplazarlas
Una actualización silenciosa de Java es la forma más eficiente de dejar sin firmar a toda la empresa un lunes por la mañana. Pero desactivar la actualización automática sin más deja los equipos con una versión que envejece, y eso es un riesgo de seguridad real. La política correcta tiene dos mitades:
- Apagar la actualización automática en el puesto, para que ningún cambio llegue sin haber sido probado.
- Sustituirla por actualización administrada: la herramienta de despliegue de la empresa distribuye la versión aprobada, en la ventana de mantenimiento, después de la prueba piloto.
Dónde se configura eso depende de la distribución de Java que uses y de la herramienta de administración de la empresa; conviene consultar la documentación de ambas en lugar de aplicar recetas genéricas. En servidores de sesiones el asunto es aún más delicado, porque el impacto es simultáneo para todos los usuarios: el detalle está en FirmaEC en Windows Server y Terminal Server y en firma electrónica en entornos Citrix.
El almacén de confianza de Java, el punto ciego
Este es el detalle que más tiempo hace perder a los equipos de infraestructura. Java mantiene su propio almacén de certificados de confianza, separado del almacén de Windows. Que una autoridad esté instalada y confiable en Windows no significa nada para una aplicación Java.
Tiene dos consecuencias prácticas en una empresa:
- Si el proxy corporativo hace inspección de tráfico cifrado, la autoridad interna que firma esas conexiones debe estar también en el almacén de Java, o las conexiones del firmador fallarán con errores de certificado que nada tienen que ver con el certificado del usuario. El contexto de red está en proxy y firewall corporativo: puertos y dominios a permitir.
- Cada actualización del entorno de ejecución puede reemplazar ese almacén y devolverlo a su estado de fábrica. Por eso la importación de la autoridad interna tiene que ser un paso del procedimiento de actualización y no una tarea manual que alguien hizo una vez.
La herramienta para administrar ese almacén viene incluida en la propia distribución de Java. Sus opciones y su ubicación varían entre distribuciones, así que el procedimiento se documenta internamente con la que use tu empresa.
Tabla de decisiones para administrar Java
| Decisión | Recomendación | Motivo |
|---|---|---|
| Cuántas versiones instaladas | Una sola en los equipos que firman | Elimina la ambigüedad sobre cuál se ejecuta |
| Actualización | Automática desactivada, despliegue administrado | Evita cambios no probados en toda la flota |
| Arquitectura | La misma que el middleware del token | Un desajuste impide cargar la biblioteca criptográfica |
| Almacén de confianza | Autoridad interna importada y verificada tras cada actualización | Java no usa el almacén de Windows |
| Distribución | La que permita el licenciamiento de tu empresa | Hay distribuciones con condiciones de uso distintas; revísalas con el área legal |
Cuando la mejor decisión es no depender de Java
Vale la pena decirlo con claridad: buena parte de este trabajo de administración existe porque la firma se hace en el puesto del usuario. Cuando el proceso se traslada a un servicio en la nube o a una integración con los sistemas de la empresa, la dependencia de Java en el escritorio desaparece del mapa de riesgos. Las opciones están descritas en nube frente a .p12 frente a token, en cómo integrar una API de firma en tu sistema y en cómo automatizar la firma en tu ERP.
Certificados que se adaptan a tu arquitectura
Firmas.com.ec emite certificados de firma electrónica con trámite 100% en línea y entrega en aproximadamente 30 minutos, en formato archivo .p12, token USB o firma en la nube, con validez legal y ante el SRI. Si tu empresa quiere reducir la superficie de administración en el puesto de trabajo, el equipo corporativo puede ayudarte a elegir el formato adecuado. Consulta el precio actualizado en la página de precios.
Coordinación entre sistemas y usuarios
El grupo desarrolla también Omnifox, plataforma omnicanal que reúne WhatsApp, correo, redes sociales y llamadas en una bandeja compartida. Para avisar de una ventana de mantenimiento o coordinar una actualización con las áreas afectadas, tener un canal único con historial evita el clásico "a mí nadie me avisó". Más información en omnifox.io.
Preguntas frecuentes
¿Qué versión exacta de Java necesita el firmador?
La que indique la documentación oficial de la versión del firmador que estés desplegando. Ese requisito cambia con las actualizaciones, así que conviene verificarlo en la fuente en lugar de fijar un número por costumbre.
¿Puedo tener varias versiones instaladas a la vez?
Técnicamente sí, pero es la causa de la mitad de los problemas. Si otro sistema exige una versión distinta, lo sano es dejar documentado qué usa cada aplicación y controlar cuál es la predeterminada del equipo.
¿Por qué el token no aparece aunque Windows sí lo reconoce?
Con frecuencia por un desajuste de arquitectura entre el entorno de ejecución y la biblioteca criptográfica del fabricante. Ambos deben ser de 32 o ambos de 64 bits.
¿Es obligatorio desactivar la actualización automática?
Es muy recomendable en equipos que firman, siempre que se reemplace por un despliegue administrado. Dejar los equipos sin actualizar durante años no es una alternativa aceptable desde el punto de vista de seguridad.
¿Hay licenciamiento que revisar?
Las condiciones de uso dependen de la distribución de Java que elijas y existen alternativas abiertas ampliamente utilizadas. Es una conversación que conviene tener con el área legal antes de estandarizar una distribución en toda la empresa.
Si quieres una firma corporativa que no dependa del entorno de ejecución instalado en cada equipo, conversa con un asesor de Firmas.com.ec. Solicita tu cotización corporativa.