Cuando una empresa entrega sus aplicaciones a través de Citrix, la firma electrónica deja de ser un asunto del usuario y pasa a ser un asunto de arquitectura. El documento vive en un servidor, la aplicación se ejecuta en un servidor y el certificado, en cambio, suele estar en un dispositivo conectado a un computador que está en otro edificio. Todo lo que ocurre entre esos dos puntos depende de cómo esté configurada la plataforma de virtualización.
La buena noticia es que el problema es conocido y tiene soluciones probadas. La mala es que se resuelve con configuración de plataforma y no con clics del usuario, así que el ticket termina siempre en el escritorio del área de infraestructura. Esta guía ordena las decisiones para que ese ticket se cierre una sola vez.
Aplicación publicada o escritorio virtual: no es lo mismo
La distinción condiciona todo lo demás:
- En una aplicación publicada, el usuario solo ve el firmador. Es más limpio de administrar, pero hay que garantizar explícitamente el acceso a las carpetas donde están los documentos y el retorno del archivo firmado.
- En un escritorio virtual, el usuario tiene un entorno completo. Da más libertad y también más superficie de configuración: navegador, visor de PDF, cliente de correo y firmador conviviendo.
- Si los escritorios son no persistentes, cualquier cosa instalada o importada durante la sesión desaparece al cerrarla. Eso incluye certificados importados al almacén del usuario y configuraciones del firmador.
Antes de tocar directivas, define en cuál de los tres escenarios estás. Muchos diagnósticos fallidos son en realidad una discusión sobre persistencia que nadie tuvo.
Redirección del token: la capa crítica
Para que el certificado del usuario se pueda usar dentro de la sesión virtual hay dos mecanismos, y la elección tiene consecuencias:
| Mecanismo | Cómo se comporta | Cuándo conviene |
|---|---|---|
| Redirección de tarjeta inteligente | El dispositivo se expone a la sesión como lector de tarjeta; el middleware trabaja en el servidor | Es la vía habitual para tokens criptográficos y la mejor soportada |
| Redirección USB genérica | Se reenvía el dispositivo completo, con más sensibilidad a latencia y desconexiones | Solo si el fabricante lo indica expresamente para ese modelo |
| Sin redirección | El certificado no está en el puesto: se usa archivo .p12 o firma en la nube | Escenarios con muchos usuarios remotos o teletrabajo |
Las directivas que habilitan cada mecanismo existen tanto en la consola de administración de la plataforma como en el cliente que instala el usuario, y sus nombres cambian entre versiones del producto. Conviene localizarlas en la documentación de la versión exacta que tenga la empresa y no reutilizar instrucciones de una versión anterior. Además, ninguna directiva sirve si el fabricante del token no soporta el escenario: esa consulta va primero.
Middleware en la imagen base, no en la sesión
En entornos virtualizados el software del token pertenece a la imagen base o al mecanismo de entrega de aplicaciones, no a una instalación manual dentro de una sesión. Instalarlo "para probar" en una máquina viva funciona esa tarde y desaparece con la siguiente actualización de la imagen.
Al preparar la imagen conviene dejar por escrito la arquitectura de los componentes (32 o 64 bits, que debe coincidir con el proceso que los invoca), la versión del middleware que se validó y la versión del firmador. Ese trío es lo que cambia cuando algo deja de funcionar tras un mantenimiento. La preparación general del paquete está en cómo instalar los drivers del token.
Almacén de certificados y perfiles no persistentes
La cadena de certificados de la entidad emisora debe estar en la imagen, desplegada al almacén de la máquina. Si se importa al almacén del usuario en una sesión no persistente, se pierde y el usuario vuelve al día siguiente con el mensaje de certificado no válido. Ese síntoma se confunde a menudo con un problema del certificado personal; el diagnóstico correcto está descrito en qué significa el error de cadena de certificados.
Para el despliegue masivo de la raíz y las intermedias en la imagen o por directiva, el procedimiento está en despliegue masivo del certificado raíz por GPO.
Java, versiones y actualizaciones en la imagen
El firmador del Estado se apoya en Java, y en una imagen compartida la actualización automática es un riesgo de disponibilidad para todos a la vez. La versión se fija en la imagen, se documenta y se cambia solo tras una prueba controlada. Los criterios están en Java en la empresa.
Rendimiento, latencia y archivos grandes
Hay tres puntos donde el usuario percibe lentitud y que suelen atribuirse erróneamente al firmador:
- Lectura del documento desde una unidad redirigida. Si el archivo está en el disco local del usuario y se accede a través de la sesión, cada operación viaja por la red. Para lotes grandes conviene trabajar sobre almacenamiento del lado del servidor.
- Diálogo del PIN. Con redirección de tarjeta inteligente, cada operación criptográfica implica un viaje de ida y vuelta hasta el dispositivo del usuario. En enlaces con latencia alta, firmar cincuenta documentos uno por uno se vuelve inviable.
- Salida a internet para validación. La comprobación de vigencia del certificado y el sellado de tiempo requieren red. Si el servidor sale por un proxy saturado, el usuario ve un firmador "colgado".
Para volúmenes altos, la conclusión práctica suele ser la misma: sacar la operación del puesto virtual y llevarla a un proceso centralizado, como se describe en firma masiva en la nube para grandes volúmenes.
La opción que simplifica la arquitectura
Cuando el inventario de tokens es grande y la mesa de ayuda dedica horas a redirecciones, vale la pena evaluar el cambio de formato. Con firma en la nube desaparecen el middleware en la imagen, la redirección, la latencia del PIN y la dependencia del hardware del usuario; queda una llamada de red que se autoriza una vez en el proxy. La comparación de fondo está en archivo, token o nube para la empresa, y el enfoque de equipos en firma electrónica centralizada para equipos de trabajo.
Certificados corporativos
Firmas.com.ec emite certificados de firma electrónica con trámite 100% en línea, entrega en aproximadamente 30 minutos y validez legal y ante el SRI, en formato archivo .p12, token USB o firma en la nube. Para entornos virtualizados, el equipo corporativo puede ayudar a decidir el formato según la arquitectura que ya tienes montada. Consulta el precio actualizado en la página de precios.
Un canal único para la mesa de ayuda
El grupo desarrolla también Omnifox, una plataforma omnicanal que reúne WhatsApp, correo electrónico, redes sociales y llamadas en una bandeja compartida. En empresas con usuarios distribuidos, permite que las incidencias de firma lleguen por el canal que la gente ya usa y queden registradas en un solo historial. Más información en omnifox.io.
Preguntas frecuentes
¿Funciona el token del usuario en un escritorio virtual?
Puede funcionar mediante redirección de tarjeta inteligente, con el middleware en la imagen del servidor y siempre que el fabricante del token soporte ese escenario. Conviene confirmarlo antes de comprometer una fecha de despliegue.
¿Por qué el certificado desaparece cada mañana?
Porque el escritorio es no persistente y lo que se importa al perfil no sobrevive al cierre de sesión. La cadena de confianza va en la imagen, al almacén de la máquina, y el certificado personal debe residir en un medio que el usuario conserve.
¿Es mejor publicar el firmador como aplicación o dar el escritorio completo?
Publicar solo el firmador reduce la superficie de soporte. Hay que verificar el acceso a las carpetas de trabajo y el retorno del documento firmado al lugar donde el usuario lo espera.
¿Qué explica que firmar sea tan lento en la sesión virtual?
Normalmente la combinación de latencia hacia el dispositivo del usuario y lectura de archivos desde unidades redirigidas. Mover los documentos al almacenamiento del servidor y agrupar las operaciones mejora bastante.
¿Se puede usar el archivo .p12 en un escritorio virtual?
Sí, pero hay que decidir dónde se guarda con criterio: es la clave privada de una persona, no un recurso compartido del área de sistemas. En escritorios no persistentes, además, necesita una ubicación que sobreviva a la sesión.
Si tu empresa entrega aplicaciones por virtualización y quiere una firma que no dependa del hardware de cada puesto, habla con un asesor corporativo de Firmas.com.ec. Solicita tu cotización corporativa.