FirmaLocal
Firmar un PDF

Error SAF_16 y SAF_11: el servidor intermedio

SAF_16 («Error al recuperar los datos del servidor intermedio») y SAF_11 son fallos de red: proxy, cortafuegos, sesión caducada o certificado del servidor.

Actualizado el

«SAF_16: Error al recuperar los datos del servidor intermedio» y «SAF_11: Error en el envio del resultado de la operación» son dos caras del mismo problema, y por eso van juntos en esta guía. En ambos casos Autofirma ha arrancado bien, ha encontrado tu certificado y está lista para firmar; lo que falla es la conexión de red entre la aplicación y un servidor de la sede que casi nadie sabe que existe: el servidor intermedio.

Si te ha salido SAF_16, Autofirma no ha podido descargar lo que tenía que firmar. Si te ha salido SAF_11, la firma se ha hecho pero no se ha podido devolver. Las causas son las mismas —proxy, cortafuegos, sesión caducada, un certificado de servidor que Java no reconoce— y el orden de comprobación también. Para el resto de códigos, consulta Todos los errores SAF de Autofirma.

Qué es el servidor intermedio y por qué existe

La sede electrónica no puede pasarle un PDF de varios megas a Autofirma dentro de una URL afirma://. Lo que hace es dejar los datos en un servidor intermedio —dos servicios web del propio organismo, uno de almacenamiento y otro de recuperación— y enviar a Autofirma únicamente un identificador de sesión y la dirección de ese servidor. Autofirma descarga los datos de ahí, firma en tu equipo y sube el resultado al mismo servidor, de donde la página de la sede lo recoge.

Eso significa que Autofirma sale a Internet por su cuenta, con su propio entorno Java, sin pasar por el navegador. Y ahí está la trampa: tu navegador puede tener configurado el proxy de la empresa, confiar en los certificados de la Administración y atravesar el cortafuegos sin problema, mientras que Autofirma no hereda nada de eso. El navegador llega a la sede; Autofirma, no.

En el código fuente los dos códigos son ERROR_RECOVERING_DATA (SAF_16) y ERROR_SENDING_RESULT (SAF_11). El primero agrupa los fallos al recibir los datos de una operación de firma, de selección de certificado, de lote, de carga o de guardado; el segundo, los fallos al enviar el resultado, ya sea por el servidor intermedio o por el puerto local. La errata del mensaje («envio», sin tilde) viene así en la aplicación.

Error SAF_16: «Error al recuperar los datos del servidor intermedio»

Autofirma ha pedido los datos al servidor y no los ha obtenido. Las causas, de más a menos frecuente:

  • La sesión ha caducado. Los datos permanecen en el servidor intermedio un tiempo limitado. Si entre pulsar «Firmar» y elegir el certificado pasaron varios minutos —buscando la contraseña, resolviendo un aviso de Gatekeeper, reinstalando algo—, cuando Autofirma va a por ellos ya no están. Se resuelve empezando el trámite otra vez.
  • Un proxy que Autofirma no conoce. En redes corporativas y de administraciones públicas es la causa clásica; la FNMT lo dice expresamente en su FAQ para SAF_11 y SAF_16. La solución está en Herramientas → Preferencias → General → Configuración de red → Configurar proxy.
  • El certificado del servidor no es de confianza para Java. Autofirma valida el certificado TLS del servidor intermedio con su propio almacén de raíces, no con el del sistema. Si la sede usa una raíz que ese almacén no incluye, o si un antivirus con inspección HTTPS sustituye el certificado por el suyo, la conexión se rechaza. De ahí la casilla «Aceptar sólo conexiones con sitios seguros», explicada más abajo. En el registro detallado este caso aparece como unable to find valid certification path to requested target.
  • Un cortafuegos que bloquea el dominio del servidor intermedio, que no siempre es el mismo que el de la sede que ves en el navegador.
  • La sede está caída o el servicio de almacenamiento no responde. Ocurre más de lo que parece en los días de plazo.

Error SAF_11: «Error en el envio del resultado de la operación»

Aquí la firma se ha realizado: el fichero firmado existe en memoria en tu equipo, pero Autofirma no ha conseguido entregárselo a la sede. Las causas son las anteriores, con un matiz: como la descarga funcionó, el proxy y el cortafuegos suelen estar bien, y las sospechosas principales pasan a ser la caducidad de la sesión (la subida llega tarde) y la casilla de sitios seguros, que es precisamente lo que la Universidad de Málaga documenta como solución para SAF_11 en su sede desde la versión 1.7 de Autofirma.

