Restaurar el flujo de firma tras cambiar de servidor

La empresa migra su ERP a un servidor nuevo, cambia de proveedor de infraestructura o levanta el sistema en otro centro de datos. La aplicación arranca, los usuarios entran, los reportes salen. Y a la mañana siguiente el área contable avisa que ningún documento se está firmando. La firma electrónica automatizada es una de las piezas que más silenciosamente se rompe en una migración, porque casi nunca está en la lista de verificación de quien mueve el servidor.

Este artículo es una guía de restauración ordenada, pensada para el responsable técnico que tiene que dejar el flujo de firma funcionando otra vez, y una lista de prevención para la próxima migración.

Por qué la firma se rompe en una migración

Un flujo de firma desatendida depende de una cadena de elementos que rara vez viajan juntos en una imagen de servidor:

• El certificado en sí, sea un archivo .p12 depositado en una ruta del servidor, un dispositivo conectado o credenciales de acceso a un servicio de firma en la nube.
• La clave de acceso al certificado, normalmente guardada en un archivo de configuración o en un almacén de secretos.
• Los permisos de la cuenta de servicio sobre esa ruta y sobre las carpetas de entrada y salida de documentos.
• La salida a internet hacia los servicios de validación de la entidad emisora y hacia los portales de destino.
• Los certificados raíz e intermedios instalados en el almacén de confianza del sistema.
• La hora y la zona horaria del servidor.
• Las tareas programadas o servicios que disparan el proceso.

Una migración típica traslada la aplicación y la base de datos, y da por sentado el resto. De ahí que el síntoma clásico sea "todo funciona menos la firma".

Diagnóstico en orden: de abajo hacia arriba

1. ¿El proceso se está ejecutando? Antes de investigar la firma, confirma que la tarea o el servicio que la dispara existe en el servidor nuevo y está activo. En muchas migraciones simplemente no se recreó.
2. ¿El certificado está donde el sistema lo busca? Verifica que la ruta configurada exista y que el archivo esté ahí. Las rutas cambian entre servidores y la configuración suele viajar apuntando al camino viejo.
3. ¿La cuenta de servicio puede leerlo? Un archivo presente pero sin permisos de lectura para la cuenta que ejecuta el proceso produce el mismo error que un archivo ausente.
4. ¿La clave de acceso está bien? Si el archivo de configuración se copió de otro entorno o la clave se guardó cifrada con una llave del servidor anterior, el descifrado falla. El síntoma se parece al de clave correcta que el sistema no acepta.
5. ¿La cadena de confianza está completa? Los certificados raíz e intermedios de la entidad emisora deben estar instalados en el servidor nuevo. Si no lo están, verás errores como los descritos en error de cadena de certificados.
6. ¿Hay salida a los servicios de validación? Un servidor nuevo detrás de otro cortafuegos o de otro proxy no necesariamente tiene permitidas las mismas salidas. Los criterios están en configuración en red corporativa.
7. ¿La hora es correcta? Un servidor recién levantado puede quedar con zona horaria por defecto o sin sincronización. Las consecuencias están en fecha y hora mal configuradas.
8. ¿El certificado sigue vigente? Si la migración coincidió con el vencimiento del certificado, la causa del fallo no tiene nada que ver con el traslado y hay que renovarlo.

Recorrer la lista en este orden evita el error habitual de empezar por lo más complejo. La mayoría de los casos se resuelven en los primeros cuatro puntos.

Tabla de síntomas y causa probable

La parte que no se puede copiar: el certificado en dispositivo

Si tu flujo dependía de un token conectado físicamente al servidor anterior, la migración obliga a resolver el traslado físico del dispositivo y la instalación del middleware del fabricante en el servidor nuevo. Si el destino es infraestructura en la nube, directamente no hay dónde conectar el token, y el escenario de redirección tiene las limitaciones que se explican en token USB en máquinas virtuales.

Es el momento natural para replantear el formato. Para firma desatendida en servidores, lo que tiene sentido es un certificado gestionado como servicio o un esquema de mayor control como el descrito en HSM para corporativos. La comparación entre las tres opciones está en nube contra .p12 contra token USB.

Seguridad: la migración es el momento de arreglar lo que estaba mal

Muchas migraciones descubren prácticas que se arrastraban desde hace años: el archivo .p12 en una carpeta compartida accesible para media empresa, la clave escrita en texto plano dentro de un archivo de configuración versionado, o un certificado de una persona natural usado como certificado de sistema. Aprovecha el cambio para corregirlo:

