Muchas empresas ecuatorianas dejaron de instalar software equipo por equipo y concentraron sus aplicaciones en un servidor de escritorio remoto. El contable, el asistente de compras y el gerente entran a la misma sesión publicada, trabajan sobre el mismo sistema y el departamento de TI administra una sola máquina. El esquema funciona bien hasta que alguien necesita firmar un documento y descubre que el firmador se comporta de una forma que nunca vio en su computador personal.
FirmaEC, el firmador oficial y gratuito del Estado, es una aplicación de escritorio pensada para un usuario que tiene su hardware al alcance de la mano. En un servidor de sesiones esa premisa se rompe: el programa corre en el servidor y el token está conectado a un computador que puede estar en otra ciudad. Este artículo ordena lo que hay que revisar antes de publicar el firmador a toda la empresa.
Qué cambia realmente en un servidor de sesiones
Conviene separar el problema en tres capas, porque cada una falla por motivos distintos y se diagnostica de forma diferente:
- Hardware: el token USB o el lector, que físicamente está en el equipo del usuario y no en el servidor.
- Sistema: los controladores y el middleware del fabricante del token, además del almacén de certificados de Windows, que en un servidor multiusuario existe por máquina y también por cada perfil.
- Aplicación: el firmador y el entorno de ejecución de Java sobre el que se apoya.
Cuando el diagnóstico salta de una capa a otra sin orden, el equipo de soporte termina reinstalando cosas al azar. Si el problema aparece también en equipos individuales, el punto de partida es otro: revisa primero las causas habituales por las que FirmaEC no funciona y descarta lo básico antes de culpar al servidor.
El token USB y la redirección de dispositivos
Para que un token conectado en el equipo del usuario sea visible dentro de la sesión remota hay dos caminos posibles, y cuál aplica depende del modelo del dispositivo:
- Redirección como tarjeta inteligente. La mayoría de tokens criptográficos se presentan ante Windows como un lector de tarjeta inteligente. Ese tipo de redirección es la vía más estable y la que suele estar soportada por el fabricante.
- Redirección USB genérica. Reenvía el dispositivo completo a la sesión. Es más frágil para dispositivos criptográficos y no todos los fabricantes la respaldan.
Las opciones para permitir o bloquear cada tipo de redirección viven en las directivas de Escritorio remoto y también en la configuración del cliente de conexión. Los nombres exactos de esas directivas y su ubicación en el editor cambian entre versiones de Windows Server, así que la instrucción práctica es ubicarlas en la consola de la versión que tengas instalada en lugar de seguir una ruta copiada de un foro. Y antes de invertir horas: pregunta al fabricante del token si ese modelo está soportado en sesiones remotas. Algunos lo están, otros no, y ninguna configuración compensa un dispositivo que el fabricante no diseñó para ese escenario.
Dónde se instalan el middleware y los controladores
Este es el error de despliegue más repetido. Cuando el token se redirige como tarjeta inteligente, el software del fabricante debe estar instalado en el servidor, que es donde corre el firmador y donde se ejecutan las operaciones criptográficas de la sesión. Instalarlo solo en el equipo del usuario no sirve de nada. Algunos fabricantes piden componentes en ambos lados; conviene leer su documentación en lugar de asumir.
Tres detalles que se pasan por alto:
- La arquitectura debe coincidir. Una biblioteca criptográfica de 32 bits no la carga un proceso de 64 bits, y ese desajuste produce un error genérico de "dispositivo no encontrado" que despista mucho.
- En un servidor de sesiones, las aplicaciones destinadas a todos los usuarios se instalan con el servidor puesto en modo de instalación. Saltarse ese paso deja instalaciones que funcionan solo para la cuenta que las hizo.
- Los servicios relacionados con tarjeta inteligente deben estar habilitados en el servidor. Muchas plantillas de endurecimiento los dejan deshabilitados porque "no se usan".
La guía general para preparar el paquete de controladores está en cómo instalar los drivers del token, y si el dispositivo aparece pero nadie lo reconoce, en token no reconocido por la computadora.
Perfiles de usuario y almacén de certificados
En un servidor de sesiones el perfil del usuario es un objeto administrado, y ahí es donde se guardan el archivo .p12, los certificados importados y la configuración del firmador. Si la empresa usa perfiles temporales o contenedores no persistentes, todo eso desaparece al cerrar sesión y el usuario vuelve a empezar cada mañana.
Las decisiones que hay que tomar de forma explícita:
- Si el perfil es persistente o no, y si los certificados de confianza se despliegan al almacén de la máquina para que no dependan del perfil.
- Dónde se guardan los archivos .p12. Nunca en una carpeta compartida del servidor a la que puedan llegar otros usuarios: un archivo .p12 es la clave privada de una persona y su custodia es responsabilidad de su titular.
- Qué pasa con las carpetas redirigidas y las unidades del equipo local mapeadas dentro de la sesión, porque de ahí saldrán y ahí volverán los documentos.
Java y actualizaciones automáticas
El firmador se apoya en un entorno de ejecución de Java. En un servidor compartido, una actualización silenciosa puede dejar sin firmar a toda la empresa en un mismo instante, y el impacto es mucho mayor que en un equipo aislado. La regla es fijar la versión validada, desactivar la actualización automática y probar cualquier cambio en un servidor de pruebas antes de tocar producción. El detalle de cómo hacerlo está en Java en la empresa: versiones compatibles y cómo fijarlas, que además explica el desajuste de arquitectura que impide cargar la biblioteca del token.
Sesiones concurrentes: el punto que más se olvida probar
Una prueba con un solo usuario no demuestra nada en un servidor multiusuario. Con varias sesiones simultáneas aparecen conflictos que no existen en un escritorio individual: archivos temporales que se escriben en la misma ruta, bloqueos sobre un mismo archivo de configuración y, sobre todo, puertos locales. Si una aplicación auxiliar reserva un puerto fijo en la máquina, la segunda sesión que intente levantarla fallará sin un mensaje claro.
La prueba de aceptación mínima antes de publicar: dos o tres usuarios distintos firmando al mismo tiempo, cada uno con su propio certificado, y al menos uno de ellos firmando un documento grande. Si eso pasa, el despliegue está en condiciones razonables.
Comparativa de formatos en un entorno de sesiones remotas
| Escenario | Ventajas | Puntos débiles en Terminal Server |
|---|---|---|
| Token USB redirigido | La clave nunca sale del dispositivo | Depende de la redirección, del middleware en el servidor y del soporte del fabricante |
| Archivo .p12 en el perfil | No requiere hardware ni redirección | Se pierde con perfiles no persistentes; exige control estricto de dónde se guarda |
| Firma en la nube | No depende del hardware del usuario ni de la sesión | Requiere salida a internet permitida por el proxy corporativo |
Para entornos con muchos usuarios remotos, la firma en la nube elimina de un golpe la capa más problemática. La comparación completa está en nube frente a .p12 frente a token.
Checklist de despliegue
- Confirmar con el fabricante del token si el modelo está soportado en sesiones remotas.
- Instalar middleware y controladores en el servidor, con la arquitectura correcta.
- Habilitar la redirección que corresponda y verificar que el cliente de conexión también la permite.
- Definir persistencia de perfiles y ubicación de los archivos .p12.
- Fijar la versión de Java y bloquear su actualización automática.
- Desplegar la cadena de certificados al almacén de la máquina, siguiendo la guía de instalación de la cadena en toda la empresa.
- Revisar que las directivas de grupo no bloqueen la ejecución, según las GPO que suelen bloquear la firma.
- Probar con varios usuarios concurrentes y documentar el resultado.
Si el servidor está detrás de un proxy con inspección de tráfico, agrega también la revisión de puertos y dominios a permitir: la validación de un certificado necesita salir a internet aunque el documento nunca lo haga.
Los certificados que se firman ahí
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. Para empresas que trabajan sobre escritorios remotos, la firma en la nube es la opción que menos depende de la infraestructura del puesto de trabajo. Consulta el precio actualizado en la página de precios.
Si en ese mismo servidor corre el sistema contable y se emiten comprobantes electrónicos, el grupo también ofrece Azur, facturación electrónica autorizada por el SRI, con registro en azur.com.ec/registro.
Cuando el soporte también es conversación
El grupo desarrolla además Omnifox, una plataforma omnicanal que reúne WhatsApp, correo, redes sociales y llamadas en una sola bandeja compartida. Para una mesa de ayuda que atiende incidencias de firma en varios sitios, tener todos los canales en un mismo hilo evita que el caso se pierda entre un chat personal y un correo suelto. Más información en omnifox.io.
Preguntas frecuentes
¿Se puede usar el token del usuario dentro de una sesión de escritorio remoto?
En muchos casos sí, mediante la redirección de tarjeta inteligente, siempre que el middleware esté instalado en el servidor y el fabricante soporte ese uso. No es universal: hay modelos que sencillamente no están diseñados para sesiones remotas.
¿Es mejor el archivo .p12 en un servidor compartido?
Es más simple técnicamente, pero exige disciplina: cada archivo pertenece a una persona, no al servidor, y debe quedar fuera del alcance de otros usuarios. Si el perfil no es persistente, además hay que resolver dónde se conserva entre sesiones.
¿Por qué funciona para un usuario y falla para el resto?
Casi siempre porque la instalación se hizo dentro de un perfil en lugar de a nivel de máquina, o porque los certificados de confianza quedaron en el almacén de un usuario. También puede ser un conflicto de puertos entre sesiones simultáneas.
¿Conviene publicar el firmador como aplicación remota en vez del escritorio completo?
Suele ser más ordenado, porque limita lo que el usuario puede tocar. Hay que verificar que el acceso a las unidades redirigidas y a las carpetas de trabajo siga funcionando, ya que el documento tiene que llegar y volver.
¿La firma en la nube elimina todos estos problemas?
Elimina los que dependen del hardware y de la redirección, que son la mayoría. Quedan los de red: el servidor necesita salida permitida hacia los servicios del proveedor y una hora de sistema correcta.
Si tu empresa trabaja sobre escritorios remotos y necesita firmar sin depender del hardware de cada puesto, conversa con un asesor corporativo de Firmas.com.ec. Solicita tu cotización corporativa.