Un caso particular: si el trámite firma varios documentos seguidos, SAF_11 en el segundo o tercero suele indicar que el servidor intermedio ha limpiado la sesión entre uno y otro. Firmar de nuevo desde el principio, sin pausas, lo resuelve.

La casilla «Aceptar sólo conexiones con sitios seguros»

Está en Herramientas → Preferencias → pestaña General → Configuración de red (en Mac, Autofirma → Preferencias → General). Marcada, Autofirma exige que el certificado TLS del servidor intermedio sea válido y de una autoridad reconocida por su Java; desmarcada, acepta cualquier certificado.

Las FAQ de varias sedes —UMA, ICO, ADIF— recomiendan desmarcarla cuando aparece SAF_11 o SAF_16. Funciona porque elimina la validación que estaba fallando, pero conviene entender lo que se pierde: sin ella, Autofirma no puede detectar que alguien se interpone entre tu equipo y la sede. La recomendación honesta es la de la propia UMA: desmárcala, completa la firma y vuelve a marcarla. Si te encuentras desmarcándola cada vez, el problema de fondo es una raíz de confianza que falta o un antivirus que inspecciona HTTPS, y eso sí tiene arreglo definitivo: actualizar Autofirma (las versiones nuevas incorporan más raíces) o excluir Autofirma de la inspección del antivirus.

Cómo resolverlo, en orden

  1. Empieza el trámite de nuevo, de una vez, sin pausas largas entre «Firmar» y la selección del certificado. Resuelve la mayoría de los SAF_16 y buena parte de los SAF_11.
  2. Si estás en una red de empresa o de una administración, configura el proxy en Autofirma con los mismos datos que usa el navegador, o elige Autodetectar. En Mac, los valores están en Ajustes del Sistema → Red → Detalles → Proxies; en Windows, en Configuración → Red e Internet → Proxy.
  3. Prueba la casilla de sitios seguros: desmarcar, firmar, volver a marcar.
  4. Descarta antivirus y cortafuegos: desactiva temporalmente la inspección de tráfico cifrado, o prueba compartiendo los datos del móvil. Si por otra red funciona, la culpa es de la tuya.
  5. Comprueba la hora del equipo. Un reloj desajustado invalida cualquier certificado TLS.
  6. Actualiza Autofirma si la versión no es la actual: desinstala, reinicia e instala desde el portal oficial.

Si en lugar de estos códigos la sede muestra «No se ha podido conectar con Autofirma» o la aplicación ni siquiera se abre, el fallo está antes, en la comunicación local entre el navegador y Autofirma: esa es la guía del error SAF_45. Y si el código es SAF_26 o SAF_27, la conexión que falla es con el servicio de firma de lotes, que tiene su propia guía: Errores SAF_26 y SAF_27.

Si sigue fallando: firmar sin servidor intermedio

Todo lo anterior existe porque la sede necesita hacer viajar el documento hasta Autofirma y de vuelta. Si el trámite se firma dentro del formulario de la sede, ese viaje es obligatorio y no hay atajo: configura el proxy, habla con sistemas o usa otra red. Cómo reconocer ese caso lo explicamos en ¿Lo aceptará la sede?.

Pero si lo que tienes que hacer es adjuntar un PDF firmado, no hay servidor intermedio que valga: firmas el documento en tu equipo y lo subes ya firmado, como cualquier otro fichero. FirmaLocal hace exactamente eso desde el navegador, sin instalar nada: cargas tu certificado .p12 o .pfx y el PDF, y la firma PAdES-B-B se calcula localmente; ni el documento ni el certificado se envían a ningún servidor, ni al nuestro ni a ninguno intermedio. En una red corporativa restrictiva es, de hecho, la vía que menos permisos necesita. Firma tu PDF ahora. Límites: solo certificados en fichero, una firma por documento, sin sello de tiempo.

Comprobar que la firma vale

Sube el PDF firmado a VALIDe y comprueba que reconoce la firma y el titular. Si la sede te dio SAF_11, conviene hacerlo también con el fichero que Autofirma haya podido guardar en tu equipo: la firma es válida aunque la subida fallara, y en muchos trámites puedes adjuntarlo a mano.

Fuentes

FirmaLocal genera firmas electrónicas avanzadas basadas en certificado cualificado (PAdES-B-B), la misma clase de firma que produce Autofirma con un certificado software. No sustituye a la firma con DNIe ni a la autenticación dentro de una sede electrónica. FirmaLocal no presta asesoramiento jurídico.