• Guarda el certificado en una ruta con permisos restringidos exclusivamente a la cuenta de servicio.
• Usa un almacén de secretos para la clave, no un archivo de texto.
• Retira el certificado del control de versiones si alguna vez llegó ahí, y considéralo comprometido si estuvo expuesto.
• Registra quién tiene acceso al certificado y a su clave, y revisa esa lista cada vez que cambie el equipo responsable.
• Deja documentado el procedimiento de restauración para la próxima vez.

Pruebas antes de dar por cerrada la migración

1. Firma un documento de prueba y valida el resultado en un equipo distinto del servidor.
2. Ejecuta el flujo completo de punta a punta, incluida la entrega al portal o al sistema de destino.
3. Procesa un lote representativo, no un solo documento: los problemas de recursos y de tiempos aparecen con volumen.
4. Revisa que el registro de eventos del proceso esté escribiendo donde el equipo lo va a mirar.
5. Prueba el reintento ante fallo: qué pasa si el servicio de validación no responde.
6. Confirma que los documentos firmados se archivan sin ser reprocesados por el repositorio.

Si el flujo alimenta emisión de comprobantes, prueba también el envío al SRI antes de reactivar la operación completa. Las causas típicas de rechazo están en firma electrónica rechazada por el SRI. Y si tu empresa quiere dejar de mantener esa capa por su cuenta, el grupo cuenta con Azur, sistema de facturación electrónica autorizado por el SRI, que gestiona emisión, firma y envío de comprobantes sin que tu equipo tenga que restaurar nada después de cada migración. Puedes conocerlo en azur.com.ec/registro.

Checklist para la próxima migración

• Inventario de todos los procesos que firman, con su certificado asociado y su responsable.
• Ubicación, permisos y forma de custodia de cada certificado y de cada clave.
• Lista de destinos de red que el proceso necesita alcanzar.
• Certificados raíz e intermedios a instalar en el servidor nuevo.
• Tareas programadas y servicios a recrear, con su cuenta de ejecución.
• Configuración de hora y zona horaria verificada.
• Plan de prueba definido y ejecutado antes de apagar el servidor anterior.
• Ventana de convivencia: no des de baja el servidor viejo hasta que el nuevo firme y entregue correctamente.

Si además estás rehaciendo la automatización desde cero, aprovecha para rediseñar el flujo en lugar de replicar un esquema heredado que nadie recuerda haber decidido.

Comunicación durante la migración con Omnifox

Durante una migración los avisos llegan por todos lados: usuarios reportando por WhatsApp, proveedores por correo, gerencia por llamada. Omnifox, la plataforma omnicanal del grupo, reúne esos canales en una sola bandeja compartida con historial y asignación por responsable, para que el equipo técnico vea el impacto real en un solo lugar en lugar de reconstruirlo después. Conócela en omnifox.io.

Preguntas frecuentes

¿Se puede copiar el archivo .p12 al servidor nuevo?

Técnicamente sí, y es lo habitual en una migración. Lo importante es hacerlo por un canal seguro, dejarlo con permisos restringidos y eliminar cualquier copia intermedia. Un archivo de certificado que anduvo por carpetas compartidas debe considerarse expuesto.

¿Por qué la firma falla solo en el servidor nuevo si el certificado es el mismo?

Porque el certificado es solo una pieza. Faltan candidatos habituales: permisos, cadena de confianza, salida de red, hora del sistema o la tarea que dispara el proceso. El orden de diagnóstico de este artículo cubre todos.

¿Hay que emitir un certificado nuevo al cambiar de servidor?

No por el solo hecho de migrar. El certificado identifica a la empresa o a la persona, no al servidor. Sí conviene emitir uno nuevo si el anterior estuvo expuesto o si aprovechas para cambiar de formato.

¿Cuánto tiempo debo mantener el servidor anterior?

Hasta que el nuevo haya firmado y entregado correctamente en condiciones reales, incluido al menos un ciclo completo del proceso. Apagar antes de esa verificación es la causa más común de urgencias evitables.

¿Qué formato conviene para firma desatendida en servidores?

Un esquema que no dependa de un dispositivo físico conectado: firma en la nube o certificados gestionados en infraestructura de alta seguridad. El token está pensado para una persona en un equipo, no para un servicio que corre sin supervisión.

Deja el flujo de firma listo y documentado

En Firmas.com.ec emitimos certificados de firma electrónica para empresas con trámite 100% en línea y emisión en aproximadamente 30 minutos, en formato archivo .p12, token USB o firma en la nube, con validez legal ante el SRI y ante la ley. Si estás migrando infraestructura, te acompañamos para que la firma quede operativa y con un procedimiento escrito. Consulta el precio actualizado en la página de precios y cotiza el plan corporativo o habla con un asesor.